Your wallet file is deleted, not corrupt: what to do in the first hour

A corrupt wallet file and a deleted wallet file are different problems, and people routinely treat them as the same one. A corrupt file is still on the drive and will wait patiently while you think. A deleted file is being erased, slowly on some drives and within minutes on others, by the machine you are using to research the problem.

That is the whole reason this guide exists. Almost every irrecoverable deleted-wallet case I see was recoverable at the moment the person noticed, and stopped being recoverable during the hours they spent downloading tools onto the same drive.

Two rules before anything else. Do not type your seed phrase into a website, however official the recovery tool looks. Do not send a drive, a wallet file, or a seed to anyone who contacted you first. If you are working out who to trust, read how to tell a legitimate recovery service from a scam before you hand anything to anybody.

The first hour: stop writing to the drive

Deleting a file does not erase it. It marks the space as available. Everything that happens next is a race between you and whatever writes to that space first, and on a running operating system a great deal writes to it: browser cache, log files, Windows Update, the installer for the recovery tool you are about to download.

So, in order:

1. Stop using the machine. If the wallet was on your system drive, shut the computer down. Do not "just check one thing" first.
2. Do not install recovery software onto the affected drive. Install it on a second computer, or run it from a USB stick, and recover to a different drive.
3. Take the drive out and work on it as a secondary drive, connected to another machine. A drive that is not booting an operating system is a drive that is not being written to.
4. Make an image before you recover. A sector-by-sector image gives you unlimited attempts against a frozen copy. Working directly on the original gives you one attempt, and every failed attempt is a write.

Point four is the one people skip, and it is the one that matters most. If the drive is also failing, which is common in this situation, every additional read is a risk you spend on a tool you may have chosen wrongly. Image once, then experiment as much as you like.

Check whether it is actually deleted first

Before any carving, spend ten minutes on the cheap possibilities. A surprising share of "deleted wallet" cases are misplaced wallets.

• Uninstalling wallet software does not delete the wallet. Bitcoin Core's data directory survives reinstalls and upgrades. Reinstalling and pointing it at the old directory is often the entire fix. The details are in recovering a corrupt or deleted Bitcoin Core wallet.
• The wallet may have made its own backups. MultiBit Classic in particular kept timestamped copies in a <walletname>-data folder, in key-backup, wallet-backup and rolling-backup subfolders, which is what rescues most MultiBit cases. See MultiBit wallet files: locations, formats, backups, and derivation paths.
• Windows keeps point-in-time snapshots. Right click the folder that contained the wallet, then Properties, then Previous Versions. Restore points and File History both predate your deletion more often than you would expect.
• Old sync folders and email. Dropbox, Google Drive, OneDrive and iCloud all keep deleted-file histories for a period, and a lot of people once emailed a backup to themselves.
• Every other machine you have owned. A wallet backup from 2014 works exactly as well today as it did then. Keys do not expire.

If any of these produce a file, you are done with this article and you have a normal wallet-opening problem instead.

Does PhotoRec recover Bitcoin wallet.dat files?

Yes, and it will not call them wallet.dat. That single sentence resolves most of the confusion around this question, so it is worth stating before the explanation: PhotoRec does recover the file, and then hands it back to you under a generic name like f0012345.db. People search the output for "wallet", find nothing, and conclude the tool failed when it had already succeeded.

The reason is that PhotoRec has no wallet.dat signature at all. Its only Bitcoin-specific entry is .wallet for the Armory format, which is unrelated. But wallet.dat was never its own file format: a modern Bitcoin Core wallet is a SQLite database, and older wallets (and legacy wallets in current versions) are Berkeley DB files. PhotoRec carries signatures for both. So it carves your wallet as a database, because that is what your wallet is.

Why searching the recovery results for "wallet.dat" finds nothing

This is the part that confuses almost everyone, and it is the reason the free tools appear to fail when they have in fact succeeded.

There are two different kinds of recovery, and they behave completely differently.

