Perché è necessario eseguire backup? L'hardware è molto affidabile e ci sono anche 'cloud' che superano in affidabilità i server fisici: con una corretta configurazione, un server 'cloud' può facilmente sopportare il guasto di un server fisico, mentre per gli utenti dei servizi ci sarà solo un leggero e impercettibile aumento del tempo di risposta. Inoltre, la duplicazione delle informazioni spesso comporta costi aggiuntivi per il tempo di elaborazione 'superfluo', il carico del disco e il traffico della rete.
Un programma ideale funziona rapidamente, non consuma memoria in modo inadeguato, non presenta perdite e non esiste.
—Sconosciuto
Poiché i programmi sono ancora scritti da sviluppatori umani e il processo di test è spesso assente, e la fornitura di software avviene raramente seguendo le 'best practices' (che sono anch'esse programmi e quindi non perfette), gli amministratori di sistema spesso si trovano a dover affrontare richieste che suonano brevi, ma sostanziali: 'riporta tutto com'era', 'riporta il database a funzionamento normale', 'funziona lentamente - torniamo indietro', e il mio preferito 'non so cosa, ma riparalo'.
Oltre agli errori logici che emergono a causa di un lavoro superficiale degli sviluppatori, di circostanze improvvise e della scarsa conoscenza o comprensione delle piccole peculiarità della programmazione — incluse quelle relative ai collegamenti e ai sistemi, comprese le operazioni di sistema, i driver e il firmware — ci sono anche altri errori. Ad esempio, molti sviluppatori si affidano al runtime, dimenticando completamente le leggi fisiche, che non possono ancora essere aggirate tramite programmi. Questo include l'affidabilità infinita del sottosistema di storage e in generale di qualsiasi sottosistema di memorizzazione dei dati (compresa la RAM e la cache della CPU!), il tempo di elaborazione pari a zero sulla CPU, l'assenza di errori nella trasmissione dei dati attraverso la rete e nella elaborazione sulla CPU, e i ritardi di rete che sono nulli. Non si dovrebbe trascurare nemmeno il famoso deadline, poiché se non si riesce a rispettarlo, ci saranno problemi ben più gravi rispetto alle sottigliezze del funzionamento della rete e del disco.
Come si affrontano i problemi che si presentano e incombono sui dati preziosi? Non ci sono sostituti per gli sviluppatori umani, e non è affatto certo che sia possibile trovarli a breve. D'altra parte, finora solo alcuni progetti sono riusciti a dimostrare che il software funziona come previsto, e non è affatto garantito che tali prove possano essere applicate ad altri progetti simili. Inoltre, tali prove richiedono énormément tempo e specifiche competenze e conoscenze, il che rende praticamente impossibile il loro utilizzo considerando le scadenze. Inoltre, non abbiamo ancora sviluppato una tecnologia di archiviazione, elaborazione e trasmissione delle informazioni che sia incredibilmente veloce, economica e infinitamente affidabile. Tecnologie di questo tipo, se esistono, lo fanno solo in forma di concetti, oppure — più frequentemente — solo nei libri e nei film di fantascienza.
I buoni artisti copiano, i grandi artisti rubano.
— Pablo Picasso.
Le soluzioni migliori e le cose incredibilmente semplici si verificano generalmente dove si incontrano concetti, tecnologie, conoscenze e campi scientifici che, a prima vista, sembrano completamente incompatibili.
Ad esempio, gli uccelli e gli aerei hanno le ali, ma nonostante la somiglianza funzionale — il principio di funzionamento coincide in alcune modalità, e i problemi tecnici vengono risolti in modo simile: ossa cave, utilizzo di materiali resistenti e leggeri, ecc. — i risultati sono assolutamente diversi, sebbene molto simili. I migliori esempi che osserviamo nella nostra tecnologia sono principalmente ispirati dalla natura: compartimenti ermetici nelle navi e nei sottomarini — una diretta analogia con i vermi a segmenti; costruzione di array raid e verifica dell'integrità dei dati — duplicazione della catena del DNA; e anche organi duplici, indipendenza del funzionamento di diversi organi dal SNC (automazione del lavoro del cuore) e riflessi — sistemi autonomi su Internet. Certamente, prendere e applicare soluzioni pronte 'alla lettera' porta a problemi, ma chi lo sa, forse non ci sono altre soluzioni.
Se sapessi dove cadere, avrei steso un po' di paglia!
—Proverbio popolare bielorusso
Significa che le copie di backup sono vitali per chi desidera:
- Avere la possibilità di ripristinare il funzionamento dei propri sistemi con tempi di inattività minimi, se non addirittura senza di essi.
- Agisci con determinazione, perché in caso di errore c'è sempre la possibilità di un ripristino.
- Minimizzare le conseguenze della manomissione intenzionale dei dati.
Qui c'è un po' di teoria.
Qualsiasi classificazione è arbitraria. La natura non classifica. Classifichiamo noi, perché per noi è più comodo, e lo facciamo in base a dati che prendiamo anch'essi in modo arbitrario.
—Jean Bruyère
Indipendentemente dal modo fisico di memorizzazione, la memorizzazione logica dei dati può essere grossolanamente suddivisa in 2 modalità di accesso a questi dati: blocco e file. Questa divisione è diventata piuttosto sfumata negli ultimi tempi, poiché non esistono archivi logici puramente a blocchi, così come non esistono archivi puramente a file. Tuttavia, per semplificare, consideriamo che esistano.
La memorizzazione a blocchi dei dati implica che ci sia un dispositivo fisico dove vengono registrati i dati in porzioni fisse, in blocchi. L'accesso ai blocchi avviene tramite un certo indirizzo, con ciascun blocco che ha il proprio indirizzo all'interno del dispositivo.
Il backup viene solitamente eseguito copiando i blocchi di dati. Per garantire l'integrità dei dati al momento della copia, viene sospesa la scrittura di nuovi blocchi e la modifica di quelli esistenti. Se prendiamo un'analogia dal mondo reale, è simile a un armadio con celle numerate identiche.
La memorizzazione dei dati basata su un dispositivo logico è simile a quella basata su blocchi e spesso è strutturata in modo simile. Le differenze principali sono la presenza di una gerarchia di memorizzazione e nomi comprensibili per gli esseri umani. Si evidenzia un'astrazione sotto forma di file — un'area di dati denominata, così come di una directory — un file speciale che contiene descrizioni e accessi ad altri file. I file possono essere dotati di metadati aggiuntivi: data di creazione, flag di accesso, ecc. Di solito, si prenotano in questo modo: si cercano file modificati e poi li si copia in un'altra memoria di file con struttura simile. L'integrità dei dati è generalmente garantita dall'assenza di file in cui si sta scrivendo. I metadati dei file vengono prenotati in modo analogo. L'analogia più vicina è una biblioteca, in cui ci sono sezioni con diversi libri e anche un catalogo con nomi comprensibili per gli esseri umani.
Recentemente, a volte viene descritto un ulteriore approccio, da cui, in effetti, è iniziata la memorizzazione dei dati nei file e che presenta le stesse caratteristiche arcaiche: la memorizzazione dei dati oggettuali.
A differenza dello storage file, non ha più di un livello di annidamento (schema piatto) e i nomi dei file, sebbene siano leggibili dall'uomo, sono comunque più adatti per l'elaborazione da parte di macchine. Nella creazione di backup, gli storage oggetti sono generalmente trattati in modo simile a quelli file, ma ci sono occasionalmente anche altre opzioni.
— Ci sono due tipi di amministratori di sistema: quelli che non fanno backup e quelli che GIÀ lo fanno.
— In realtà ce ne sono tre: ci sono anche quelli che controllano che i backup siano recuperabili.—Sconosciuto
È importante comprendere che il processo di backup dei dati è gestito da software, quindi presenta gli stessi svantaggi di qualsiasi altro programma. Per ridurre (non eliminare!) la dipendenza dal fattore umano, così come le particolarità — che singolarmente potrebbero non avere un grande impatto, ma insieme possono avere un effetto significativo — si applica la cosiddetta regola 3-2-1. Ci sono molte varianti di interpretazione, ma quella che preferisco è la seguente: è necessario mantenere 3 copie degli stessi dati, 2 copie in formati diversi e 1 copia deve essere conservata in una posizione geograficamente remota.
Con formato di archiviazione si intende quanto segue:
- Se esiste una dipendenza dal metodo fisico di archiviazione, cambiamo il metodo fisico.
- Se esiste una dipendenza dal metodo logico di archiviazione, cambiamo il metodo logico.
Per ottenere il massimo effetto dalla regola 3-2-1, è consigliabile cambiare il formato di archiviazione in entrambi i metodi.
Dal punto di vista della prontezza del backup per il suo scopo principale — il ripristino della funzionalità — si distinguono i backup "caldi" e "freddi". I backup caldi si differenziano da quelli freddi solo per un aspetto: sono pronti all'uso immediatamente, mentre i backup freddi richiedono alcune azioni aggiuntive per il ripristino: decrittazione, estrazione dall'archivio, ecc.
Non bisogna confondere i backup caldi e freddi con i backup online e offline, che implicano l'isolamento fisico dei dati e sono sostanzialmente un altro modo di classificare i metodi di backup. Infatti, una copia offline — non collegata direttamente al sistema dal quale deve essere ripristinata — può essere sia calda che fredda (in termini di prontezza al ripristino). Una copia online può essere accessibile direttamente nel luogo in cui deve essere ripristinata e nella maggior parte dei casi è calda, sebbene possano esserci anche copie fredde.
Inoltre, è importante ricordare che il processo di creazione di backup di solito non si conclude con un singolo backup; possono esserci molte copie. Pertanto, è fondamentale distinguere tra backup completi, cioè quelli che possono essere ripristinati in modo indipendente da altri backup, e le copie incrementali (differenziali, decrementali, ecc.) — quelle che non possono essere ripristinate da sole e richiedono il ripristino preliminare di uno o più altri backup.
Le copie incrementali differenziali cercano di ridurre lo spazio necessario per archiviare i backup. In questo modo, nel backup vengono memorizzati solo i dati modificati rispetto all'ultimo backup.
Le copie decrementali differenziali vengono create con lo stesso scopo, ma in un modo leggermente diverso: viene eseguito un backup completo, ma viene effettivamente memorizzata solo la differenza tra la copia recente e quella precedente.
È importante considerare il processo di backup su uno storage che supporta l'assenza di duplicati. In questo modo, se si scrivono backup completi su di esso, verrà effettivamente registrata solo la differenza tra i backup, ma il processo di ripristino sarà simile a quello di un ripristino da un backup completo e completamente trasparente.
Quis custodiet ipsos custodes?
(Chi custodirà i custodi stessi? — latino)
È decisamente sgradevole non avere backup, ma è molto peggio se un backup sembra essere stato effettivamente creato, ma durante il ripristino si scopre che non può essere ripristinato, perché:
- L'integrità dei dati originali è stata compromessa.
- Lo storage con i backup è danneggiato.
- Il ripristino avviene molto lentamente, non è possibile utilizzare i dati che sono stati ripristinati parzialmente.
Un corretto processo di backup deve tenere conto di tali osservazioni, soprattutto delle prime due.
L'integrità dei dati originali può essere garantita in diversi modi. I più comuni includono: a) la creazione di snapshot del file system a livello block, b) il "freezing" dello stato del file system, c) un dispositivo block speciale per la memorizzazione delle versioni, d) la scrittura sequenziale di file o blocchi. Si utilizzano anche checksum per verificare i dati durante il recupero.
I danni allo storage possono essere rilevati anche tramite checksum. Un altro metodo è l'uso di dispositivi specializzati o file system in cui i dati già scritti non possono essere modificati, ma possono essere aggiunti nuovi dati.
Per accelerare il ripristino, si utilizza il recupero dei dati con più processi, a condizione che non ci sia un "collo di bottiglia" rappresentato da una rete lenta o un sistema disco non performante. Per evitare il problema dei dati parzialmente ripristinati, è possibile suddividere il processo di backup in compiti relativamente piccoli, ciascuno dei quali viene eseguito separatamente. In questo modo, diventa possibile ripristinare il funzionamento in modo sequenziale, prevedendo i tempi di recupero. Questo problema è spesso di natura organizzativa (SLA), quindi non ci soffermeremo ulteriormente su di esso.
Chi conosce le spezie non è colui che le aggiunge in ogni piatto, ma colui che non ne aggiunge mai di superflue.
— V. Siniavsky
La pratica riguardo al software utilizzato dagli amministratori di sistema può variare, ma i principi generali rimangono gli stessi, in particolare:
- Si raccomanda vivamente di utilizzare soluzioni pronte.
- I programmi devono funzionare in modo prevedibile, cioè non ci devono essere caratteristiche o colli di bottiglia non documentati.
- La configurazione di ogni programma deve essere così semplice da non dover leggere ogni volta il manuale o la guida rapida.
- La soluzione deve essere, per quanto possibile, universale, poiché i server possono differire notevolmente nelle loro caratteristiche hardware.
Per il backup di dispositivi a blocchi, ci sono i seguenti programmi comuni:
- dd, noto ai veterani dell'amministrazione di sistema, include anche programmi simili (come dd_rescue, ad esempio).
- Programmi integrati in alcuni file system che creano un'istantanea (dump) del file system.
- Utility generiche; ad esempio, partclone.
- Soluzioni proprietarie, spesso di proprietà; ad esempio, NortonGhost e versioni successive.
Per i file system, la questione del backup è parzialmente risolvibile utilizzando metodi applicabili ai dispositivi a blocchi, tuttavia la questione può essere risolta in modo più efficace, utilizzando ad esempio:
- Rsync, un programma e protocollo universale per la sincronizzazione dello stato dei file system.
- Strumenti di backup integrati (ZFS).
- Strumenti di backup di terze parti; il più popolare è tar. Ci sono anche altri, come dar, un'alternativa a tar orientata ai sistemi moderni.
Vale la pena menzionare i software che garantiscono la coerenza dei dati durante la creazione di backup. Le opzioni più comuni sono:
- Montaggio del file system in modalità di sola lettura (ReadOnly) o congelamento del file system (freeze) — metodo applicabile in modo limitato.
- Creazione di snapshot dello stato del file system o del dispositivo a blocchi (LVM, ZFS).
- Utilizzo di strumenti di terzi per la creazione di snapshot, anche nei casi in cui i punti precedenti non possano essere forniti per qualche motivo (programmi come hotcopy).
- Tecnica di copia al momento della modifica (CopyOnWrite), tuttavia è spesso legata al file system utilizzato (BTRFS, ZFS).
Quindi, per un piccolo server è necessario garantire uno schema di backup che soddisfi i seguenti requisiti:
- Semplice da usare — non richiede azioni aggiuntive, minime azioni per creare e ripristinare copie.
- Universale — funziona sia su server di grandi dimensioni che su server più piccoli; questo è importante quando il numero cresce server o si scala.
- Si installa tramite un gestore di pacchetti o con una o due semplici comandi come «scarica e decomprimi».
- Affidabile — utilizza un formato di archiviazione standard o consolidato da tempo.
- Velocità operativa.
I candidati che soddisfano più o meno i requisiti includono:
- rdiff-backup
- rsnapshot
- burp
- duplicati
- duplicity
- deja dup
- dar
- zbackup
- restic
- borgbackup
Come ambiente di test utilizzeremo una macchina virtuale (basata su XenServer) con le seguenti caratteristiche:
- 4 core a 2.5 GHz,
- 16 GB di RAM,
- 50 GB di storage ibrido (Sistema di Archiviazione Dati con caching SSD al 20% della dimensione del disco virtuale) come un disco virtuale separato senza partizionamento,
- canale Internet a 200 Mbit/s.
Come server di ricezione delle copie di backup utilizzeremo una macchina praticamente identica, ma con un disco rigido da 500 GB.
Sistema operativo — Centos 7 x64: partizionamento standard, una partizione aggiuntiva sarà utilizzata come sorgente dati.
Come dati sorgente prenderemo un sito WordPress, con file multimediali della dimensione di 40 GB e un database in MySQL. Poiché server virtuali variano notevolmente nelle caratteristiche e, per migliore riproducibilità, qui ci sono
i risultati del test del server utilizzando sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Eseguendo il test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dall'ora attuale
Limite dei numeri primi: 20000
Inizializzando i thread di lavoro…
Thread avviati!
Velocità CPU:
eventi al secondo: 836.69
Throughput:
eventi/s (eps): 836.6908
tempo trascorso: 30.0039s
numero totale di eventi: 25104
Latenza (ms):
min: 2.38
media: 4.78
max: 22.39
95° percentile: 10.46
somma: 119923.64
Equità dei thread:
eventi (media/deviazione standard): 6276.0000/13.91
tempo di esecuzione (media/deviazione standard): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Eseguendo il test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dall'ora attuale
Eseguendo il test di velocità della memoria con le seguenti opzioni:
dimensione blocco: 1KiB
dimensione totale: 102400MiB
operazione: lettura
ambito: globale
Inizializzando i thread di lavoro…
Thread avviati!
Operazioni totali: 50900446 (1696677.10 al secondo)
49707.47 MiB trasferiti (1656.91 MiB/sec)
Throughput:
eventi/s (eps): 1696677.1017
tempo trascorso: 30.0001s
numero totale di eventi: 50900446
Latenza (ms):
min: 0.00
media: 0.00
max: 24.01
95° percentile: 0.00
somma: 39106.74
Equità dei thread:
eventi (media/deviazione standard): 12725111.5000/137775.15
tempo di esecuzione (media/deviazione standard): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Eseguendo il test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dall'ora attuale
Eseguendo il test di velocità della memoria con le seguenti opzioni:
dimensione blocco: 1KiB
dimensione totale: 102400MiB
operazione: scrittura
ambito: globale
Inizializzando i thread di lavoro…
Thread avviati!
Operazioni totali: 35910413 (1197008.62 al secondo)
35068.76 MiB trasferiti (1168.95 MiB/sec)
Throughput:
eventi/s (eps): 1197008.6179
tempo trascorso: 30.0001s
numero totale di eventi: 35910413
Latenza (ms):
min: 0.00
media: 0.00
max: 16.90
95° percentile: 0.00
somma: 43604.83
Equità dei thread:
eventi (media/deviazione standard): 8977603.2500/233905.84
tempo di esecuzione (media/deviazione standard): 10.9012/0.41
sysbench —threads=4 —file-test-mode=rndrw —time=60 —file-block-size=4K —file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Eseguendo il test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dall'ora attuale
Flag aggiuntive per l'apertura dei file: (nessuna)
128 file, 8MiB ciascuno
1GiB di dimensione totale del file
Dimensione del blocco 4KiB
Numero di richieste I/O: 0
Rapporto di lettura/scrittura per il test I/O casuale combinato: 1.50
FSYNC periodico abilitato, chiamando fsync() ogni 100 richieste.
Chiamando fsync() alla fine del test, Abilitato.
Utilizzando modalità I/O sincrona
Eseguendo test di lettura/scrittura casuali
Inizializzando i thread di lavoro…
Thread avviati!
Throughput:
lettura: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
scrittura: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latenza (ms):
min: 0.00
media: 0.27
massimo: 18.01
95° percentile: 1.08
somma: 238469.45
Con questo articolo inizia un ampio
ciclo di articoli sul backup
- Backup, parte 1: Perché è importante fare backup, panoramica dei metodi e tecnologie
- Backup, parte 2: Panoramica e test degli strumenti di backup basati su rsync
- Backup, parte 3: Panoramica e testing di duplicity, duplicaty, deja dup
- Backup, parte 4: Panoramica e test di zbackup, restic, borgbackup
- Backup, parte 5: Test di bacula e veeam backup per linux
- Backup, parte 6: Confronto degli strumenti di backup
- Backup, parte 7: Conclusioni
Fonte: habr.com
