Site icon Gioxx.org

raspiBackup: backup senza la necessità di togliere la scheda SD

Raspberry Pi

Photo by Harrison Broadbent on Unsplash

Progetto tedesco completamente Open Source, accessibile all’indirizzo github.com/framps/raspiBackup, raspiBackup è la soluzione di backup che tiene al sicuro il tuo ambiente di lavoro (e file annessi) senza la necessità di rimuovere la scheda SD dal Raspberry Pi (vedi RPi: backup della scheda SD (Windows / macOS)). Diamo un’occhiata insieme al progetto e affrontiamo una prima installazione con risoluzione di un problema annesso. In piedi da quasi 5 mesi, raspiBackup è diventata la soluzione in produzione, senza dimenticare che il momento in cui un backup è davvero utile e sensato è quando c’è bisogno di effettuare il restore.

Photo by Vishnu Mohanan on Unsplash

Prima installazione

Ti parlo rapidamente del mio ambiente di lavoro per farti capire lo scenario: Raspberry Pi di terza generazione, modello B+, a bordo una scheda SD SanDisk da 32 GB che fa il suo sporco lavoro e tiene in piedi diversi processi automatici di backup, dialoga con Arlo e tado° (e quindi con Telegram e la casa in generale), manipola e pubblica le liste X Files su GitHub (mestiere che nel frattempo si è evoluto e ha visto nascere delle novità delle quali spero di parlarti presto), mantiene vivo (per scopo di test) Pi-hole. Il Raspberry può contare sullo spazio disco messo a disposizione dal mio NAS in NFS, è lì che mando in backup la maggior parte delle cose.

Detto ciò, l’installazione di raspiBackup è cosa resa semplice da uno script che tu potrai lanciare da riga di comando:

curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/installation/install.sh | sudo bash

Affronterai così una procedura guidata che ti porterà al termine della configurazione di base, la quale – salvo problemi che stiamo per vedere insieme – dovrebbe permetterti di effettuare il tuo primo backup completo di Raspberry Pi.

Riassumendo (e qui di seguito ti lascio le immagini catturate durante la prima installazione), dovrai:

Ready to backup?

Ed è qui che casca l’asino. Felice come non mai per la semplice installazione, ho scelto di lanciare immediatamente un backup di test. L’operazione può durare molto tempo (in base a quanti dati possiedi, alla velocità del disco fisso di destinazione e alla rete locale). Al termine, ammesso sia configurato (e io lo usavo già per altro), ti arriverà un resoconto a mezzo posta elettronica per riassumerti ciò che è accaduto:

--- RBK0031I: Checking whether a new version of raspiBackup.sh is available.
--- RBK0151I: Using backuppath /mnt/Backup/RaspiBackup with partition type nfs.
!!! RBK0157W: No services to stop.
--- RBK0036I: Saving partition layout.
--- RBK0158I: Creating native rsync backup "/mnt/Backup/RaspiBackup/raspberrypi/raspberrypi-rsync-backup-20210328-040001".
--- RBK0085I: Backup of type rsync started. Please be patient.
??? RBK0021E: Backupprogram for type rsync failed with RC 23.
--- RBK0033I: Please wait until cleanup has finished.
--- RBK1001I: Memory usage - Pre backup - Used: 480 MB Free: 48 MB - Post backup - Used: 477 MB Free: 133 MB
--- RBK1000I: CPU temperature pre and post backup: 54.8'C - 53.7'C
??? RBK1005E: bc not found. Please install bc first with with 'sudo apt-get install bc'.
--- RBK0043I: Removing incomplete backup in /mnt/Backup/RaspiBackup/raspberrypi/raspberrypi-rsync-backup-20210328-040001. This may take some time. Please be patient.
--- RBK0049I: Messages saved in /root/raspiBackup.msg.
--- RBK0026I: Debug logfile saved in /root/raspiBackup.log.
--- RBK0010I: raspberrypi: raspiBackup.sh V0.6.6 (83ecd03) stopped at dom 28 mar 2021, 05.44.20, CEST with rc 109.
??? RBK0005E: Backup failed. Check previous error messages for details.

Fallito con un errore di tipo RC 23, ho deciso di consultare la pagina dedicata alle FAQ (linux-tips-and-tricks.de/en/faq), trovando riscontro:

