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 value

The 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.