Robin
Predictably the contents of /home/asus/Documents is now empty
Even when this comes now way too late, it may prevent you from future incidents like that.
1.) Use two separate external backups instead of a single one, and process them one by one only, making sure only one of them is plugged the same time.
2.) Have checked with md5sum that the files have been copied properly before unplugging the first device. Non of the native linux copy or move commands does this for you, and I have ran into cases already where files have been copied to nirvana, because the usb-storage stick-controller was faulty, pretending and reporting to the kernel being writing, but actually did nothing. Thus in the end the moved files were gone from the original place, but not present in the new place either, or had changed significantly: some areas in them were zeroed.
3.) Plug the second backup stick only once you are absolutely sure everything is on the first one 1:1 as expected and after having unplugged the first one already physically after safe release of the filesystem on it.
This way in case of an incident like the above, you’ll not lose everything, but merely what you have done between the last backup (still present perfectly fine on the second backup stick) and the very moment, where the new backup has been hosed along with the originals.
For super sensitive stuff even backups have backups, and they are located in DIFFERENT geographic locations.
Precisely that. And not merely for super sensitive stuff. I had to learn the hard way that it can happen that your internal hdd and the external USB backup stick breaks the same time, without any obvious reason. Maybe the constant overvoltage delivered by our power supplier (he is legally allowed to!) may have played a role in this: We see here 251V frequently instead of the nominal 230V, since the day they have raised the mains from originally 220V, which has fried already some older electronic and electric equipment which was never rated for constantly running on excessive values like they consider OK these days, before I understood that they sometimes don’t supply 230 but 250V. But the modern PC mains adapters should handle this properly, since it is within the currently legally allowed tolerances, so in theory this should not have caused this. The long and short of it: There are common cases even in default users reach, which can kill the backups of years if relying on a single backup medium (Luckily I didn’t, but still many stuff was lost forever)
Some additional hints which you might find to be helpful:
I had good success restoring much (literally all) from a corrupted vfat file system on an sd card, using photorec from the testdisk package on antiX (23 and 26).
1st Make absolutely sure to umount the drive immediately after the incident. If you need access, make sure to mount it always read-only.
2nd dd the complete partition to an external drive, using:
$ sudo dd bs=512 conv=noerror,notrunc status=progress if=/dev/partition of=/path/to/external/dd_backup.img
3nd Now you can try to apply different recovery strategies and tools on a fresh copy of this image, again and again; this way you have more than a single shot in case first attempt fails (and it will fail!), using different tools (like the already mentioned by others: extundelete, which should work if e.g. the journal hasn’t been wrapped over already on an ext4 file system, which makes clear why immediate umounting is crucial)
Be patient. It will take some hours to run, depending of the partition size. In my case the 64 GiB medium took 14 hrs constant processing (unattended) by photorec in several automated passes, constantly 60 MiB/sec disk i/o (USB 2.0) and constantly ~50% CPU load at highest available CPU frequency of 1,7 GHz. Please note: Photorec expects plenty of target space to save the all file fragments. You’ll have to check them individually afterwards one by one, and rename them appropriately.
While, extundlete might be able to restore the former file naming, since it reads and analyses the inode structure from the journal, scanning for recently deleted inodes, while photorec crawls the raw data directly, searching for known file structures.
Good luck!
Windows is like a submarine. Open a window and serious problems will start.