All versions of raspiBackup ignored some errors of tar and rsync. This can cause inconsistent backups. Therefore starting with v0.6.3.2 no errors are allowed any more. In version 0.6.3.2a it’s possible to enable this again with following definitions in the configfile.
It’s strongly recommended to eliminate the error root cause and don’t ignore the errors. Use option --systemstatus to list the active system services in the debug log in addition to the open files. Locate the service which modifies files during the backup and stop it with option -o

Per cercare di andare un po’ più a fondo, ho deciso di dare un’occhiata ai log del programma, scontrandomi con questo messaggio un po’ più specifico:

20210328-040018 DBG 1478:                      --- Redirect: & - Skips:
rsync: set_acl: sys_acl_set_file(media/pi, ACL_TYPE_ACCESS): Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]

Ho quindi consultato il contenuto (e lo scambio di risposte) di una issue precisa su GitHub, all’indirizzo github.com/framps/raspiBackup/issues/94, decidendo così di lanciare una ricerca approfondita per scovare ciò che stava dando fastidio tra gli attributi dei file che mandavo in backup sul NAS:

find / \( -path /proc -o -path /dev -o -path /proc -o -path /sys -o -path /tmp -o -path /run -o -path /mnt -o -path /media -o -path /lost+found -o -path /export -o -path /home/ftp -o -path /srv -o -path /sharedfolders \) -prune -o -name '*' -exec getfattr -h -d -m "^" --absolute-names {} \; 2> /dev/null | more

sfortunatamente, senza successo.

Ho quindi scelto di andare a ritoccare il file di configurazione di raspiBackup (è /usr/local/etc/raspiBackup.conf, e ti toccherà lanciare l’editor con privilegi elevati per poterlo modificare) e mettere in pratica ciò che viene riportato nella pagina FAQ del software, all’indirizzo linux-tips-and-tricks.de/en/faq/#a24, chiedendo a rsync di ignorare (e quindi non trasportare in backup) gli attributi dei file (dato che non avevo intenzione alcuna di attaccare un disco esterno diretto al RPi o passare in quel momento da NFS 3 a 4):

DEFAULT_RSYNC_BACKUP_OPTIONS="-aHx --delete"

A questo punto ho rilanciato l’operazione di backup e sono riuscito a portarla a termine correttamente.

E ora?

E ora ricorda quanto detto a inizio articolo: un buon backup è quello che sei in grado di ripristinare facendo nuovamente funzionare tutta la baracca. Ciò vuol dire che – per esempio – potresti prendere una memoria SD di pari grandezza rispetto a quella che stai usando in produzione, infilarla nel Raspberry Pi dopo averla preparata con un’installazione base di Raspbian e raspiBackup, caricare il file di configurazione che hai usato in passato (tanto avrai sicuramente modo di recuperarlo proprio dal backup che intendi utilizzare per il ripristino) e quindi lanciare l’operazione di restore.

Ha funzionato? La scheda SD nuova è pari a quella vecchia, contiene tutto e ti permette di tornare a lavorare correttamente con il tuo Raspberry Pi? Molto bene, allora avevi effettuato un buon backup. Sii contento per il risultato e goditi il tuo nuovo software di backup per Raspberry Pi. Io, come al solito, sono qui a tua disposizione in caso di dubbi o domande in merito all’articolo, l’area commenti è qualche colpo di scroll di mouse più in basso.

#StaySafe


Credits:
linux-tips-and-tricks.de/en/all-pages-about-raspibackup/539-raspibackup-manual-installation
github.com/framps/raspiBackup/issues/94
unix.stackexchange.com/questions/12203/rsync-failed-to-set-permissions-on-error-with-rsync-a-or-p-option
Immagine di copertina: Harrison Broadbent on Unsplash

Correzioni, suggerimenti? Lascia un commento nell'apposita area qui di seguito o contattami privatamente.
Ti è piaciuto l'articolo? Offrimi un caffè! ☕ :-)

L'articolo potrebbe non essere aggiornato

Questo post è stato scritto più di 5 mesi fa, potrebbe non essere aggiornato. Per qualsiasi dubbio ti invito a lasciare un commento per chiedere ulteriori informazioni! :-)

Condividi l'articolo con i tuoi contatti:
Exit mobile version