Filesystem-aware undelete reads the filesystem's own records of recently deleted entries. It recovers the original filename and folder, so wallet.dat comes back as wallet.dat. It only works while those records survive, which usually means shortly after deletion and before a format.

File carving ignores the filesystem entirely and scans raw sectors for byte patterns that mark the start of a known file type. PhotoRec is the standard free carver, and its documentation is explicit about the tradeoff: it "ignores the file system and goes after the underlying data, so it will still work even if your media's file system has been severely damaged or reformatted."

The catch is that filenames live in the filesystem. A carver never sees them. Its output is a directory of thousands of files named f0012345.db, sorted by type. Your wallet is in there under a generic name, and if you search that pile for "wallet" you will conclude nothing was found.

It gets one step worse. PhotoRec's list of recovered formats has no wallet.dat signature at all. The only Bitcoin-specific entry is .wallet for the Armory wallet format. Bitcoin Core wallets are not carved as wallets, because they are not their own format: the current Bitcoin Core documentation describes wallet.dat as a "Personal wallet (a SQLite database) with keys and transactions," while older wallets, and legacy wallets in newer versions, are Berkeley DB files instead. PhotoRec carries signatures for both Berkeley DB and SQLite.

So the honest answer is the one at the top of this section: yes, and it arrives as an anonymous .db or .sqlite file among a great many others.

How to find your wallet in a pile of carved files

Once you understand that you are looking for a shape rather than a name, sifting the output becomes a normal job. What to look for, by wallet:

• Bitcoin Core. A .sqlite file for a modern wallet, or a .db Berkeley DB file for a legacy one. Wallet files are usually far larger than the incidental application databases around them, and their contents include recognisable Bitcoin Core key and record names.
• MultiBit Classic. A .wallet file, but note that the extension is shared with Armory and the formats are unrelated. MultiBit Classic wallets are bitcoinj protobuf files, so PhotoRec's Armory signature will not match them. These are best found by filesystem-aware undelete, or by searching a drive image for the byte patterns bitcoinj writes.
• MultiBit HD. mbhd.wallet.aes, encrypted, alongside mbhd.checkpoints and mbhd.spvchain files in the same folder. The neighbours are a useful signal that you have found the right directory.
• Electrum. No file extension at all, and the default is simply named default_wallet inside a wallets folder under %APPDATA%\Electrum on Windows or ~/.electrum elsewhere. Extensionless files are exactly what a carver handles worst. If the wallet was made before Electrum 2.8 it may be readable structured text rather than an opaque blob, which makes it findable by content search.
• Blockchain.com and Blockchain.info backups. A JSON file, typically wallet.aes.json, which carves as .json and looks like a wall of base64 inside. See when a Blockchain.com backup file will not decrypt.
• Ethereum and EVM keystores. Small JSON files, usually named with a UTC timestamp and the address, containing crypto, cipher and kdf fields. Easy to identify by content, easy to miss by name.

The practical method on a drive image is not to browse the carved output at all. It is to search the raw image for the structural markers of the format you want, then extract around the hits. That is slower to set up and dramatically more reliable, and it works on files that no signature list covers.

The thing that actually decides your odds: HDD versus SSD

Everything above assumes the data is still physically present. On a spinning hard drive it usually is, for a long time. On a solid state drive it frequently is not, within minutes, and no software can change that.

The mechanism is TRIM. When you delete a file, the operating system tells the drive that those blocks are free, and the drive's own garbage collection wipes them on its own schedule, without waiting for anything to overwrite them. Microsoft's documentation describes delete notifications as the feature "that notifies the underlying storage device of clusters that have been freed due to a file delete operation," and states that "for systems using NTFS, trim is enabled by default unless an administrator disables it."

You can check what your system was doing. On Windows, in an administrator command prompt:

fsutil behavior query DisableDeleteNotify

A result of 0 means TRIM was enabled, which is the default and the bad news. A result of 1 means it was disabled, which improves your odds considerably.

