Phenquestions
Perché, anche se ti attieni alle versioni Long Term Support (LTS), le distribuzioni Linux sono spesso fondamentalmente più a rischio rispetto alle macchine Windows di andare - improvvisamente e clamorosamente - fuori mercato.
Perché, in così tanti casi, è così??
- La compatibilità hardware, anche per componenti essenziali come le GPU, rimane una sfida significativa con molti fornitori che ancora non supportano le distribuzioni Linux, lasciando alla comunità il compito di creare soluzioni alternative;
- Il modello finanziario dell'open source non incentiva, né tanto meno richiede, approfonditi processi di QA;
- E per coloro che stanno al passo con i rilasci all'avanguardia, le modifiche fondamentali agli strumenti di gestione dei pacchetti hanno la brutta abitudine di talvolta murare il sistema aprendo un vaso di Pandora irreparabile di errori di dipendenza. Ripararli, anche quando possibile, può comportare l'abbattimento di tane di coniglio lunghe giorni. Quella che potrebbe sembrare una buona esperienza di apprendimento per un utente alle prime armi può diventare una frustrazione da capogiro per un utente veterano sull'orlo del passaggio a Windows.
E il problema della stabilità di Linux ha fatto infuriare molti utenti. Sfoglia molti thread di utenti in difficoltà su AskUbuntu.com e ti imbatterai in un sacco di poster frustrati che hanno provato di tutto e alla fine hanno deciso che l'unico modo per andare avanti è installare da zero.
Sebbene ciò possa inizialmente essere una sorta di processo di apprendimento, incoraggiando gli utenti a ripensare periodicamente a come rendere il loro sistema più snello e semplificare il processo di ripristino, dopo un po' diventa niente di meglio che un grosso fastidio che fa perdere tempo. Prima o poi, anche gli utenti esperti più avanzati inizieranno a desiderare la stabilità.
Uso Linux come sistema operativo quotidiano da più di 10 anni e ho subito la mia giusta dose di installazioni pulite indesiderate. Così tanti, infatti, che ho promesso che la mia ultima reinstallazione sarebbe stata la mia ultima. Da allora, ho sviluppato la seguente metodologia. E ha funzionato per mantenere il mio sistema Lubuntu funzionante come il giorno in cui l'ho installato senza una reinstallazione da allora. Ecco cosa faccio.
Considerazioni: di cosa hai bisogno per eseguire il backup??
Prima di decidere una strategia di backup, è necessario comprendere alcuni elementi fondamentali:
- Di cosa hai bisogno per eseguire il backup? È necessario eseguire il backup dell'intera partizione/volume o solo della directory dell'utente home??
- Una strategia di backup incrementale sarà sufficiente per il tuo caso d'uso?? O hai bisogno di fare backup completi?
- Il backup deve essere crittografato??
- Quanto è facile che sia il processo di ripristino??
Il mio sistema di backup si basa su una combinazione di metodologie.
Uso Timeshift come sistema di backup principale, che acquisisce istantanee incrementali. E tengo un backup completo del disco sul sito che esclude le directory che non contengono dati utente. Relativi alla radice del sistema questi sono:
- /dev
- /proc
- /sys
- /tmp
- /correre
- /mnt
- /media
- /perso+trovato
Infine, tengo altri due backup. Uno di questi è una (reale) partizione di sistema completa per il backup dell'immagine utilizzando a Clonezilla USB dal vivo. Clonezilla confeziona una serie di strumenti di basso livello per replicare le installazioni. E il secondo è un backup completo del sistema fuori sede che carico su AWS S3 circa una volta all'anno ogni volta che ho a disposizione un ottimo uplink di dati.
Opzioni degli strumenti di backup
In questi giorni, la selezione di strumenti che puoi utilizzare è ampia.
Include:
- CLI note come rsync che possono essere scritte e chiamate manualmente come cron job
- Programmi come Déjà Dup, Duplicity, Bacula che forniscono GUI per creare e automatizzare piani di backup su server di destinazione locali o fuori sede, inclusi quelli gestiti da comuni provider di cloud
- E strumenti che si interfacciano con servizi cloud a pagamento come CrashPlan, SpiderOak One e CloudBerry. L'ultima categoria include servizi che forniscono essi stessi spazio di archiviazione cloud a basso costo, quindi l'offerta è totalmente end to end.
La regola del 3-2-1
Darò una rapida panoramica degli strumenti che sto attualmente utilizzando sulla mia macchina principale.
Sebbene abbia scritto alcuni script Bash per ottenere i file di configurazione essenziali nel mio archivio cloud principale, che utilizzo per i file quotidiani, questo componente (essenziale) del mio piano di backup esegue semplicemente il backup dell'intera macchina, comprese le macchine virtuali e il sistema file che dovrebbero essere tralasciati o sottoposti a backup separatamente in approcci più sfumati.
La sua premessa centrale è l'aderenza alla regola di backup 3-2-1. Questo approccio dovrebbe mantenere i tuoi dati, incluso il tuo sistema operativo principale, al sicuro in quasi tutti gli scenari di errore.
La Regola afferma che dovresti mantenere:
- 3 copie dei tuoi dati. Dico sempre che questo è un nome un po' improprio perché in realtà significa che dovresti mantenere la tua origine dati primaria e due backup. Lo definirei semplicemente "due backup"
- Queste due copie di backup devono essere conservate su supporti di memorizzazione diversi. Riportiamo questo in termini semplici di home computing. Potresti scrivere un semplice script rsync che (incrementalmente) copi il tuo SSD principale in un altro supporto di archiviazione collegato - diciamo un HDD collegato alla prossima porta SATA sulla tua scheda madre. Ma cosa succede se il tuo computer prende fuoco o la tua casa viene derubata?? Saresti lasciato senza la tua fonte di dati principale e senza backup. Invece, puoi eseguire il backup del tuo disco primario su un Network Attached Storage (NAS) o semplicemente usare Clonezilla per scriverlo su un disco rigido esterno.
- Una delle due copie di backup deve essere archiviata fuori sede. I backup fuori sede sono fondamentali perché, in caso di un evento naturale catastrofico come ad esempio un'inondazione, l'intera casa potrebbe essere distrutta. Meno drammaticamente, un grave evento di sovratensione potrebbe friggere tutta l'elettronica collegata in una casa o tutti quelli su un particolare circuito (ecco perché mantenere uno dei backup in loco scollegato da un alimentatore ha senso - un esempio potrebbe essere un semplice HDD/SDD esterno ).Tecnicamente, "fuori sede" è ovunque sia una posizione remota. Quindi potresti usare Clonezilla per scrivere in remoto un'immagine del tuo sistema operativo sul tuo PC di lavoro o su un'unità collegata ad esso, su Internet. Al giorno d'oggi, l'archiviazione cloud è abbastanza economica da installare in modo conveniente anche immagini di unità complete. Per questo motivo, eseguo il backup completo del mio sistema, una volta all'anno, su un bucket Amazon S3. L'utilizzo di AWS offre anche un'enorme ridondanza aggiuntiva.
La mia implementazione di backup
Il mio approccio ai backup si basa su alcune semplici policy:
- Voglio mantenere le cose il più semplici possibile;
- Voglio darmi la massima ridondanza che posso ragionevolmente ottenere;
- Voglio, come minimo, seguire la regola del 3-2-1
Quindi faccio come segue.
- Conservo un'unità aggiuntiva sul desktop che viene utilizzata esclusivamente per ospitare Timehsft punti di ripristino. Perché gli dedico un intero disco, ho un bel po' di spazio per giocarci. Tengo un backup giornaliero, mensile e settimanale. Finora, Timeshift è tutto ciò di cui avevo bisogno per riportare il sistema indietro di alcuni giorni a un punto prima che qualcosa, come un nuovo pacchetto, avesse un impatto negativo su altre parti del sistema. Anche se non riesci a superare GRUB, Timeshift può essere utilizzato come CLI con privilegi di root per riparare il sistema. È uno strumento incredibilmente versatile e utile. Questa è una prima copia in loco.
- Conservo un'unità aggiuntiva sul desktop che viene utilizzata esclusivamente per ospitare le immagini Clonezilla della mia unità principale. Poiché queste immagini mi sarebbero davvero utili solo nel caso in cui Timeshift fallisse, le prendo solo una volta ogni tre-sei mesi. Questa è una seconda copia in loco.
- Usando Clonezilla, creo un disco rigido aggiuntivo che tengo a casa esterno al PC. Tranne che, per questo disco rigido, utilizzo un backup del dispositivo piuttosto che un backup dell'immagine del dispositivo come nell'immagine precedente, in modo che sarebbe bello andare istantaneamente se il mio disco principale fosse in muratura. Se dovessi eseguire il ripristino dall'unità di backup Clonezilla interna, ad esempio, dovrei prima seguire un processo di ripristino. Supponendo che gli altri componenti del sistema funzionino correttamente a seguito di un guasto del disco rigido, in teoria avrei solo bisogno di collegare questa unità alla scheda madre per iniziare a utilizzarla. Questa è una terza copia in loco.
- Infine, una volta ogni sei mesi circa, carico un'immagine del mio sistema generata da Clonezilla su AWS S3. Inutile dire che questo è un lungo caricamento in più parti e deve essere effettuato da una connessione Internet con un buon collegamento di caricamento.
Complessivamente, il mio sistema prevede tre copie in loco e una copia fuori sede del mio desktop principale.
Principali da asporto
- Tutti gli utenti Linux dovrebbero disporre di solide strategie di backup
- La regola di backup 3-2-1 è un buon metro per garantire che i tuoi dati siano al sicuro praticamente in tutte le circostanze.
- Uso una combinazione di Timeshift e Cloudzilla per creare i miei backup anche se ci sono molte altre opzioni, comprese quelle a pagamento, sul mercato. Per lo storage nel cloud, utilizzo un semplice bucket AWS S3, anche se, ancora una volta, ci sono servizi integrati che includono sia software che strumenti di storage.
