Introduzione
I backup sono molto importanti per i server cloud. Che tu stia gestendo un singolo progetto con tutti i suoi dati memorizzati su un unico server, o distribuendo direttamente da Git a macchine virtuali che vengono avviate e disattivate conservando un set minimo di log, dovresti sempre pianificare uno scenario di fallimento. Questo può significare molte cose diverse a seconda delle applicazioni che stai utilizzando, di quanto sia importante avere un passaggio immediato a un’altra risorsa e di che tipo di problemi stai prevedendo.
In questa guida, esplorerai i diversi approcci per fornire backup e ridondanza dei dati. Poiché casi d’uso differenti richiedono soluzioni diverse, questo articolo non sarà in grado di darti una risposta universale, ma imparerai cosa è importante in diversi scenari e quali implementazioni sono più adatte per la tua operatività.
Nella prima parte di questa guida, esaminerai diverse soluzioni di backup e ne valuterai i meriti relativi in modo da poter scegliere l’approccio che si adatta al tuo ambiente. Nella seconda parte, esplorerai le opzioni di ridondanza.
Parte 1 — Qual è la Differenza tra Ridondanza e Backup?
Le definizioni dei termini ridondante e backup spesso si sovrappongono e, in molti casi, vengono confuse. Si tratta di due concetti distinti che sono correlati, ma differenti. Alcune soluzioni forniscono entrambi.
Ridondanza
La ridondanza dei dati significa che vi è un immediato passaggio automatico in caso di problemi del sistema. Un passaggio automatico significa che se un insieme di dati (o un host) diventa non disponibile, un’altra copia perfetta viene immediatamente sostituita in produzione per prenderne il posto. Ciò comporta quasi nessun tempo di inattività percepibile e l’applicazione o il sito web possono continuare a gestire le richieste come se nulla fosse accaduto. Nel frattempo, l’amministratore di sistema (in questo caso, tu) ha l’opportunità di risolvere il problema e riportare il sistema a uno stato completamente operativo.
Tuttavia, una soluzione di ridondanza di solito non è anche una soluzione di backup. Lo storage ridondante non fornisce necessariamente protezione contro un guasto che colpisce l’intero sistema o macchina. Ad esempio, se si ha una configurazione RAID a specchio (come RAID 1), i dati sono ridondanti nel senso che se un disco fallisce, l’altro sarà ancora disponibile. Tuttavia, se la macchina stessa dovesse fallire, tutti i dati potrebbero andare persi.
Con soluzioni di ridondanza come MySQL Group Replication, ogni operazione viene tipicamente eseguita su ogni copia dei dati. Questo include operazioni dannose o accidentali. Per definizione, una soluzione di backup dovrebbe anche consentire di ripristinare da un punto precedente in cui i dati sono noti per essere integri.
Backup
In generale, è necessario mantenere backup funzionali dei propri dati importanti. A seconda della situazione, ciò potrebbe significare eseguire il backup dei dati dell’applicazione o dell’utente, o di un intero sito web o macchina. L’idea alla base dei backup è che, in caso di perdita di sistema, macchina o dati, è possibile ripristinare, redistribuire o comunque accedere ai dati. Il ripristino da un backup potrebbe richiedere tempo di inattività, ma può fare la differenza tra ripartire da un giorno fa e ricominciare da zero. Tutto ciò che non puoi permetterti di perdere dovrebbe, per definizione, essere salvato.
In termini di metodi, ci sono diversi livelli di backup. Questi possono essere stratificati come necessario per tener conto di diversi tipi di problemi. Ad esempio, è possibile eseguire il backup di un file di configurazione prima di modificarlo in modo da poter tornare alle impostazioni precedenti in caso di problemi. Questo è ideale per piccoli cambiamenti che si stanno monitorando attivamente. Tuttavia, questa configurazione fallirebbe in caso di guasto del disco o qualcosa di più complesso. È inoltre consigliabile avere backup regolari e automatizzati su una posizione remota.
I backup di per sé non forniscono il failover automatico. Questo significa che i tuoi guasti potrebbero non costarti dati (supponendo che i tuoi backup siano aggiornati al 100%), ma potrebbero costarti tempo di attività. Questo è uno dei motivi per cui la ridondanza e i backup vengono spesso utilizzati in combinazione tra loro.
Parte 2 — Backup a Livello di File
Una delle forme di backup più familiari è il backup a livello di file. Questo tipo di backup utilizza normali strumenti di copia a livello di sistema di file per trasferire i file in un’altra posizione o dispositivo.
Come Usare il Comando cp
In teoria, potresti eseguire il backup di una macchina Linux, come il tuo server cloud, con il comando cp. Questo copia i file da una posizione locale a un’altra. Su un computer locale, potresti montare un’unità rimovibile e quindi copiare i file su di essa:
Questo esempio monta un disco rimovibile, sdc, come /mnt/my-backup e quindi copia la directory /etc sul disco. Successivamente smonta l’unità, che può essere conservata altrove.
Come Usare Rsync
A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:
-azvP è un set tipico di opzioni di Rsync. Ecco una spiegazione di cosa fa ciascuna di esse:
aenables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the-rlptgoDoptions individually (yes, really). Notably, the-roption tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such ascpandscp.zcompresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.venables verbose mode, so you can read more details of your transfer while it is in progress.Ptells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.
È possibile esaminare altre opzioni di rsync sulla sua pagina man.
Certo, in un ambiente cloud, di solito non si montano e si copiano file su un disco montato ogni volta. Rsync può anche eseguire backup remoti su una rete fornendo una sintassi in stile SSH. Questo funzionerà su qualsiasi host a cui è possibile accedere tramite SSH, purché Rsync sia installato su entrambi i lati. Poiché Rsync è considerato uno strumento fondamentale di Linux, questa è quasi sempre un’ipotesi sicura, anche se si sta lavorando localmente su un Mac o su una macchina Windows.
Questo eseguirà il backup della directory /etc della macchina locale in una directory su remote_host situata in /backup. Questo avrà successo se si ha il permesso di scrivere in questa directory e c’è spazio disponibile.
È anche possibile consultare ulteriori informazioni su come utilizzare Rsync per sincronizzare directory locali e remote.
Come utilizzare altri strumenti di backup
Anche se cp e rsync sono utili e diffusi, non rappresentano una soluzione completa da sole. Per automatizzare i backup utilizzando Rsync, sarebbe necessario creare le proprie procedure automatizzate, pianificare i backup, ruotare i log, e così via. Anche se ciò potrebbe essere appropriato per alcune distribuzioni molto piccole che non desiderano utilizzare servizi esterni, o distribuzioni molto grandi che dispongono di risorse dedicate per mantenere script molto granulari per vari scopi, molti utenti potrebbero preferire investire in un’offerta di backup dedicata.
Bacula
Bacula è una soluzione complessa e flessibile che funziona su un modello client-server. Bacula è progettato con concetti separati di client, posizioni di backup e direttori (il componente che orchestrata il backup effettivo). Configura inoltre ogni compito di backup in un’unità chiamata “job”.
Questo consente una configurazione estremamente granulare e flessibile. È possibile effettuare il backup di più client su un dispositivo di archiviazione, un cliente su più dispositivi di archiviazione e modificare lo schema di backup aggiungendo nodi o regolando i loro dettagli. Funziona bene su un ambiente di rete ed è espandibile e modulare, il che lo rende ottimo per il backup di un sito o di un’applicazione distribuiti su più server.
Duplicity
Duplicity è un altro strumento di backup open source. Utilizza la crittografia GPG per le trasmissioni per impostazione predefinita.
Il beneficio ovvio dell’utilizzo della crittografia GPG per i backup dei file è che i dati non vengono memorizzati in testo normale. Solo il proprietario della chiave GPG può decifrare i dati. Questo fornisce un certo livello di sicurezza per compensare le misure di sicurezza aggiuntive richieste quando i tuoi dati sono memorizzati in più posizioni.
Un altro beneficio che potrebbe non essere evidente per coloro che non utilizzano regolarmente GPG è che ogni transazione deve essere verificata per essere completamente accurata. GPG, come Rsync, impone il controllo degli hash per garantire che non ci sia stata perdita di dati durante il trasferimento. Ciò significa che quando si ripristinano i dati da un backup, è molto meno probabile incontrare la corruzione dei file.
Parte 3 — Backup a Livello di Blocco
A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.
Un vantaggio dei backup a livello di blocco è che sono tipicamente più veloci. Mentre i backup basati su file di solito avviano un nuovo trasferimento per ogni file separato, un backup basato su blocco trasferirà blocchi, il che significa che meno trasferimenti non sequenziali devono essere avviati per completare la copia.
Utilizzo di dd per Eseguire Backup a Livello di Blocco
Il metodo più comune per eseguire backup a livello di blocco è con l’utilità dd. dd può essere utilizzato per creare intere immagini disco ed è anche frequentemente utilizzato per archiviare supporti rimovibili come CD o DVD. Ciò significa che è possibile eseguire il backup di una partizione o disco su un singolo file o su un dispositivo grezzo senza alcun passaggio preliminare.
Per utilizzare dd, è necessario specificare una posizione di input e una posizione di output, come segue:
In questo scenario, l’argomento if= specifica il dispositivo o la posizione di input. L’argomento of= specifica il file o la posizione di output. Fate attenzione a non confondere questi, altrimenti potreste cancellare per errore un intero disco.
Ad esempio, per eseguire il backup di una partizione contenente i vostri documenti, che si trova in /dev/sda3, è possibile creare un’immagine di quella directory fornendo un percorso di output a un file .img:
Parte 4 — Versionamento dei Backup
Uno dei principali motivi per eseguire il backup dei dati è la possibilità di ripristinare una versione precedente di un file in caso di modifica o cancellazione indesiderata. Mentre tutti i meccanismi di backup finora menzionati possono fornire questo, è anche possibile implementare una soluzione più granulare.
Ad esempio, un modo manuale per realizzare questo sarebbe quello di creare un backup di un file prima di modificarlo in nano:
Potresti anche automatizzare questo processo creando file nascosti con timestamp ogni volta che modifichi un file con il tuo editor. Ad esempio, potresti inserire questo nel tuo file ~/.bashrc, così che ogni volta che esegui nano dalla tua shell bash (cioè $), crei automaticamente un backup contrassegnato con anno (%y), mese (%m), giorno (%d), e così via:
Questo funzionerebbe fino a quando modifichi manualmente i file con nano, ma è limitato nel suo campo di applicazione e potrebbe rapidamente riempire un disco. Puoi vedere come potrebbe finire per essere peggiore che copiare manualmente i file che stai per modificare.
Un’alternativa che risolve molti dei problemi intrinseci a questo design è utilizzare Git come sistema di controllo versione. Anche se è stato sviluppato principalmente per concentrarsi sulla versione del testo semplice, di solito codice sorgente, riga per riga, puoi utilizzare Git per tracciare quasi ogni tipo di file. Per saperne di più, puoi consultare Come Utilizzare Git in Modo Efficace.
Parte 5 — Backup a Livello di Server
La maggior parte dei fornitori di hosting offrirà anche la propria funzionalità di backup opzionale. La funzione di backup di DigitalOcean esegue regolarmente backup automatici per droplet che hanno abilitato questo servizio. Puoi attivarlo durante la creazione del droplet spuntando la casella “Backup”:
Questo effettuerà il backup dell’intera immagine del server cloud regolarmente. Ciò significa che puoi ripristinare dal backup o usarlo come base per nuovi droplet.
Per l’acquisizione occasionale del tuo sistema, puoi anche creare snapshot. Questi funzionano in modo simile ai backup, ma non sono automatizzati. Anche se è possibile fare uno snapshot di un sistema in esecuzione in alcuni contesti, non è sempre consigliato, a seconda di come si sta scrivendo sul filesystem:
Puoi saperne di più sui backup e snapshot di DigitalOcean dalla documentazione su Containers and Images.
GitOps
Infine, vale la pena notare che ci sono alcune circostanze in cui non sarà necessariamente necessario implementare backup su base server. Ad esempio, se il tuo deployment segue i principi del GitOps, potresti trattare molti dei tuoi singoli server cloud come usa e getta e invece considerare le fonti di dati remote come i repository Git come la vera fonte di verità per i tuoi dati. Deployment complessi e moderni come questo possono essere più scalabili e meno soggetti a guasti in molti casi. Tuttavia, vorrai comunque implementare una strategia di backup per i tuoi archivi di dati stessi o per un server di log centralizzato a cui ciascuno di questi server usa e getta potrebbe inviare informazioni. Considera quali aspetti del tuo deployment potrebbero non necessitare di essere salvati e quali sì.
Conclusione
In questo articolo hai esplorato vari concetti e soluzioni di backup. Successivamente, potresti voler esaminare soluzioni per abilitare la ridondanza.