This single fact reorders the whole triage. Deleted wallet on an old spinning drive, noticed quickly, is one of the better cases in this business. Deleted wallet on a TRIM-enabled SSD, noticed a week later, is one of the worst, and anyone who tells you otherwise while quoting an upfront fee is telling you what you want to hear. Realistic numbers for this and other situations are in recovery odds by scenario.

Phones behave like SSDs, and worse. Modern iPhone and Android storage is encrypted at rest, so deleted data is not merely marked free, it is unreadable once its key is discarded. Recovery there means app backups, iCloud or Google account data, and old computer backups, not carving.

Formatted, reset, or reinstalled

A quick format rewrites the filesystem table and leaves the data in place, which is the good case: carving works well on quick-formatted drives, exactly as PhotoRec's documentation claims for reformatted media. A full format writes over the whole volume, and a drive that was encrypted and then reset has had its key destroyed. Those last two are generally not recoverable by software, whatever a paid tool's marketing page implies.

Windows "Reset this PC" sits in between and depends on which option was chosen and what the drive is. It is worth an assessment rather than an assumption.

A fragment is not nothing

If carving returns a wallet file that is truncated or partly overwritten, do not throw it away. A wallet file is a container for keys, and keys are small. A partial Bitcoin Core wallet routinely still contains intact private keys that can be extracted directly, byte pattern by byte pattern, even when no software will open the file as a wallet. The technique, and the specific byte marker for Bitcoin Core keys, is described in the corrupt or deleted Bitcoin Core wallet guide.

The same logic applies across formats. "The file will not open" and "the keys are gone" are separate claims, and the second one needs much more evidence than the first.

What makes it permanent

The short list, so you can avoid all of it:

• Continuing to use the drive, especially as a boot drive.
• Installing recovery software onto the drive you are recovering.
• Writing recovered files back to the same partition. PhotoRec's own instructions are blunt: "you must not choose to write the recovered files to the same partition they were stored on."
• Running repair utilities such as chkdsk against the source drive before imaging it.
• Reformatting, reinstalling the operating system, or accepting a shop's offer to "reset it and see."
• Running a failing drive for hours. If it is clicking, or read speeds have collapsed, every minute powered on costs you.

None of these are exotic mistakes. They are the normal things a competent person does when trying to fix a computer, which is precisely why deleted-wallet cases are so often lost by careful people.

When to hand it over

Hand it over when the wallet is worth more than the drive, when the drive is failing while you work, when the first careful attempt has already failed, or when you are about to run a tool you have not used before against the only copy of your data. The decision point is not difficulty. It is that a wrong move here is not reversible.

That is the service: corrupt and deleted wallet file recovery by David Veksler, through a Colorado-registered LLC, with a written contract, published pricing, a free assessment, and no fee until your crypto is back. In the first message, describe the drive, the wallet software, and what happened, not your secrets. A first assessment should never require your seed words or private keys.

If instead your coins were sent to somebody else's address by a thief or a scammer, this is not a data-recovery problem and no drive work will bring them back. The honest version of that situation is my Bitcoin was stolen, can you help.

Get your free assessment →

Sources

• CGSecurity on PhotoRec ignoring the filesystem, its read-only access, and not writing recovered files to the source partition: https://www.cgsecurity.org/wiki/PhotoRec (retrieved 2026-08-11)
• CGSecurity's list of file formats recovered by PhotoRec, including the Armory .wallet signature, Berkeley DB, SQLite and JSON, and the absence of any wallet.dat signature: https://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRec (retrieved 2026-08-11)
• Bitcoin Core doc/files.md on wallet.dat being a SQLite database, and on the legacy Berkeley DB wallet files: https://github.com/bitcoin/bitcoin/blob/master/doc/files.md (retrieved 2026-08-11)
• Microsoft on delete notifications (trim or unmap) and NTFS defaults, and the fsutil behavior query DisableDeleteNotify command: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior (retrieved 2026-08-11)
• Electrum FAQ on the wallet file location and the default_wallet name, and on wallet file encryption since version 2.8: https://electrum.readthedocs.io/en/latest/faq.html (retrieved 2026-08-11)