Vue lecture

Quick Machine Recovery : le nouvel outil de Microsoft pour réparer Windows 11 à distance en cas de crash

Microsoft teste actuellement une nouvelle fonctionnalité prometteuse dans Windows 11 : Quick Machine Recovery, un outil capable de corriger à distance les pannes critiques qui empêchent le système d’exploitation de démarrer. D’abord annoncée par Satya Nadella lors de la conférence Microsoft Ignite 2024 dans le cadre de l’initiative Windows Resiliency, cette fonctionnalité est désormais disponible … Lire la suite

Source

  •  

Recover deleted/replaced files on EXT file systems

I just had to try and recover a couple files that a buggy program replaced with empty files instead of their actually updated content. Context is an EXT4 FS, on a secondary data partition (and even disk, but that's unrelated).

Linked post is interesting, but a bit over-doing it: no need to actually back the journal up in my case (tho I did it), nor unmount the partition to use either tool.

Additionally the linked article talks about deleted files, whereas here I wanted to recover previous versions of the content of existing files. I guess this requires the program not having rewritten the same blocks, but in my case the program both writes to a temp file first and then renames over (although it happily replaced with an empty file), and wrote a 0-bytes file which likely wouldn't overwrite anything. Anyway, for this use case, the key is the -b option to give it a time frame that does not include the faulty rename.

So, basically what I did:

  • Remount the partition read-only to avoid any additional writes that could corrupt the data blocks: `sudo mount /dev/sdb1 -o remount,ro
  • Backup the EXT4 journal just in case (but I highly doubt that was of any use, I could have used the actual FS's journal): sudo debugfs -R "dump <8> $HOME/sdb1.journal" /dev/sdb1
  • Trial version listing potential recoveries: sudo ext4magic /dev/sdb1 -a $(date -d "-2hours" +%s) -b $(date -d "-45minutes" +%s) -f relative/path/to/files/ -j ~/sdb1.journal -l
  • Actual recovery: sudo ext4magic /dev/sdb1 -a $(date -d "-2hours" +%s) -b $(date -d "-45minutes" +%s) -f relative/path/to/files/ -j ~/sdb1.journal -r -d RECOVERY/

At this point I had the files in their state from 45 minutes ago, validated the recovery and remounted read-write. Done.

This was surprisingly easy, thanks to journaling FS :)
To be fair, having the lost data outside the root or home FSes helped a lot, not only because of random applications potentially writing stuff if any mutable data is stored there (/home, /var/run, /tmp and whatnot), but I could also easily install the tools I missed straight away without risks of overwriting precious data blocks.


Permalink
  •