Perché è importante fare copie di sicurezza? I dispositivi sono piuttosto affidabili e ci sono anche 'cloud' che, per affidabilità, superano i server fisici: se configurato correttamente, un server 'cloud' può facilmente sopravvivere a un guasto dell'infrastruttura fisica, e dal punto di vista degli utenti dei servizi, ci sarà solo un leggero e quasi impercettibile aumento del tempo di servizio. Inoltre, la duplicazione delle informazioni spesso richiede di pagare per il 'tempo' di elaborazione in eccesso, il carico del disco e il traffico di rete.
Un programma ideale funziona rapidamente, non consuma memoria in modo eccessivo, non ha falle e non esiste.
— Sconosciuto
Poiché i programmi sono ancora scritti da sviluppatori umani e il processo di testing è spesso assente, in aggiunta la fornitura di programmi raramente avviene con l'uso delle 'best practices' (che sono a loro volta programmi e quindi non ideali), gli amministratori di sistema si trovano sovente a dover risolvere problemi che si riducono a frasi brevi ma dense: 'riporta come era', 'riporta il database a funzionare normalmente', 'funziona lentamente — ripristiniamo', e, il mio preferito, 'non so cosa, ma ripara'.
Oltre agli errori logici che emergono a causa del lavoro disordinato degli sviluppatori, o di situazioni particolari, nonché della scarsa conoscenza o comprensione di piccoli dettagli nella programmazione — inclusi i connettori e le strutture di sistema, comprese le operazioni del sistema, i driver e i firmware — esistono anche altri tipi di errori. Per esempio, molti sviluppatori si affidano al runtime, dimenticando completamente le leggi fisiche, che non possono ancora essere eluse tramite programmi. Questo riguarda l'affidabilità infinita del sottosistema di archiviazione e, in generale, di qualsiasi sottosistema di memorizzazione dei dati (inclusa la memoria volatile e la cache della CPU!), il tempo di elaborazione nullo sulla CPU, l'assenza di errori durante la trasmissione su rete e durante l'elaborazione sulla CPU, e i ritardi di rete pari a 0. Non dovremmo nemmeno trascurare il famigerato deadline, perché se non ci si riesce entro quel termine, ci saranno problemi ben più gravi rispetto ai dettagli del funzionamento della rete e del disco.
Come affrontare i problemi che si presentano in modo imponente e pendono su dati preziosi? Non c'è modo di sostituire i programmatori viventi, e non è nemmeno certo che sarà possibile nel prossimo futuro. D'altra parte, finora solo pochi progetti sono riusciti a dimostrare pienamente che il programma funzionerà come previsto, e non è affatto detto che sarà possibile prendere e applicare quelle prove ad altri progetti simili. Inoltre, tali prove richiedono un sacco di tempo e richiedono abilità e conoscenze specifiche, il che riduce praticamente al minimo la possibilità di applicarle considerando le scadenze. Inoltre, non sappiamo ancora realizzare una tecnologia di archiviazione, elaborazione e trasmissione dell'informazione che sia super veloce, economica e infinitamente affidabile. Tali tecnologie, se esistono, sono disponibili solo in forma concettuale o, più spesso, solo in libri e film di fantascienza.
I buoni artisti copiano, i grandi artisti rubano.
—Pablo Picasso.
Le soluzioni più fortunate e le cose sorprendentemente semplici si verificano di solito in quei luoghi dove si incontrano concetti, tecnologie, conoscenze e ambiti scientifici che all'apparenza sono completamente incompatibili.
Ad esempio, gli uccelli e gli aerei hanno le ali, tuttavia, nonostante la somiglianza funzionale - i principi di azione si sovrappongono 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, anche se molto simili. I migliori esempi che osserviamo nella nostra tecnologia sono soprattutto presi dalla natura: compartimenti ermetici per navi e sottomarini - un'analogia diretta con i vermi anellidi; costruzione di array raid e verifica dell'integrità dei dati - duplicazione della catena del DNA; così come organi accoppiati, indipendenza del funzionamento di organi diversi dal sistema nervoso centrale (automazione del funzionamento del cuore) e riflessi - sistemi autonomi in rete. Certo, prendere e applicare soluzioni già pronte 'in modo diretto' può portare a problemi, ma chi lo sa, forse non ci sono altre soluzioni.
Se solo sapessi dove cadere, avrei messo una paglia per terra!
—Proverbio popolare bielorusso
Quindi, le copie di sicurezza sono vitali per coloro che desiderano:
- Avere la possibilità di ripristinare il funzionamento dei propri sistemi con il minimo di inattività, o addirittura senza di essa.
- Agire con determinazione, perché in caso di errore c'è sempre la possibilità di ripristino
- Minimizzare le conseguenze della manomissione intenzionale dei dati
Qui - un po' di teoria
Qualsiasi classificazione è arbitraria. La natura non classifica. Classifichiamo noi, perché per noi è più comodo. E classifichiamo in base a dati che prendiamo anch'essi in modo arbitrario.
—Jean Bruyère
Indipendentemente dal metodo fisico di memorizzazione, la memorizzazione logica dei dati può essere convenzionalmente suddivisa in 2 modalità di accesso a questi dati: a blocchi e a file. Questa distinzione è diventata piuttosto sfumata ultimamente, poiché non esistono memorie logiche puramente a blocchi o puramente a file. Tuttavia, per semplicità, consideriamo che ci siano.
La memorizzazione a blocchi dei dati implica che ci sia un dispositivo fisico in cui i dati vengono scritti in porzioni fisse, blocchi. L'accesso ai blocchi avviene tramite un determinato indirizzo, a ciascun blocco corrisponde un proprio indirizzo all'interno del dispositivo.
Una copia di sicurezza viene solitamente effettuata copiando i blocchi di dati. Per garantire l'integrità dei dati al momento della copia, si sospende la scrittura di nuovi blocchi e anche la modifica di quelli esistenti. Prendendo un'analogia dal mondo reale, si avvicina di più a un armadio con celle numerate identiche.
La memorizzazione dei dati a file, per quanto riguarda il dispositivo logico, è simile a quella a blocchi e spesso viene organizzata sopra di essa. Le differenze importanti sono la presenza di una gerarchia di memorizzazione e nomi comprensibili per l'uomo. Si sviluppa un'astrazione sotto forma di file — un'area di dati nominata, e anche di una directory — un file speciale in cui sono memorizzate le descrizioni e gli accessi agli altri file. I file possono essere dotati di metadati aggiuntivi: data di creazione, flag di accesso, ecc. Di solito si riservano le copie in questo modo: si cercano i file modificati, poi li si copiano in un'altra memoria di file con la stessa struttura. L'integrità dei dati viene solitamente realizzata attraverso l'assenza di file in cui avviene la scrittura. I metadati dei file vengono riservati in modo simile. L'analogia più vicina è una biblioteca, dove ci sono sezioni con libri diversi e c'è anche un catalogo con nomi di libri comprensibili per l'uomo.
Negli ultimi tempi, a volte viene descritto un ulteriore tipo di archiviazione, da cui, in sostanza, è iniziato il salvataggio dei dati, e che presenta le stesse caratteristiche arcaiche: archiviazione oggettuale dei dati.
Si differenzia dall'archiviazione dei file perché non ha più di un livello di nidificazione (schema piatto), e sebbene i nomi dei file siano leggibili dall'uomo, sono comunque più adatti per l'elaborazione da parte delle macchine. Durante il backup, i repository oggettuali vengono spesso trattati come i file, ma ci sono anche alcune alternative.
— Esistono due tipi di amministratori di sistema: quelli che non fanno backup e quelli che già lo fanno.
— In realtà ci sono tre tipi: ci sono anche quelli che controllano se i backup possono essere ripristinati.— Sconosciuto
È anche importante comprendere che il processo stesso di backup dei dati è effettuato da programmi, e quindi presenta gli stessi svantaggi di qualsiasi altro programma. Per ridurre (non eliminare!) la dipendenza dal fattore umano, così come dalle peculiarità — che da sole non influenzano molto, ma insieme possono avere un effetto significativo — viene applicata la cosiddetta regola 3-2-1. Ci sono molte interpretazioni su come decodificarlo, ma a me piace di più la seguente: è necessario conservare 3 copie degli stessi dati, 2 copie devono essere conservate in formati diversi e 1 copia deve essere conservata in un deposito geograficamente remoto.
Per formato di archiviazione si intende quanto segue:
- Se c'è dipendenza dal metodo fisico di archiviazione — cambiamo il metodo fisico.
- Se c'è dipendenza dal metodo logico di archiviazione — cambiamo il metodo logico.
Per ottenere il massimo effetto della regola 3-2-1, si raccomanda di cambiare il formato di archiviazione in entrambi i modi.
Dal punto di vista della prontezza del backup per il suo scopo primario — il ripristino della funzionalità — si distinguono i backup "caldi" e "freddi". I backup caldi si differenziano da quelli freddi solo per un motivo: sono immediatamente pronti per l'uso, mentre i freddi richiedono ulteriori azioni per il ripristino: decrittazione, estrazione dall'archivio, ecc.
Non bisogna confondere le copie calde e fredde con le copie online e offline, che implicano l'isolamento fisico dei dati e sono, in effetti, un'altra forma di classificazione dei metodi di backup. Pertanto, una copia offline - non collegata direttamente al sistema da cui deve essere ripristinata - può essere sia calda che fredda (in termini di prontezza al ripristino). Una copia online può essere accessibile direttamente dove deve essere ripristinata ed è nella maggior parte dei casi una copia calda, anche se ci sono casi in cui è fredda.
Inoltre, non bisogna dimenticare che il processo di creazione delle copie di backup di solito non termina con la creazione di una sola copia di backup, ma possono esserci un numero considerevole di copie. Di conseguenza, è necessario distinguere tra backup completi, cioè quelli che possono essere ripristinati indipendentemente da altri backup, e copie differenziali (incrementali, differenziali, decrementali, ecc.) - quelle che non possono essere ripristinate da sole e richiedono il ripristino preventivo di una o più altre copie di backup.
Le copie differenziali incrementali sono un tentativo di risparmiare spazio di archiviazione per le copie di backup. In questo modo, vengono registrati solo i dati modificati rispetto all'ultima copia di backup.
Le copie differenziali decrementali vengono create con lo stesso scopo, ma con un metodo leggermente diverso: viene eseguita una copia di backup completa, ma viene effettivamente memorizzata solo la differenza tra la copia recente e quella precedente.
Vale la pena considerare separatamente il processo di backup sopra uno storage che supporta l'assenza di archiviazione di duplicati. Pertanto, se si scrivono copie di backup complete sopra di esso, verrà effettivamente registrata solo la differenza tra le copie di backup, tuttavia il processo di ripristino delle copie di backup avverrà in modo simile al ripristino da una copia completa e sarà completamente trasparente.
Quis custodiet ipsos custodes?
(Chi custodirà i custodi stessi? — latino)
È molto sgradevole non avere copie di backup, ma è molto peggio se una copia di backup sembra essere stata creata, ma durante il ripristino si scopre che non può essere ripristinata perché:
- L'integrità dei dati originali è stata compromessa.
- Lo storage con le copie di backup è danneggiato.
- Il ripristino procede piuttosto lentamente, non si possono utilizzare i dati che sono stati ripristinati solo parzialmente.
Un processo di backup ben strutturato deve tenere conto di commenti simili, in particolare i primi due.
L'integrità dei dati originali può essere garantita in diversi modi. I più comuni sono: a) creazione di snapshot del file system a livello di blocco, b) 'congelamento' dello stato del file system, c) dispositivo a blocchi speciale con tecnologia di versioning, d) scrittura sequenziale di file o blocchi. Sono utilizzate anche le somme di controllo per garantire la verifica dei dati durante il ripristino.
Anche i danni allo storage possono essere identificati tramite somme di controllo. Un altro metodo è l'utilizzo di dispositivi specializzati, o file system nei quali non è possibile modificare i dati già registrati, ma solo aggiungere nuovi.
Per accelerare il ripristino, si può adottare il recupero dei dati attraverso più processi — a patto che non ci sia un 'collo di bottiglia' rappresentato da una rete lenta o da un sistema disco non veloce. Per evitare la situazione di dati ripristinati parzialmente, è possibile suddividere il processo di backup in compiti relativamente piccoli, ciascuno dei quali viene eseguito separatamente. In questo modo, si crea la possibilità di ripristinare sequenzialmente la funzionalità con una previsione dei tempi di ripristino. Questo problema si colloca più spesso nell'ambito organizzativo (SLA), quindi non ci soffermeremo su di esso in dettaglio.
Sa apprezzare le spezie non chi le aggiunge in ogni piatto, ma chi non ne aggiunge mai di superfluo.
—V. Sinyavsky
La pratica riguardo ai software utilizzati dagli amministratori di sistema può variare, ma i principi generali sono comunque gli stessi, in particolare:
- È fortemente consigliato utilizzare soluzioni pronte.
- I programmi devono funzionare in modo prevedibile, cioè non devono esserci caratteristiche non documentate o colli di bottiglia.
- La configurazione di ciascun programma deve essere semplice da non dover leggere ogni volta il manuale o una guida rapida.
- La soluzione deve essere universale, poiché i server possono variare notevolmente nelle loro caratteristiche hardware.
Per il backup dei dispositivi a blocchi, ci sono i seguenti programmi comuni:
- dd, nota ai veterani dell'amministrazione di sistema, insieme a programmi simili (come dd_rescue, ad esempio).
- Utilità integrate in alcuni file system che creano un'immagine (dump) del file system.
- Utilità generali; ad esempio, partclone.
- Soluzioni proprietarie, spesso esclusive; ad esempio, NortonGhost e versioni più recenti.
Per i file system, il backup viene affrontato parzialmente con metodi applicabili ai dispositivi a blocchi, ma si può anche risolvere in maniera più efficace, utilizzando ad esempio:
- Rsync, un programma e protocollo universale per la sincronizzazione dello stato dei file system.
- Strumenti integrati per l'archiviazione (ZFS).
- Strumenti di terze parti per l'archiviazione; il più popolare è tar. Ce ne sono anche altri, come dar, un sostituto di tar orientato ai sistemi moderni.
Vale la pena menzionare strumenti software per garantire la coerenza dei dati durante la creazione di backup. I seguenti metodi sono comunemente utilizzati:
- Montare il file system in modalità di sola lettura (ReadOnly), o congelare il file system (freeze) — il metodo ha applicazioni limitate.
- Creare immagini dello stato di un file system o di un dispositivo a blocchi (LVM, ZFS).
- Utilizzare strumenti di terze parti per organizzare immagini, anche nei casi in cui i punti precedenti non possano essere garantiti per vari motivi (programmi del tipo hotcopy).
- La tecnica di copia al cambiamento (CopyOnWrite), tuttavia è spesso legata al file system in uso (BTRFS, ZFS).
Pertanto, per un piccolo server è necessario garantire uno schema di backup che soddisfi i seguenti requisiti:
- Facile da usare — non richiede azioni aggiuntive particolari, minime azioni per creare e ripristinare copie.
- Universale — funziona sia su server grandi che piccoli; è importante con la crescita del numero server o della scalabilità.
- Viene installato tramite un gestore di pacchetti, o con una o due comandi del tipo 'scarica e decomprimi'.
- Stabile — viene utilizzato un formato di archiviazione standard o consolidato da tempo.
- Rapida nel lavoro.
Candidati tra coloro che rispondono più o meno ai requisiti:
- rdiff-backup
- rsnapshot
- burp
- duplicati
- duplicity
- deja dup
- dar
- zbackup
- restic
- borgbackup
Per il banco di prova verrà utilizzata 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 (SAN con caching SSD pari al 20% della dimensione del disco virtuale) sotto forma di un disco virtuale separato senza partizionamento,
- canale Internet a 200 Mbit/s.
Per il server di ricezione dei backup verrà utilizzata quasi la stessa macchina, ma con un disco rigido da 500 GB.
Sistema operativo — CentOS 7 x64: partizionamento standard, una partizione aggiuntiva sarà utilizzata come sorgente dei dati.
Come dati sorgente utilizzeremo un sito WordPress con file multimediali da 40 GB e un database MySQL. Poiché server virtuali variano notevolmente nelle caratteristiche e anche per una 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 dotazione)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'orario attuale
Limite dei numeri primi: 20000
Inizializzazione dei 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
avg: 4.78
max: 22.39
percentuale 95: 10.46
somma: 119923.64
Equità dei thread:
eventi (avg/stddev): 6276.0000/13.91
tempo di esecuzione (avg/stddev): 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 dotazione)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'orario attuale
Esecuzione del test di velocità di memoria con le seguenti opzioni:
dimensione blocco: 1KiB
dimensione totale: 102400MiB
operazione: lettura
ambito: globale
Inizializzazione dei thread di lavoro…
Thread avviati!
Totale operazioni: 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
avg: 0.00
max: 24.01
percentuale 95: 0.00
somma: 39106.74
Equità dei thread:
eventi (avg/stddev): 12725111.5000/137775.15
tempo di esecuzione (avg/stddev): 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 dotazione)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'orario attuale
Esecuzione del test di velocità di memoria con le seguenti opzioni:
dimensione blocco: 1KiB
dimensione totale: 102400MiB
operazione: scrittura
ambito: globale
Inizializzazione dei thread di lavoro…
Thread avviati!
Totale operazioni: 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
avg: 0.00
max: 16.90
percentuale 95: 0.00
somma: 43604.83
Equità dei thread:
eventi (avg/stddev): 8977603.2500/233905.84
tempo di esecuzione (avg/stddev): 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 dotazione)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'orario attuale
Extra flag di apertura file: (nessuno)
128 file, 8MiB ciascuno
1GiB dimensione totale del file
Dimensione blocco 4KiB
Numero di richieste IO: 0
Rapporto Read/Write per test casuale combinato IO: 1.50
FSYNC periodico abilitato, chiamando fsync() ogni 100 richieste.
Chiamando fsync() alla fine del test, abilitato.
Utilizzando la modalità I/O sincrona
Esecuzione di test r/w casuali
Inizializzazione dei thread di lavoro…
Thread avviati!
Throughput:
lettura: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
scrivere: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latenza (ms):
min: 0.00
media: 0.27
max: 18.01
95° percentile: 1.08
somma: 238469.45
Questo articolo segna l'inizio di un ampio
ciclo di articoli sul backup
- Backup, parte 1: Perché è necessario il backup, panoramica dei metodi e delle tecnologie
- Backup, parte 2: Panoramica e test di strumenti di backup basati su rsync
- Backup, parte 3: Panoramica e test di duplicity, duplicaty, deja dup
- Backup, parte 4: Panoramica e test di zbackup, restic, borgbackup
- Backup, parte 5: Test di Bacula e Veeam Backup for Linux
- Backup, parte 6: Confronto degli strumenti di backup
- Backup, parte 7: Conclusioni
Fonte: habr.com
