Clonezilla e dd possono fallire nei vostri backup: ma ho la soluzione!

Uso abitualmente Clonezilla per i backup dei miei PC sia a casa che al lavoro e non ho mai avuto grossi problemi (o meglio, quando li ho avuti, di solito li ho sempre capiti e risolti con qualche configurazione adhoc).

In questi giorni ero alle prese con un osso duro invece. Un vecchio PC del 2011 che non ne voleva sapere di farsi backuppare.

La cosa particolare è che nè nei in backup nè nei restore veniva mostrato nessun errore: il risultato era però un sistema restorato (debian 10 su ext4) con file corrotti e inutilizzabili.

Ne ho provate di ogni:

  • ho utilizzato diverse versioni di clonezilla per verificare che non fosse una regression; (sono arrivato fino a versioni del 2011)
  • ho utilizzato varie architetture di iso di clonezilla (amd64, i686-pae e i686);
  • ho provato direttamente “dd”

Ed è proprio questa ultima prova ad avermi indirizzato al problema reale: come è possibile che neanche dd possa funzionare?

Abitualmente lanciavo questa riga di bash per avviare il backup con dd:

dd if=/dev/sda1 status=progress bs=2M | gzip -c > /home/partimage/image.gz 

Notate la parte in grassetto? Non è stata messa a caso. Cercando in giro per stackoverflow a caccia di problemi su dd, mi sono imbattuto in questo thread che mi ha aperto un mondo.

E in effetti, lanciando il backup in questo modo:

dd if=/dev/sda1 status=progress | gzip -c > /home/partimage/image.gz 

Il tutto funziona perfettamente, ovviamente facendo il restore in questo modo:

gunzip -c /home/partimage/image.gz | dd of=/dev/sda1 status=progress 

Ora rimane solo un problema: clonezilla non supporta la possibilità di cambiare il parametro bs passato a dd, e qui ho chiesto allo sviluppatore di abilitare un opzione in merito. Vediamo come andrà a finire.