Never save recovered files back to the source drive
Recovery software finds the missing files and asks where to save them. The affected drive has plenty of free space, so it seems like the obvious destination.
Do not use it. During recovery, space reported as free may still contain the content you want to recover.
How recovery can overwrite its own source
After deletion, the file system may mark a file's former storage as available for reuse. Recovery software can sometimes find the surviving records or content because those locations have not yet been overwritten.
Saving recovered output creates new files. If those writes reuse locations belonging to other lost files, the recovery process destroys part of its own remaining input. Finding a file during a scan does not mean its contents have already been copied to safety.
The result may be deceptive: the first files open normally while later ones contain damaged or unrelated content. A saved scan list is not a backup of the listed files. Keep the source, image, working copy and extracted output distinct.
A simple overwrite example
Imagine a deleted archive whose contents still occupy regions the file system now regards as free. The scan identifies its old record and lists it for recovery. Before the archive is exported, several recovered photographs are saved into that same volume. The file system may allocate the photographs over part of the archive's old content.
The archive can still appear in the scan list with its correct name and size. When it is finally exported, however, its bytes are no longer the same. A recovery application generally cannot reserve all potentially recoverable source regions against ordinary file-system writes.
The same conflict applies to metadata: saving output creates allocation updates and directory records as well as file contents. You cannot protect the source simply by choosing a different folder or exporting only small files.
Writes can begin before you press Recover
Installing recovery software onto the affected volume can reuse deleted space. So can downloading its installer, saving a scan session there, or using a temporary directory on that volume. On a running system disk, normal operating-system activity can continue writing even if the recovery program itself opens the source read-only.
Cloud synchronization also deserves attention. Recovering into a synchronized folder can create extra local activity and propagate partially restored output or unwanted changes elsewhere. Choose a deliberate destination and keep your only independent backup separate from that activity.
This is why a deleted-file problem on the active system drive needs more planning than installing a tool and scanning C:. Another boot environment or controlled attachment may be appropriate, provided encryption keys, automatic mounting and hardware compatibility are accounted for.
Does another partition solve the problem?
A different partition on the same physical disk is not equivalent to separate storage. Correctly defined, non-overlapping partitions normally restrict ordinary file writes to their own address ranges. That makes the situation different from saving into the same source volume.
Nevertheless, partition boundaries may be part of the problem under investigation. Both partitions also depend on the same device, and a device failure can take both copies away. Use a separate healthy physical device for a clear and reliable recovery destination.
A different drive letter is not enough evidence: check what physical disk or storage pool is behind it. Another NAS share can still belong to the affected pool.
Choose the destination before extracting
- Identify the physical source, the image location if applicable, and the output destination.
- Choose separate healthy storage with enough capacity for the selected files and possible duplicate results.
- Confirm that its file system supports the expected file sizes. For example, FAT32 cannot hold a single file of 4 GiB or larger.
- Keep recovery logs, scan databases and temporary output away from the source as well.
- Recover a representative sample and check that files open correctly before exporting everything.
- Retain the source or preserved image until the important results have been verified and backed up.
The image file and extracted output may share a sufficiently large healthy destination device for practical reasons, but that device then holds both copies and remains a single point of failure.
Four destinations that look safer than they are
Scroll horizontally to see the full table →
| Proposed destination | What to check |
|---|---|
| Another folder on the source volume | It uses the same free-space allocator and is unsuitable |
| Another drive letter | It may be another partition on the same device or another view of the same storage |
| Another share on the affected NAS | It may depend on the same damaged pool, disks or metadata |
| A virtual disk stored on the source | The guest's new writes become writes to its backing file on the source |
An external drive with a different physical identity is easier to verify. Identify it by model, capacity and, when available, serial number; do not trust drive letters to remain constant after reconnecting devices.
How much free space do you need?
The output requirement is the size of the files you intend to extract, not necessarily the entire source capacity. However, recovered sets can include duplicates, old versions and false candidates. A compressed, sparse or deduplicated source may also require more destination space when exported as ordinary files.
An image has its own requirements. A raw image can represent the full selected address range even when the original volume was mostly empty; compressed and sparse image formats behave differently. Confirm image-format support before choosing the next recovery tool.
If destination space runs out, preserve the successful output and acquire more separate storage or narrow the selection. Do not “temporarily” use the source for the remainder. If creating a sector-level clone, remember that the clone destination is overwritten; it cannot simultaneously serve as storage for unrelated files you need to keep.
Validate without editing your only recovered copy
Save enough information to associate the output with its recovery run. Test archives, open documents and inspect media beyond their first frame. Use copies for applications that may rewrite or repair a file on opening. Once the important results are verified, make an independent backup before erasing or reusing any recovery source.
If you have already saved files to the source
If some extracted files are unusable, see why recovered files will not open before attempting file repairs. Stop further writes. Keep the files already recovered; do not delete them to “make space,” because that does not restore overwritten content. Preserve the current state and reassess what remains recoverable.
When can the original drive be reused?
Only after recovery is complete, important files are verified and another copy exists. If the original device is unreliable, replace it.
The principle
The source is where you read. The destination is where you write. Keep them separate throughout recovery.
Sources and further reading
- Microsoft Support: Windows File Recovery — Source overwrite risks and the requirement for a different recovery destination.
- CGSecurity: PhotoRec documentation — Avoiding source writes and choosing a destination suitable for large recovered files.