Vue normale

Reçu hier — 31 mars 2025

Quick Machine Recovery : un espoir pour les PCs Windows 11 victimes d’une panne critique ?

31 mars 2025 à 15:17

Quick Machine RecoveryMicrosoft introduit Quick Machine Recovery, un outil automatisé destiné à faciliter la résolution des pannes critiques sur les PCs Windows 11

Cet article Quick Machine Recovery : un espoir pour les PCs Windows 11 victimes d’une panne critique ? a été publié en premier par GinjFo.

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

31 mars 2025 à 11:30
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

Fini les BSOD ? Microsoft teste un outil pour déboguer Windows à distance

31 mars 2025 à 06:34

Encore traumatisée par l’affaire Crowdstrike, Microsoft teste actuellement un outil qui permet à l’entreprise de corriger à distance les bugs les plus gênants.
 [Lire la suite]

Envie de rejoindre une communauté de passionnés ? Notre Discord vous accueille, c’est un lieu d’entraide et de passion autour de la tech.

Reçu avant avant-hier

Recover deleted/replaced files on EXT file systems

14 mars 2025 à 16:04

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
❌