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.

Après une réinstallation fraîche d'une Debian Bookworm et réutilisation du /home d'une Bookworm mais celle-ci mise à jour depuis un installation initiale de 2017, j'ai perdu mes keyrings.
En fait, le chemin a changé : il ne sont plus stockés dans ~/.gnome2/keyrings/ mais dans ~/.local/share/keyrings/. Solution : arrêt du service gnome-keyring-daemon (moi j'ai simplement déloggué et pris un TTY), restauration de ~/.local/share/keyrings/ vers ~/.gnome2/keyrings/, et c'est reparti.

Je n'ai par contre pas encore étudie ce qui définit ce chemin et pourquoi il n'est plus identique alors qu'à priori l'ensemble du /home a été restauré. Peut-être pour un futur édit.