Restore huge file from shadow copy without copying

Question

I have a volume with a shadow copy. The shadow copy contains a very big file (let's say 100 GB). The shadow copy is on the same disk as the volume it is shadowing. The "original" file got deleted. I want to recover it from the shadow copy. I can mount the shadow copy with

mklink /d __Shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy69\ 

then simply copy the file from the shadow copy, but it will be slow, and it will double the space used (there will be two separate copies of the file).

I tried using mklink /H to create a hard link to the file but it doesn't work (it checks that the file are in the same "volume". I've an Italian Windows. Translated in English the error is The system cannot move the file to a different disk drive). Are there other tools to do it?

I'm running Windows 11 Pro.

Addendum: just tried using PowerShell 7.4.1 and this example. Same result, same error. It could be a (wrong) check done at the OS level.

Answer 1

It could be a (wrong) check done at the OS level.

The check is not wrong. Volume Shadow Copy works at block level, below the filesystem; it only uses the filesystem to store the differences, but they're all in terms of "changed blocks X-Y" and not "changed files". In effect, when you mount a VSC snapshot, you have two separate NTFS instances that see different views of the underlying disk, where the same sector/cluster# may contain different data, and they behave literally as if they're accessing two unrelated disks.

So if the file has been deleted, it wouldn't be as simple as just pulling the list of extents (cluster #'s) that the "snapshot" file references and making a new file that references the same extents on the "live" volume, because those clusters are not guaranteed to contain the original data anymore. On the "live" view of the volume, some of those clusters may have already been overwritten and/or assigned to another file – the chance of that happening is fairly high if you had 100 GB worth of them.

The way VSC preserves old data is by copying it to a "diff area", which on the live volume is represented by a file under 'System Volume Information'. Old data belonging to all files is gathered into the same "diff area" before it's overwritten, meaning that e.g. cluster #1234 of the snapshot is actually kept in cluster #56789 of the live volume. Only VSC knows the internal structure of the diff area – NTFS itself does not; it just sees it as a bunch of large files that are in use by some other driver.

So this creates a few problems: First, as NTFS doesn't interact with VSC, it cannot create cross-volume links because it doesn't know how the cluster layout of the file seen in the "snapshot" translates to the cluster layout of the link that you want to create on the "live" volume. Second, if you did convince NTFS to craft a file that references clusters within the VSC snapshot area, you'd have two files referencing the same clusters. ReFS can handle that; NTFS cannot.

Third, such a file would have to be read-only forever, as any changes to the clusters that live in VSC's diff area would lead to changing the VSC snapshot that's supposed to be read-only. (VSC's cluster copying doesn't apply to clusters that already correspond to VSC's storage!) And vice versa, deleting the VSC snapshot could potentially lead to corrupting the "live" file.

So it is correct that NTFS generally refuses to link across volumes without making an exception for VSC snapshots.

It could certainly be made to work if NTFS were to check VSC about which sectors haven't been overwritten yet, and to copy the overwritten sectors out of VSC's storage back into a regular location, but that's far more code than merely bypassing the check, and I don't think it's possible to do in third-party apps – it's something that would need to be implemented within NTFS directly.

---

(This is all very different from, say, Btrfs snapshots which all share a single view of the underlying storage, and where copying a file out of a snapshot merely references the same sectors that belong to another file.)

Answer 2

The usual advice for restoring files, rather than copying, is this:

1. Right-click the file to be restored, or if it was deleted then the folder where it was located, and click Properties
2. Click the Previous Versions tab
3. Select a restore point containing the file
4. Click Restore
5. Click Yes for the warning message (be ABSOLUTELY SURE that there are no other files in this location that will be overwritten by this process, if there are then move them elsewhere)
6. The file will now be restored to the folder where it was previously located.

Reference : Recover lost or deleted files.