Recuperant un arxiu perdut i esborrat
Des de l'inici, hem estat desant els canvis que fèiem al submarí en un arxiu anomenat Changelog. Sense cap format estricte ni estàndard, però ben útil per veure els canvis d'altres admins i els propis de fa setmanes i mesos. El problema va venir quan es va sobreescriure aquest arxiu amb una versió antiga, per culpa d'una sessió de vim que portava mesos oberta...
Primer fem un backup de la targeta SD
Apaguem la raspi i la fiquem a un portàtil amb gnu/linux
dd status=progress bs=4M if=/dev/mcxxxxxx of=submarin-sdcard-2019_08_22.iso
Muntem la còpia en només lectura per analitzar-la
Intentem muntar el backup de la targeta amb mount
mkdir mnt mount -o loop,ro submarin-sdcard-2019_08_22.iso ./mnt → mount: /home/raneq/iso/mnt-raspi: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
Oh no! error! no ens deixa muntar la partició perquè la SD no tenia taula de particions.
Com que ens volem assegurar del que hi ha, busquem una manera de muntar-la. Però avís! si no necessites assegurar-te què hi ha dins, pots saltar-te aquest pas i executar el photorec directament contra la imatge.
(?¿). Trobem un programa que ens ho resol:
man partx
Given a device or disk-image, partx tries to parse the partition table and list its contents.
It can also tell the kernel to add or remove partitions from its bookkeeping.
-a, --add
Add the specified partitions, or read the disk and add all partitions.
-v, --verbose
Verbose mode.
sudo partx -av submarin-sdcard-backup-2019_08_22.iso partition: none, disk: submarin-sdcard-backup-2019_08_22.iso, lower: 0, upper: 0 Trying to use '/dev/loop0' for the loop device /dev/loop0: partition table type 'dos' detected range recount: max partno=2, lower=0, upper=0 /dev/loop0: partition #1 added /dev/loop0: partition #2 added
ls /dev/loop0* loop0 loop0p1 loop0p2 sudo mount -o ro /dev/loop0p1 mnt/ mkdir mnt2 sudo mount -o ro /dev/loop0p2 mnt2/
Bé! Ja tenim les dues particions muntades. A veure quina és la interessant:
▶ ls mnt bcm2708-rpi-b.dtb bcm2710-rpi-cm3.dtb fixup4db.dat kernel7l.img start4x.elf bcm2708-rpi-b-plus.dtb bcm2711-rpi-4-b.dtb fixup4x.dat kernel.img start_cd.elf bcm2708-rpi-cm.dtb bootcode.bin fixup_cd.dat LICENCE.broadcom start_db.elf bcm2708-rpi-zero.dtb cmdline.txt fixup.dat LICENSE.oracle start.elf bcm2708-rpi-zero-w.dtb config.txt fixup_db.dat overlays start_x.elf bcm2709-rpi-2-b.dtb COPYING.linux fixup_x.dat start4cd.elf bcm2710-rpi-3-b.dtb fixup4cd.dat issue.txt start4db.elf bcm2710-rpi-3-b-plus.dtb fixup4.dat kernel7.img start4.elf
▶ ls mnt2/ bin dev home lost+found mnt proc run srv tmp var boot etc lib media opt root sbin sys usr
Bé, sembla que la partició de dades és la segona, la que està a loop0p2 i muntada a mnt2. Així que desmuntem l'altra.
sudo umount mnt
Fem servir photorec per inspeccionar la partició en cerca del nostre arxiu perdut
Mirem el que diu la descripció de la web de photorec
:
PHOTOREC
FAT, NTFS, ext2/ext3/ext4 file systems store files in data blocks (also called clusters under Windows). The cluster or block size remains at a constant number of sectors after being initialized during the formatting of the file system. [...]
When a file is deleted, the meta-information about this file (file name, date/time, size, location of the first data block/cluster, etc.) is lost; for example, in an ext3/ext4 file system, the names of deleted files are still present, but the location of the first data block is removed. This means the data is still present on the file system, but only until some or all of it is overwritten by new file data.
To recover these lost files, PhotoRec first tries to find the data block (or cluster) size. If the file system is not corrupted, this value can be read from the superblock (ext2/ext3/ext4) or volume boot record (FAT, NTFS).
Ens agrada! Endavant! A veure si està als repositoris de Debian:
apt search photorec testdisk/stable,stable 7.0-3+b4 amd64 Partition scanner and disk recovery tool, and PhotoRec file recovery tool testdisk-dbg/stable,stable 7.0-3+b4 amd64 Partition scanner and disk recovery tool, and PhotoRec file recovery tool
Val, sembla que està dins del paquet de testdisk. L'instaŀlem i llegim el manual:
apt install testdisk
man photorec NAME photorec - Recover lost files from harddisk, digital camera and cdrom SYNOPSIS photorec [/log] [/debug] [/d recup_dir] [device|image.dd|image.e01] photorec /version
Ostres, sembla que ens podríem haver estalviat la part de muntar la imatge iso
amb partx. Diu que es pot apuntar a un device
o a una image.dd
.
O potser no? És possible que photorec no sàpiga interpretar les
particions i ho agafi tot seguit... Bé, igualment ja ho tenim fet així, continuem.
sudo photorec /dev/loop0p1
Havia fet servir el testdisk abans, la interfície del photorec és molt semblant: tot per consola, fletxes en els quatre sentits per moure's, i anar passant pantalles:
↑↓ seleccionar dev ←→ navegar menú ENTER acció ESPAI des/habilitar
Fem els següents passos:
> [Proceed] Unknown [Whole disk] > Partition ext2, ext3 o ext4. →→ [File Opt] PhotoRec will try to locate the following files [X] custom Own custom signatures ... [ ] ttf TrueType Font [ ] tx? Text files with header: rtf,xml,xhtml,mbox/imm,pm,ram,reg,sh,slk,stp,jad,url [X] txt Other text files: txt,html,asp,bat,C,jsp,perl,php,py/emlx... scripts Press s to disable all file families, b to save the settings
No hi sembla que hi hagi vim swap file. Ho comprovem a la seva wiki
To recover more files, it is possible to add your own custom signatures to PhotoRec.
En aquest punt, vam provar de fer-ho buscant simplement text files. La veritat és que va ser molt lent (com 1 hora per 8 gigues) i va treure molts i molts arxius... Entre els quals alguns fragments de Changelog. Però el resultat no ens satisfeia, així que vam decidir provar això de les custom signatures.
Seguim les instruccions de la seva wiki
Comprovem que no sap detectar arxius swap de vim.
fidentify .hola.txt.swp .hola.txt.swp: unknown
I com es creen noves "signatures"? Volem que detecti arxius esborrat i el seu swapfile de vim
The file must contain one signature definition per line. A signature is composed of
extension name offset of the signature signature or magic valueThe magic value can be composed of
a string, ie "data". Special characters can be escaped like "\b", "\n", "\r", "\t", "\0" or "\\". hexadecimal data, ie 0x12, 0x1234, 0x123456... Note that 0x123456, 0x12 0x34 0x56 and 0x12, 0x34, 0x56 are equivalents. space or comma delimiters are ignored
Molt bé, no sembla difícil! Però... necessitem alguna eina per no equivocar-nos amb l'hexadecimal. A veure hexdump si serveix per això:
man hexdump -C Canonical hex+ASCII display. Display the input offset in hexadecimal, followed by sixteen space-separated, two column, hexadecimal bytes, followed by the same sixteen bytes in %_p format enclosed in ``|'' characters.
Provem d'executar-lo contra el swapfile d'abans:
hexdump -C .hola.txt.swp 00000000 62 30 56 49 4d 20 38 2e 31 00 00 00 00 10 00 00 |b0VIM 8.1.......| 00000010 c5 29 64 5d 70 a7 16 00 6b 49 00 00 70 69 6e 67 |.)d]p...kI..ping| 00000020 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |u...............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 70 6f 72 74 61 74 69 6c 00 00 00 00 |....portatil....| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 7e 70 69 6e |............~pin| 00000070 67 75 2f 69 73 6f 2f 70 68 6f 74 6f 72 65 63 32 |gu/iso/photorec2| 00000080 2f 68 6f 6c 61 2e 74 78 74 00 00 00 00 00 00 00 |/hola.txt.......| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Ei! Tenim alguna cosa! Sembla que comencem sempre amb la cadena de text "b0VIM 8.1"
Al lío!
PhotoRec searches for the signature file named .photorec.sig in the HOME directory, ie. /home/bob photorec.sig in the current directory
Molt bé, si és tan fàcil, provem això:
echo 'swp 0 "b0VIM "' > photorec.sig fidentify .hola.txt.swp .hola.txt.swp: swp
BINGO!
En fem un altre
hexdump -C changelog | head 00000000 23 20 43 68 61 6e 67 65 6c 6f 67 0a 0a 0a 32 37 |# Changelog...27| 00000010 2f 30 38 2f 32 30 31 39 20 2d 20 70 69 6e 67 75 |/08/2019 - pingu| 00000020 0a 0a 0a 52 65 63 75 70 65 72 6f 20 70 61 72 74 |...Recupero part| 00000030 73 20 64 27 61 71 75 65 73 74 20 63 68 61 6e 67 |s d'aquest chang| 00000040 65 6c 6f 67 20 71 75 65 20 73 27 65 6e 73 20 68 |elog que s'ens h| 00000050 61 76 69 65 6e 20 65 73 62 6f 72 72 61 74 2e 0a |avien esborrat..| 00000060 48 65 20 65 73 63 72 69 74 20 75 6e 61 20 65 6e |He escrit una en| 00000070 74 72 61 64 61 20 64 65 20 62 6c 6f 67 20 61 20 |trada de blog a | 00000080 68 74 74 70 73 3a 2f 2f 73 75 62 2e 6d 61 72 69 |https://sub.mari| 00000090 6e 2e 6c 69 2f 32 30 31 39 2f 30 38 2f 32 37 2f |n.li/2019/08/27/| fidentify changelog changelog: txt
Aquí veiem que el nostre arxiu de Changelog sempre començava igual. Així que podem crear una signatura nova que detecti arxius amb aquest inici de text... Quina idea!
echo 'sub 0 "# Changelog"' >> photorec.sig fidentify changelog changelog: sub
BINGO!
Final
Amb aquests filtres propis, en comptes de passar centenars de filtres complexos per cada bloc, només n'executarà dos i de senzills. Podem deshabilitar el txt també i deixar només el custom.
Llavors executem el photorec amb només els filtres propis habilitats i.... Voi-là, 7.5 GB analitzades en 2 minuts, 15 arxius swap de vim recuperats, 5 dels quals del changelog, i mitja dotzena de versions esborrades del mateix arxiu. En dos minuts de processament!!
Descobrim que als arxius de text ja hi ha tota la informació i decidim que no cal recuperar les dades de les swap de vim.