Transcription
La volta scorsa abbiamo installato Proxmox sulla Zim board e da qua in poi cominciamo a installare i nostri servizi. Il primo servizio che andiamo a installare oggi è il servizio di backup, perché vogliamo fare un backup come si deve, sensato, con la regola 3-2-1, di cui ne ho già parlato in un altro video in passato.
E oggi facciamo il backup a partire dal PC. Vogliamo che avvenga tutto in automatico, con cadenza regolare e senza saltare mai un backup. Abbiamo uno o più PC che vogliamo sottoporre a backup, quindi installiamo un bel server di backup e, a sua volta, il server di backup farà una bella sincronizzazione in cloud. Però di notte, così non mi consuma la banda quando mi serve durante la giornata. Io qui non uso i dischi SSD che vi ho fatto vedere prima per tenere i backup dei PC, perché quello è un po' spazio sprecato. Quindi, alla mia Zim board, tramite un modulo di espansione, ho montato tre dischi rotazionali che ho recuperato da vecchi portatili, tutti e tre da 500 GB. Li ho messi in RAID 5 e la capienza che vado a raggiungere è 1 TB, con la possibilità di fallimento di un disco, che è più che ragionevole per un backup che poi viene anche sincronizzato in cloud. Non ce ne sarebbe neanche così tanto bisogno. Comunque, questa è la parte che facciamo oggi. Più avanti, quando andremo a mettere su altri servizi, tra cui anche il NAS, vedremo come mettere sotto backup anche quei servizi lì e i dati del NAS, ovviamente.
Dai, basta chiacchiere, mettiamoci all'opera. Questi sono i tre dischi da 500 GB da portatile di cui vi parlavo. Ora configuro questi dischi come da schema, quindi RAID Z1 da destinare a Borg per i backup. Se anche per i backup volete usare i dischi già esistenti, come li abbiamo messi su la volta scorsa, ignorate pure questo passaggio. Ci sono i timestamp qua nella barra di riproduzione. Io quello che faccio è: inizializzo ciascun disco con GPT, poi vado sotto dischi ZFS, crea ZFS. Ora mi elenca i dischi, li seleziono tutti e tre. Questo pool lo chiamo HDD, così mi ricordo che sono i tre dischi rotazionali. Il livello di RAID è RAID Z1, che è l'equivalente, appunto, RAID 5. Premiamo crea e voilà. Questo è dove Borg andrà a mettere i suoi archivi di backup. Però prima dobbiamo installarlo.
Sito di Borg. Tar get Borg backup. Borg 1.2, che è la versione stable. Come si fa ad installarla? Sono supportate un po' tutte le distribuzioni. Diciamo che ci piace Debian. Creo un container Debian, quindi nome dell'host: Borg backup. Password. Andiamo avanti. Template Debian 11 e facciamo di to 16 GB, giusto per non essere troppo braccini. Però gli andiamo subito a creare anche un volume in cui lui possa mettere i suoi archivi. Stavolta il volume corretto, che lo vado a mettere sugli HDD meccanici. Il punto di montaggio: Borg archives. Però, o mettiamo il backup per questo lavoro qua, perché sarà un volume bello grosso e lo backuppiamo in cloud separatamente. Questo ci arriveremo più avanti. Però, quando facciamo il backup dei container, questo è come lavoro io. Faccio backup effettivamente solo del container. I volumi che associo ai container, poi li andiamo ad associare in un modo per cui li li backuppiamo separatamente. Ok, questo lo dobbiamo cambiare perché non vogliamo solo 8 GB. Dovrebbero essere circa 1000. Penso che il pool sia un po' meno. Ma tra le opzioni di mount, no exec non guasta, no atime, tanto non ci serve, oppure no suid. Diamogli un core. Boh, sì, schiatti la sta macchina, almeno 1 Gig di RAM. Però vabbè, gli servono IP. Io sapete che lo do pari l'ID che do al container, quindi 100. Bene, così.
Ora, prima di avviarlo, vado a modificare un paio di cose, come al solito. Tipo, avvia al boot? Sì. Quindi lo vado ad avviare. Root password che abbiamo specificato prima. APT update and APT upgrade and APT install -y Borg backup, come da istruzioni della guida ufficiale. Nel frattempo, ho cambiato idea su come voglio che si chiami sto punto di mount. Un dettaglio minore, ma da adesso in poi ci riferiamo con un altro nome, perché lo vado a cambiare. Voglio chiamarlo Borg repos, perché tecnicamente, nel linguaggio di Borg, questi si chiamano repository, repository di backup. C'è un reboot. La prima cosa che devo fare è abilitare SSH, perché Borg utilizza SSH per fare i suoi backup tra client-server. System CTL enable --now SSH. Poi aggiungo un utente che sarà dedicato all'uso di Borg. Quindi, add user Borg, full name bla bla bla. Corretto? Sì. E adesso posso collegarmi come utente Borg al container. SSH Borg, l'indirizzo IP di questo container. Connetti. Yes. Perfetto, perché la prossima cosa che vado a fare è abilitare l'autenticazione tramite chiave SSH.
Prima creo una chiave SSH a questo scopo. Quindi, sono di nuovo sul terminale del mio PC. SSH-keygen. Come vuoi che si chiami? RSA Borg backup. La creo senza password, perché non ho intenzione di usarla per nient'altro. E poi vediamo come metterla in sicurezza anche dal lato server, proprio. Ok, la chiave è stata creata e adesso quello che faccio è SSH-copy-id -i è specifico proprio questa chiave che ho appena creato Borg@192.168.1.100. No, niente. Sei in cappo, che questa chiave non è corretta. E ma grazie. Oh, a devo ancora copiare con SSH-copy-id, era quella l'idea. Proviamo a forzare con identity-only. Yes. Ok, almeno adesso mi chiede la password. Grazie. Ci siamo. Presumibilmente, adesso mi dovrebbe bastare fare questa roba qua, specificando però l'identity file. E voilà. Vedete, sono dentro con una shell valida, senza mettere nessuna password. Questo è pericoloso. Quindi, quello che voglio andare a fare è vado a modificare il file authorized_keys sotto SSH, che effettivamente è la mia chiave pubblica che ho appena creato. Soltanto che adesso non ha restrizioni. Adesso noi gli andiamo a dire che con questa chiave qua può soltanto usare Borg per uno specifico caso d'uso. Oltretutto, in modo che comunque, se qualcuno dovesse entrare in possesso di questa chiave, più di fare backup con Borg, non dovrebbe poter fare. All'inizio, prima di tutto il resto, vado a inserire command=borg serve, restrict to Borg repos. Chiudo la virgoletta. No pty, no agent forwarding, no port forwarding, no x11 forwarding, no user-rc. E poi tutto il resto. Salvo ed esco. E questa chiave qua, in teoria, al prossimo login, non dovrei essere in grado di utilizzarla per fare. Vedete, non mi è stata allocata una pty. Così è più sicuro, insomma. Questa, fra l'altro, non è una roba che mi sono inventato, non è neanche troppo, in teoria anche in pratica, perché è scritta nella wiki di Borg.
Nel container avevamo dato come punto di montaggio /Borg repos per Borg. Quindi, andiamo a vedere come sta messo. LS -la, anche con la D. Questo fino a pochi minuti fa apparteneva a root. Però io, mentre non registravo, perché sono un po' sbadato oggi, avevo cambiato i permessi, perché così Borg ci può scrivere dentro. In questo modo, con CHown, insomma, non avremo problemi. Infatti, infatti, adesso siamo già pronti a scaricare, installare Vorto. Fatelo pure come vi pare, dai repository della vostra distro, tramite Snap, Flatpak, è semplicissimo. Quella parte non la copre, è davvero banale. E andiamo a impostare il nostro repository. Vado a inizializzare una nuova repository e qui vuole l'indirizzo a cui crearla. Guardate il formato è username@host: il nome del repo. Quindi, in questo caso, sarà Borg@192.168.1.100: e qua gli metto proprio il percorso completo, quindi /Borg-base/repos e poi master, ad esempio, lo chiamo così, perché è il nome del mio hostname. Vado a creare una password e poi qua sotto avanzate c'è la possibilità di cifrare i nostri backup con diversi metodi. Per altro, in questo caso, stiamo creando dei backup locali, cioè non stiamo andando a fare backup su un host estraneo, esterno, in un'altra rete, a cui hanno accesso altre persone. Quindi, non c'è veramente bisogno di cifrare i dati. Tanto sono non cifrati anche sul mio PC, ed è lo stesso livello di accesso. In questo caso, teniamo le cose semplici. Quando sarà il momento di sincronizzarli in cloud, durante la notte, li cifri al volo mentre li carichiamo con rclone. Vediamo dopo. Qua metto cifratura nessuna. Loro lo sconsigliano, ma noi sappiamo meglio che cosa vogliamo fare. E soprattutto, la chiave SSH che utilizziamo per l'autenticazione, l'abbiamo creata prima. Si chiama ID_RSA_Borg_backup. Andiamo ad aggiungere. Voilà, ha aggiunto tutto quanto correttamente. Non so se avete sentito, sono partiti i dischi meccanici. E effettivamente, me l'ha aggiunto senza errori. Quindi, a questo punto, mi manca soltanto di dirgli che cosa voglio sottoporre a backup. Ad esempio, aggiungo una cosa a caso, non so, la cartella Pictures, pesa solo 1.6 GB. Specifichiamo una pianificazione, ad esempio, ogni 4 ore e 0 minuti, e ogni tre settimane validi i dati. Richiede un po' di tempo, per quello non lo fa spesso. E poi facciamo anche che sfoltisce i vecchi archivi dopo ogni backup. A tal proposito, intanto applichiamo. Sotto la tab archivi, abbiamo anche le opzioni di pulizia degli archivi. Di default, lui manterrebbe due backup orari, sette giornalieri, quattro settimanali, sei mensili e due annuali. A me può anche star bene così, per il momento non lo vado a cambiare. Sotto vari, poi mostra una notifica quando le attività di background falliscono, ma vi sconsiglio la notifica di backup avvenuto con successo, perché poi vi abituate e non capite più la differenza. Altra cosa, altrettanto importante, è far partire Vorto all'avvio del PC. Cominciamo il backup. Nel frattempo, vediamo a che velocità sta inviando roba. 60, 70, 80. È veloce, insomma, c'è una gigabit. E voilà, terminato. Se torniamo un attimo qua sopra, dovremmo poter vedere i file che sono effettivamente stati backuppati. Guardate, sotto Borg_repos, c'è master. Dentro a master, c'è un po' di roba che serve a lui, e poi la cartella data. Andiamo a vedere dentro a data. Zero. Ok. E poi, poi, 1, 2, 3, 4, 5, 6. Che cos'è sta roba? È il formato in cui lui organizza i dati. Però i dati sono spezzati in chunk da 500 MB o meno, se non ci arriva. Se io faccio un backup, modifico i file sottoposti a backup e faccio un altro backup, lui non torna a modificare la vecchia roba, va a creare dei nuovi chunk, sempre di dimensioni, insomma, variabili, contenenti soltanto le differenze rispetto all'ultimo snapshot. Questo per l'object storage è perfetto. Comunque, diago, andiamo avanti.
Morro, ma non ci hai fatto vedere come si ripristina da un backup. Adesso ve lo faccio vedere. Qua sotto immagini, elimino tutto quanto, senza passare dal cestino. Bom. Come faccio a ripristinare sta roba? Beh, è semplice. Sotto agli archivi, prendo quello più recente, poi vedete qua c'è un menù monta, dove mi pare. In realtà, creo una cartella, la bisogna Restore, e dico, boh, qua dentro. Montato correttamente. Quindi, se ora apro Restore, ecco che c'è il percorso completo. E voilà. E niente, quindi da qua me li posso copiare e me li vado a incollare dove dovrebbero essere. Quindi, qua dentro. Bom. E adesso posso smontarmi. Non è così difficile.
L'ultimo tassello è caricare questi backup in cloud durante la notte, ovviamente, quando non darebbe fastidio a nessuno. Ma a tal proposito, ce ne sono davvero tanti di servizi di object storage che ti danno tanti giga per caricare una marea di dati. Il problema è che hanno dei costi un po' strani. Ci sono quelli che costano abbastanza poco al giga, ma poi ti salasso quando tiri fuori i dati perché ti servono, che non è ideale. Ci sono quelli che ti fanno pagare qualcosina per caricare i dati e qualcos'altro per tenerli su. Ci sono quelli che bla bla bla. E ci sono diverse voci di costo nascoste. Tant'è vero che a volte risulta veramente difficile prevedere con esattezza quanto andremo a spendere. Io per questo progetto ho scelto it, lo sponsor di questo video, che è il primo provider europeo di cloud storage geodistribuito. Cabbit è una realtà tutta italiana, peraltro. Ad oggi, dopo aver costruito una rete di oltre 5.000 clienti in più di 70 Paesi nel mondo, ha lanciato il suo primo cloud storage geodistribuito esclusivo per le aziende italiane. Il nuovo servizio conta già più di 100 aziende, tra cui spiccano nomi noti che tutti conosciamo, come Amadori e Bologna Airport. Perciò, se sei un IT manager o in generale lavori nel reparto IT nella tua azienda, orecchie aperte perché potrebbe interessarti. L'idea alla base è semplice: invece di mettere i nostri dati in data center centralizzati in mano alle big tech ed essere in balia di single point of failure e piani tariffari costosi e imprevedibili, li cifriamo al volo e li carichiamo in un cloud collettivo, dove vengono spezzati, duplicati e distribuiti su più nodi della rete per garantire ridondanza e affidabilità. Chi sono i nodi della rete? Siete voi, sono io, insomma, gli utilizzatori stessi del servizio prestano una piccola parte delle proprie risorse hardware, entrando a far parte di questa rete peer-to-peer e ospitando piccoli frammenti di dati di altri utenti. Quando ho letto il funzionamento, la prima cosa che ho pensato è stata: "Ok, che succede se scollego il mio nodo e resto in silenzio?". Posso sentire in lontananza le madonne di qualche utente che ha perso il backup? In realtà, no. Possiamo stare tranquilli. Come dicevo, tutti i frammenti sono duplicati un certo numero di volte e se un certo nodo va offline, l'algoritmo crea subito nuove copie per mantenere lo stesso livello di ridondanza. Grazie a questo sistema, Cabbit è in grado di garantire il più alto standard di mercato in termini di availability dei dati, pari al 99,95%, e di durability pari ai gergali 11 nove, oltre a ridurre significativamente il carbon footprint dovuto all'uso dei tradizionali data center centralizzati. E tutto questo all' 80% in meno rispetto al costo dell'object storage di Amazon S3. La parte migliore: questo è un servizio di object storage S3-compliant, VIMs, Synology, un app, qualunque sia il tuo workflow, non devi stravolgere nulla. Basta cambiare l'endpoint per collegare facilmente strumenti e integrazioni che già conosci e scegliere tra una marea di integrazioni e servizi compatibili con S3. È sotto la scocca che avviene la magia. PS: ultima nota, si parla tanto di attacchi hacker, ransomware e scatti ultimamente. Ecco, se cerchi una soluzione che ti protegga da tutto ciò, l'object locking e il versioning di Cabbit fanno al caso tuo.
Quindi, vediamo come si configura un servizio per la sincronizzazione dei backup. Sono sulla web UI di Cabbit, dove ho già creato un bucket. Diamo giusto un'occhiata così, per vedere come funziona. Io comunque posso vedere tutti i file, così come farei su un servizio in stile Dropbox. Così, anche a colpo d'occhio, mi rendo conto se va tutto bene, se i dati sono stati caricati. Poi ci sono altri modi un po' più scientifici di controllare che tutto quanto sia ok. Ed eccoli qua, appunto, i vari file. Ora creo un altro bucket, quindi create bucket e lo vado a chiamare Borg_Master. Ed eccolo qua. A questo punto, lo voglio sincronizzare con rclone. Quindi, seguo la guida ufficiale di Cabbit per la sincronizzazione su rclone, che per la cronaca è ben documentata, così come per tutte le altre integrazioni e software possibili. E questo test lo sto facendo in locale sul mio PC, in una cartellina apposta che vado a creare, perché ovviamente, per testare questa soluzione, ho già configurato un endpoint Cabbit su rclone sulla mia Zim board. Quindi, vi faccio vedere su un computer su cui non ho già sincronizzato. Rclone config. Dopo aver installato rclone, ovviamente, voglio dirgli di creare un new remote. E inseriamo un nome: Cabbit. A questo punto, ci chiede quale tipo di storage vogliamo utilizzare. E ci sono diversi tipi di storage, pure Samba, chips, HTTP, FTP, Dropbox, Google Drive, eccetera, eccetera. Rclone è un software molto potente per fare questo genere di cose. Noi stiamo usando un object storage Amazon S3 compliant. Quindi, la nostra selezione è 5. A questo punto, ci dice qual è il servizio specifico che stai utilizzando. Qua ce ne sono solo alcuni, oppure 25 per qualunque altro servizio. Quindi, facciamo 25. Ci vengono chieste le credenziali. Uno, per inserirle ora. E a questo punto, dobbiamo inserire la Access Key ID. Dove la troviamo? Ovviamente, nella web UI, sotto API Keys. Posso andare a creare una nuova Access Key, ad esempio, la chiamo rclone_master e la vado a inserire qua dentro. E poi il segreto, che è quello sotto. Me lo copio, lo vado a incollare qua sotto. Ed è arrivato il momento di specificare l'endpoint. S3.com. Avanzate. Mettiamo no default. Quindi, diamo invio vuoto e la configurazione è completata. Premiamo ancora invio per confermare. E questi sono i remote che ho configurato. Ora, a Cabbit, in particolare, fa tutta la cosa della cifratura al volo, spezzetta e tutto quanto. Quindi, non ci dovrebbe preoccupare più di tanto la cifratura. Tuttavia, se usiamo un altro servizio di object storage, oppure vogliamo comunque essere sicuri di farla noi la cifratura prima di caricare e quant'altro, e avere le chiavi in mano e tutto quanto, nessun problema, perché a questo punto possiamo configurare la cifratura al volo mentre carichiamo su questo endpoint. Ora vi faccio vedere tutto ciò che devo fare è aggiungere un nuovo remote. Il nome per questo remote, ad esempio, Cabbit_crypt. Il tipo di remote, che in questo caso è proprio crypt. E a questo punto, dobbiamo specificare la location. In questo caso, possiamo scrivere, visto che l'abbiamo creato prima, Cabbit: e poi il nome del bucket Borg_Master. Qui possiamo scegliere se cifrare i nomi dei file, oppure semplicemente ofuscarli o non fare niente di tutto questo. Diciamo di essere veramente estremisti, quindi facciamo uno per cifrare anche i nomi dei file. Stessa cosa per le directory. Vogliamo cifrare oppure no? E sì, vai, cifra anche i nomi delle directory. E a questo punto, la parte importante, dobbiamo generare, oppure far generare a lui, una password casuale. Questa qui ce la dobbiamo salvare in un posto sicuro, perché è l'unica cosa che ci permetterà di decrittare i file quando li vogliamo scaricare. Quindi, facciamo G per farla generare a lui. Quanto la vuoi lunga? 64, 128 o 1024. Dice che 128 è già sicuro, ma facciamo che siamo estremi, 1024 bit. Via, la tua password è questo qua. Me lo segno da qualche parte. Va benissimo un file di testo su più chiavette o hard disk, che però siano disegnate a quello e al sicuro. E ci viene chiesta una seconda password per il salting, che è opzionale ma raccomandata. Premo G per generarla casualmente. 1024. Siamo veramente overkill. Non vogliamo fare altro, quindi diamo invio. Premiamo un'altra volta invio per confermare. A questo punto, su rclone, abbiamo due entry point. Guardate, Cabbit di tipo S3, e se usiamo questo qui, i dati vengono caricati in chiaro. Sarà poi il servizio, in questo caso Cabbit, a occuparsi di tutto il resto. Oppure Cabbit_crypt, che utilizza questo qui, ma prima va a cifrare i dati, quindi gli arrivano già cifrati. Esco dalla configurazione. A questo punto, vediamo se tutto funziona correttamente. Faccio una cartella di prova, Morro Linux, al suo interno creo un file chiamato, non lo so, morro_linux.txt, che fantasia. Dentro a questo file, ci vado a scrivere: "Visit morrolinux.it per trovare il corso che fa per te". Dentro a Morro Linux, morrolinux.it. Quindi, abbiamo questa roba qua. E a questo punto, vogliamo sincronizzarlo su Cabbit, in questo caso. Quindi, rclone sync -P il percorso interessato, quindi la cartella corrente, e poi l'endpoint, quindi Cabbit per farlo in chiaro, o Cabbit_crypt per farlo cifrato, due punti, Borg_Master, perché poi questo qua era il nome che avevo scelto. Ora dovrebbe caricare tutto quanto in maniera cifrata. Tutto quanto, un file e una cartella, a tutti gli effetti. Eccolo qua, ci ha messo veramente poco. Vediamo dalla web UI che cosa è stato caricato. Questo è il bucket che ho appena creato. Effettivamente contiene una cartella con nome offuscato, che contiene un'altra cartella con nome offuscato, che contiene un file col nome offuscato, e il contenuto del file è cifrato. F. Ora è chiaro che io questa roba qua la devo poter leggere. Quindi, come faccio ad aver conferma che effettivamente i miei dati sono cifrati per tutti tranne che per me? Vado qui sopra e anziché rclone sync, uso rclone LS, ad esempio, per elencare i file. E vedete che in realtà elenca i file in questo bucket, e il nome è in chiaro, così come sarà in chiaro anche il contenuto se cerco di aprirlo. Vi faccio vedere una cosa fighissima. Uso rclone mount per montare questo bucket come se fosse un disco di rete. Diciamo che so, magari mi crea una cartella dentro a tmp/cabbit, così giusto per vedere un attimo al volo. Poi faccio rclone mount, indirizzo del bucket, ovviamente, e poi dove lo voglio montare, tmp/cabbit. Diamo invio e a questo punto lui rimane collegato con il cursore bloccato. Va bene così. Se apro un file manager e mi sposto dentro a tmp, qua dentro, guarda, dentro la cartella cabbit, ho il contenuto del bucket esplorabile in locale. Fantastico. E la cosa più di tutte è che io qua dentro ci posso andare a scrivere, lo posso trattare come mi pare. Guardate, ora io vado a creare un file, non so, una cartella, quello che voglio, un file. Facciamo "Ciao". Cioè, ovviamente non sono solo file di testo, posso andare a creare qualsiasi cosa. Ci vado a scrivere dentro, qualsiasi cosa. Prova. Ok, perfetto. Salvo ed esco. Ora, ovviamente, per questo tipo di utilizzo, lo vedete anche Kate che rimane un attimo bloccato, non è così che sarebbe pensato per essere usato, perché questo è object storage. L'object storage funziona che tu, quando fai una modifica a un file, lui ricarica l'intero oggetto. Questo sarebbe il concetto alla base. Poi ci sono delle varianti che lasciamo perdere i dettagli tecnici, tecnicismi, in cui questa cosa può essere migliorata, ma concettualmente funziona così. Quindi, non è pensato per un uso interattivo come questa maniera. Però, se fate lettura, avete proprio bisogno di accedere alla copia offsite, proprio nel malaugurato caso in cui ne abbiate bisogno, potete montarlo semplicemente in questa maniera e passarlo come directory repository. Lo chiama lui di Borg, quindi io dico a Borg: "Questo, questa cartella qui, dove ho montato il bucket, è il tuo repository". E poi con vorta, il programma che vi ho fatto vedere prima, vado a interrogare Borg: "Quali sono i miei backup?". Lui mi elencherà tutto quello che c'è sul cloud e farò il ripristino.
Prima di concludere, vediamo come sincronizzare i backup in cloud di notte. Ho creato un semplicissimo script chiamato rclone_borg_sync, in cui imposto come sorgente il percorso dove Borg va a scrivere i propri repository. Tenete conto che questo script gira sul host, su Proxmox, quindi lui ha accesso a tutti i volumi utilizzati dai container. Questo qui non me lo sono inventato. Se ci fate caso, nelle proprietà, nelle risorse, in realtà del container di Borg backup, avevamo aggiunto un punto di montaggio e l'avevamo creato sul pool HDD, e si chiama sub-100-disk-0. Da Proxmox accedo al contenuto di questo disco qua, in questa maniera qua, è nella root, si chiama nome del pool SL nome del file system. Infatti, come controprova, se guardo qua dentro, ci vado a trovare il repository, e poi qua dentro ci trovo appunto la classica struttura che vi ho già fatto vedere, bla bla bla. Il resto l'abbiamo già visto. Rclone sync dalla sorgente che abbiamo impostato alla destinazione che abbiamo impostato, e poi gestisce gli errori, ovvero, se l'ultimo comando eseguito ha un codice di errore uguale a zero, tutto è andato bene, e quindi scriviamo solo "backup ok". Altrimenti, mi manda una mail con qualche dettaglio in più. Questo esegui di notte, così la mattina mi vedo la mail se qualcosa è andato storto, e dico "ah, qualcosa da guardare". Vediamo che succede comunque vada. Se finito tutto quanto è ancora notte, quindi sono meno delle 9 del mattino, che per, per la cronaca, è l'orario in cui ho programmato l'accensione automatica della Zim board dalle impostazioni del BIOS. Sì, si può fare anche questo. Beh, se sono meno delle nove, spegniti per risparmiare energia, tanto poi alle 9:00 lui si riaccende. Ovviamente, questo script non tiene conto di se ci sono download o altri programmi di backup in esecuzione. Quindi, occhio a fare questa cosa. Io adesso lo faccio in questa fase, perché non ho altre cose che girano di notte, ma come vedremo in uno dei prossimi video, espanderò abbastanza la cosa per fare i backup anche dei volumi che stanno sul NAS, intendo quelli che condivido in rete, proprio quelli che stanno sul due SSD che ho messo in RAID, perché come ho già detto diverse altre volte, e nel video stesso che vi lascio qui, il RAID non è un backup. Ripetete insieme a me: il RAID non è un backup. Il RAID non è un backup. Teoricamente, potrei fare il backup anche di quei dati, sempre con Borg, sempre alla stessa maniera, però sto ancora sperimentando su quale sia l'approccio migliore per fare il backup degli snapshot delle macchine virtuali e dei container che girano su Proxmox, dei dati che stanno qua sopra sul NAS, e qualche altra cosa. Quindi, penso che cercherò di utilizzare lo strumento più adatto ad ogni scopo, anche se potrei usarne uno per tutti. Vediamo come andrà a finire questo. Sicuramente non sarà l'ultimo video sui backup, perché poi vi devo far vedere un sacco di altre cose fighissime che ho scoperto sui backup con Proxmox. Comunque, tornando a noi, io questa roba qua, questo script, lo mando in pianificazione da /etc/cron.tab, classico metodo. Tutti i giorni a mezzanotte. Ripeto, fate attenzione soltanto a non spegnere la macchina. Nel nostro, nel vostro caso, se durante la notte eseguite anche altri job. Comunque, questo script posso anche lanciarlo manualmente ora, come ora, per verificare che tutto funzioni correttamente e che stia caricando i miei backup nella nuvoletta di Cabbit. E questo potrebbe richiedere un po'. E nell'attesa, io qui dovrei poter vedere il bucket che si popola con i repository di Borg. Ovviamente, ho scelto di caricare tutto quanto cifrato, quindi non sarà in grado di vedere i nomi in chiaro. Sappiamo benissimo che questa è la cartella data, perché il repository di Borg ha questa struttura. Questa è la cartella zero. Ok, ricordate, questi sono tutti chunk che attualmente non sono ancora stati popolati. Tutto sembra funzionare correttamente. Abbiamo testato il backup di una cartella sulla nostra Zim board, abbiamo testato la replicazione di questo backup offsite con un servizio di object storage, nello specifico Cabbit, e ovviamente abbiamo testato il ripristino da Borg con Vorto. Quindi, si chiude il cerchio. E complimenti, se avete seguito passo passo, avete appena implementato la vostra procedura di backup 3-2-1. Procedura testata, documentata, replicata, funziona. Perfetto. Non sono sicuro che avesse senso l'ultima frase che ho detto, però stanotte mi sono addormentato alle 6:00 del mattino e mi sono svegliato alle 9:00. Quindi, mettete un bel like, condividete, fate le solite cose che si fanno sui social per supportarmi, perché ora vado a letto. [Musica] Ciao. Oh. [Musica]