TL;DR
L’articolo comincia con uno sproloquio sui miei rapporti problematici con i backup, potete saltarlo e andare qua.
TL;DR - bis
Questo articolo non vuole essere una guida esaustiva di come impostare tecnicamente il backup, non troverete comandi o script. Solo una descrizione di come ho organizzato io la faccenda.
Durante il mio peregrinare informatico una cosa è rimasta pressochè costante:
La mia gestione dei backup è vergognosa.
Alla veneranda età di molti anni e dopo aver perso un discreto numero di dati qua e la mi sarei anche rotto i coglioni di essere così asino nella gestione di una fase importante dell’informatica come il backup dei dati. Per questo ho deciso di provare a sistemare le cose e scrivere questo articolo.
Alla base di tutto questo disagio da archiviazione ci sono tre pilastri fondamentali:
- Sono un cretino
- Gli hard disk mi odiano
- Un mix dei due
Sono un cretino
Fulgido esempio sono i miei frequenti formattoni per ripulire il PC e installare da capo il sistema operativo: puntualmente perdevo pezzi per strada e tanti saluti a qualcosa di presumibilmente importante.
Soluzione
Ho smesso di installare nuovamente il sistema operativo ogni mese.
Gli hard disk mi odiano
Il concetto non si limita solo agli hard disk ma a qualsiasi pezzo di elettronica in grado di memorizzare dei dati. Tendo ad avere un rapporto amore/odio con questi dispositivi. Ogni tanto mi lasciano a piedi senza tante spiegazioni.
Esempio pratico: tanti anni fa, torno da un viaggio con tante belle foto nella Compact Flash (si sono vecchio), attacco felice il card reader al PC e successivamente la Compact Flash al lettore. Per qualche motivo qualcosa non funziona e la Compact Flash, che due minuti prima funzionava correttamente nella macchina fotografica, è illeggibile. Scatta il panico e il piantino (ero giovane ed emotivamente fragile, ora sono solo emotivamente fragile), non avevo idea di come gestire la cosa. Per fortuna esiste mio padre che suggerì di usare un approccio più razionale e provare a recuperare i dati. Missione riuscita, le foto resuscitano e io sono contento.
PS: ad oggi non so dove siano finite quelle foto, forse perse nuovamente per il motivo numero uno, sono un cretino.
Soluzione
Quando tocco un dispositivo di memorizzazione faccio tutti i movimenti molto lentamente nella speranza che non si spaventi. E con i guanti in nitrile.
Il mix
Il mix è quando prendi un NAS, ci ficchi dentro un HDD ciccione per fare il backup di tutto quello che vuoi e ci copi dentro un tot di file dal tuo PC. Passa del tempo e l’HDD si spacca per un motivo ignoto. Ovviamente tu, tutto fiero del tuo nuovo dispositivo di backup, avevi cancellato dal PC i dati che avevi messo nel NAS.
Le bestemmie volano, i santi si incazzano, qualcosa è stato recuperato, ma non tutto.
Soluzione
L’articolo che sto scrivendo. 🤬
So What?
Riassunte le agonie del passato, dedichiamoci al presente.
Come dicevo pocanzi, mi sono cotto il razzo di perdere dati e vivere con l’ansietta mal celata di perdere tutto se capita una sfiga all’hardware, faccio una cazzata, o qualsiasi altra evenienza. Ho cominciato quindi un percorso personale di formazione tipo monaco shaolin (oppure Goku con i vestiti ultra pesanti), ne sarà valsa la pena? boh, vedremo, sicuramente ho appreso molte cose interessanti.
Quello che ho capito è che per fare un backup dei propri dati serve:
- rovistare nell’internet per trovare cosa funziona e cosa no
- realizzare un piano di backup
- implementare automatismi, un backup senza automatismi non è un backup
Il mio personale trigger per questa rivoluzione copernicana dei backup è stato questo video YouTube di Jeff Geerling (ah… YouTube), un pazzo scatenato che si diletta con RaspberryPi, selfhosting, homelabbing e tante cose nerdoline. Da Jeff ho appreso una verità fondamentale:
Avere una sola copia di backup dei tuoi dati, non è un backup.
Quindi? quante copie dei propri dati servono? una volta fatte le copie, dove le salvo? tenerle sullo stesso dispositivo potrebbe sembrare stupido. Una serie di interessanti domande che trovano una risposta con la strategia di backup 3-2-1, scopriamola in maniera cialtrona.
Backup 3-2-1
Il nome 3-2-1 deriva dal fatto che i numeri identificano effettivamente qualcosa, nello specifico:
- Numero minimo di copie
- Numero minimo di dispositivi di archiviazione
- Numero di copie offsite
3 - Copie
Le copie del tuo file devono essere almeno tre:
- File originale
- Copia 1
- Copia 2
2 - Dispositivi di archiviazione
Le tre copie del tuo file vanno dislocate in almeno due diversi dispositivi:
- HDD del tuo PC
- NAS
Oppure:
- NAS
- Disco esterno
And so on, avete capito.
1 - Copia offsite
Per offsite si intende genericamente una località che non coincide con quella originale/principale.
Una copia di backup va quindi depositata su un dispositivo che non risiede nello stesso luogo fisico delle altre. Questo può essere un server nella cantina dei tuoi genitori, a casa di un amico oppure un server in un qualche datacenter sperso nel mondo.
Il processo di backup
Preso atto che la strategia che voglio seguire è questa benedetta 3-2-1, quali sono gli strumenti che mi permettono di implementarla? dove salvo la roba? chi sono? perchè lo faccio? Una domanda alla volta…
La situazione ferri vecchi divora elettricità in casa è la seguente:
- 1 NAS
- 1 Nodo Proxmox
- 2 RaspberryPi
Il NAS contiene un pò di roba, tutto quello che c’è li dentro è l’unica copia esistente, bella storia (fortunatamente i dischi sono in RAID1 quindi un minimo di protezione esiste). I Raspberry contengono qualche DB, configurazioni varie (DNS, applicazioni, ecc.). Infine, il serverino Proxmox inizia a contenere qualche virtual machine interessante e relativi dati. Niente di tutto quello che ho appena nominato è coperto da backup. Evviva. 🤡
Tutto quello che segue è implementato tramite una serie di script bash e automatizzato con crontab. Ah Linux.❤️
NAS
Per risolvere questa spiacevole situazione l’idea è quella di creare una macchina virtuale in Proxmox, montare al suo interno tutte le cartelle condivise rilevanti del NAS, eseguire un backup incrementale criptato su disco locale di Proxmox tramite quella figata di strumento che è Borg e, infine, sparare tutto su un servizio di storage S3 con Rclone (altro programma atomico). In questo modo dovrei avere almeno tre copie, in due dispositivi diversi, di cui una lontano da qui.
Raspberry e VMs
Un Raspberry e le macchine virtuali su Proxmox invece contengono un pò di applicazioni e una istanza PostgreSQL, tutto più o meno su Docker (perchè sono nabbo).
Per il DB l’approccio è quello di fare un dump tramite riga di comando, salvare il dump compresso in una cartella di rete e, dalla macchina Borg, far partire il backup incrementale e successivo caricamento in S3. Per coordinare le attività dell’host DB e l’host Borg uso dei semplici file semaforo che indicano quando il dump è stato eseguito correttamente e può cominciare il backup con Borg. Un approccio assolutamente basico, del secolo scorso, ma al momento funziona.
Le applicazioni invece richiedono uno step ulteriore, vanno stoppati i container. Una volta fermati tutti i container si procede come per il DB. Anche in questo caso è tutto coordinato tramite file di semaforo, 1990 style.
Borg e Rclone
Borg e Rclone sono due programmi esagerati, free e open source. Il tipico software che ti fa affiorare la mai sopita sindrome dell’impostore e domandare se è giusto che tu sei pagato per produrre monnezza mentre ci sono tizi che confezionano perle gratuite a beneficio della comunità. Mah.
Borg produce backup criptati (scegliete bene la vostra password), compressi e incrementali. Oltre a questo riesce a gestire in autonomia il ciclo di vita dei backup tramite il comando prune
. Per esempio, gli si può chiedere di tenere 4 backup giornalieri, 1 settimanale, 1 mensile, 1 annuale. Oppure un pò il cazzo che vi pare a voi, gusti son gusti. In questo modo si può personalizzare il profilo di backup sulle nostre esigenze e si ottimizza lo spazio occupato.
Rclone invece è il compagno di merende perfetto per Borg e della strategia 3-2-1, lui “semplicemente” tiene sincronizzate due cartelle, una in locale e una remota in cloud. Finito il backup con Borg, se ne prende carico Rclone e lo carica dove serve a voi.
Entrambi i programmi hanno altre mille funzioni che non so usare. 👍
Storage Detour
Per il servizio storage la scelta è infinita, personalmente ho scelto lo storage Glacier di Scaleway perchè stavo cercando uno storage di tipo S3 dal prezzo contenuto.
Mentre scrivo questo articolo, un backup di 360GB su Scaleway costa 0.69€/mese.
Migliorie
Tutto può essere migliorato, soprattutto quello che faccio io. Quindi ho cominciato a pensare come rendere un pò meno pessimo tutto questo cinema. Magari un giorno aggiornerò questo articolo con le novità.
Sono arrivato alla conclusione che un buon passo in avanti potrebbe essere l’implementazione di un servizio di invio e-mail. Alla fine di ciascun processo di backup lo script invia una e-mail di rapporto per avere facilmente un riscontro che tutto abbia funzionato a dovere.
Integrare l’invio di e-mail in uno script bash dovrebbe risultare abbastanza semplice grazie a sSMTP, un piccolo programma che ha l’unico scopo di inviare e-mail tramite protocollo SMTP. Anche la configurazione del servizio Sendgrid con sSMTP sembra elementare.
Nutro, quindi, una flebile speranza di poter procedere con questa implementazione senza scontrarmi con troppi problemi. Mi accontento di un giusto ammontare di problemi, beata ingenuità.
Backup DB incrementale
Rendere efficiente il backup del DB non è una priorità, al momento il backup pesa 4MB una volta compresso.
Però, però… dire backup incrementale fa sempre figo.
Siccome il DB è un PostgreSQL due ottimi candidati sono Barman e pgBackRest. Al contrario dell’invio delle e-mail automatiche di rapporto, la configurazione di questi due programmi non pare del tutto banale, vanno studiati più a fondo. L’idea stuzzica ma bisogna capire il rapporto costi/benefici.
Prenderà sicuramente del tempo.
Ho finito le cose da dire
Santo cielo quanto ho scritto, e chi se lo aspettava.
La fase di backup dei propri dati è importante, tenere al sicuro da occhi indiscreti questi dati è importante, automatizzare il processo è importante. Tutti punti che possono essere migliorati ed espansi nel tempo ma che è bene cominciare ad affrontare in maniera sistematica anche con un approccio rudimentale. E poi spippolare con script vari è sempre divertente.
Fate sti cazzo di backup. Love and peace. 🌈