Perché è necessario eseguire i backup? Dopotutto, l'attrezzatura è molto, molto affidabile e inoltre ci sono "cloud" che sono più affidabili in termini di affidabilità rispetto ai server fisici: con una corretta configurazione, un server "cloud" può facilmente sopravvivere al guasto di un server fisico dell'infrastruttura, e da dal punto di vista degli utenti del servizio, ci sarà un piccolo salto appena percettibile nel tempo del servizio. Inoltre, la duplicazione delle informazioni spesso richiede il pagamento di tempo “extra” del processore, carico del disco e traffico di rete.
Un programma ideale funziona velocemente, non perde memoria, non ha buchi e non esiste.
-Sconosciuto
Poiché i programmi sono ancora scritti da sviluppatori di proteine, e spesso non esiste alcun processo di test, inoltre i programmi vengono raramente forniti utilizzando le “migliori pratiche” (che sono anch’esse programmi e quindi imperfetti), gli amministratori di sistema molto spesso devono risolvere problemi che sembrano brevi ma in breve: "ritorna a com'era", "riporta la base al normale funzionamento", "funziona lentamente - torna indietro", e anche il mio preferito "non so cosa, ma aggiustalo".
Oltre agli errori logici che derivano dal lavoro imprudente degli sviluppatori o da una combinazione di circostanze, nonché da una conoscenza incompleta o da un'incomprensione di piccole funzionalità dei programmi di creazione - inclusi quelli di connessione e di sistema, inclusi sistemi operativi, driver e firmware - ci sono anche altri errori. Ad esempio, la maggior parte degli sviluppatori si affida al runtime, dimenticandosi completamente delle leggi fisiche, che è ancora impossibile aggirare utilizzando i programmi. Ciò include l'infinita affidabilità del sottosistema del disco e, in generale, di qualsiasi sottosistema di archiviazione dei dati (comprese RAM e cache del processore!), e zero tempi di elaborazione sul processore, e l'assenza di errori durante la trasmissione sulla rete e durante l'elaborazione sul processore e latenza di rete, che è uguale a 0. Non dovresti trascurare la famigerata scadenza, perché se non la rispetti in tempo, ci saranno problemi peggiori delle sfumature del funzionamento della rete e del disco.
Cosa fare con i problemi che aumentano in tutta la loro forza e incombono su dati preziosi? Non c'è nulla che possa sostituire gli sviluppatori viventi e non è un dato di fatto che ciò sarà possibile nel prossimo futuro. D’altro canto, solo pochi progetti sono riusciti a dimostrare pienamente che il programma funzionerà come previsto, e non sarà necessariamente possibile raccogliere e applicare le prove ad altri progetti simili. Inoltre, tali prove richiedono molto tempo e richiedono abilità e conoscenze speciali, e questo praticamente riduce al minimo la possibilità del loro utilizzo tenendo conto delle scadenze. Inoltre, non sappiamo ancora come utilizzare una tecnologia ultraveloce, economica e infinitamente affidabile per archiviare, elaborare e trasmettere informazioni. Tali tecnologie, se esistono, sono sotto forma di concetti o, molto spesso, solo in libri e film di fantascienza.
I bravi artisti copiano, i grandi artisti rubano.
-Pablo Picasso.
Le soluzioni di maggior successo e le cose sorprendentemente semplici di solito accadono dove si incontrano concetti, tecnologie, conoscenze e campi della scienza che a prima vista sono assolutamente incompatibili.
Ad esempio, gli uccelli e gli aeroplani hanno le ali, ma nonostante la somiglianza funzionale, il principio di funzionamento in alcune modalità è lo stesso e i problemi tecnici vengono risolti in modo simile: ossa cave, utilizzo di materiali resistenti e leggeri, ecc. i risultati sono completamente diversi, anche se molto simili. Anche i migliori esempi che vediamo nella nostra tecnologia sono in gran parte presi in prestito dalla natura: i compartimenti pressurizzati di navi e sottomarini sono un’analogia diretta con gli anellidi; costruire array raid e controllare l'integrità dei dati - duplicare la catena del DNA; così come organi accoppiati, indipendenza del lavoro di diversi organi dal sistema nervoso centrale (automazione del cuore) e riflessi - sistemi autonomi su Internet. Certo, prendere e applicare “frontalmente” soluzioni già pronte è irto di problemi, ma chissà, forse non ci sono altre soluzioni.
Se solo avessi saputo dove saresti caduto, avrei steso delle cannucce!
—Proverbio popolare bielorusso
Ciò significa che le copie di backup sono vitali per coloro che desiderano:
- Potrai ripristinare il funzionamento dei tuoi sistemi con tempi di inattività minimi o addirittura senza tempi di inattività
- Agire con coraggio, perché in caso di errore c'è sempre la possibilità di un rollback
- Ridurre al minimo le conseguenze della corruzione intenzionale dei dati
Ecco una piccola teoria
Qualsiasi classificazione è arbitraria. La natura non classifica. Classifichiamo perché ci è più conveniente. E classifichiamo in base a dati che prendiamo anche arbitrariamente.
—Jean Bruler
Indipendentemente dal metodo di archiviazione fisica, l'archiviazione logica dei dati può essere suddivisa in due modalità di accesso a questi dati: blocco e file. Questa divisione è stata recentemente molto sfumata, perché non esiste un'archiviazione logica puramente a blocchi, così come puramente file. Tuttavia, per semplicità, supponiamo che esistano.
L'archiviazione dei dati a blocchi implica che esista un dispositivo fisico in cui i dati vengono scritti in determinate porzioni fisse, i blocchi. Si accede ai blocchi ad un determinato indirizzo; ogni blocco ha il proprio indirizzo all'interno del dispositivo.
Un backup viene solitamente effettuato copiando blocchi di dati. Per garantire l'integrità dei dati, la registrazione di nuovi blocchi, così come le modifiche a quelli esistenti, vengono sospese al momento della copia. Se prendiamo un'analogia dal mondo ordinario, la cosa più vicina è un armadio con celle numerate identiche.
L'archiviazione dei dati dei file basata sul principio del dispositivo logico è simile all'archiviazione a blocchi ed è spesso organizzata in alto. Differenze importanti sono la presenza di una gerarchia di archiviazione e nomi leggibili dall'uomo. Un'astrazione viene allocata sotto forma di file - un'area dati denominata, nonché una directory - un file speciale in cui sono archiviate le descrizioni e l'accesso ad altri file. I file possono essere forniti con metadati aggiuntivi: ora di creazione, flag di accesso, ecc. I backup vengono solitamente eseguiti in questo modo: cercano i file modificati, quindi li copiano in un altro archivio di file con la stessa struttura. L'integrità dei dati è solitamente implementata dall'assenza di file su cui si sta scrivendo. Il backup dei metadati dei file viene eseguito allo stesso modo. L'analogia più vicina è una biblioteca, che ha sezioni con libri diversi e ha anche un catalogo con nomi dei libri leggibili dall'uomo.
Recentemente, a volte viene descritta un'altra opzione, da cui, in linea di principio, è iniziata l'archiviazione dei dati sui file e che ha le stesse caratteristiche arcaiche: l'archiviazione dei dati degli oggetti.
Si differenzia dall'archiviazione dei file in quanto non ha più di un annidamento (schema piatto) e i nomi dei file, sebbene leggibili dall'uomo, sono comunque più adatti all'elaborazione da parte delle macchine. Quando si eseguono i backup, l'archiviazione degli oggetti viene spesso trattata in modo simile all'archiviazione dei file, ma occasionalmente sono disponibili altre opzioni.
— Esistono due tipi di amministratori di sistema, quelli che non eseguono backup e quelli che lo fanno GIÀ.
- In realtà ce ne sono tre tipi: c'è anche chi controlla che i backup possano essere ripristinati.-Sconosciuto
Vale anche la pena capire che il processo di backup dei dati stesso viene eseguito dai programmi, quindi presenta tutti gli stessi svantaggi di qualsiasi altro programma. Per rimuovere (non eliminare!) la dipendenza dal fattore umano, così come le caratteristiche - che singolarmente non hanno un effetto forte, ma insieme possono dare un effetto notevole - i cosiddetti regola 3-2-1. Esistono molte opzioni su come decifrarlo, ma mi piace di più la seguente interpretazione: 3 set degli stessi dati devono essere archiviati, 2 set devono essere archiviati in formati diversi e 1 set deve essere archiviato in un archivio geograficamente remoto.
Il formato di archiviazione deve essere inteso come segue:
- Se esiste una dipendenza dal metodo di archiviazione fisica, cambiamo il metodo fisico.
- Se esiste una dipendenza dal metodo di archiviazione logica, cambiamo il metodo logico.
Per ottenere il massimo effetto dalla regola 3-2-1, si consiglia di modificare il formato di archiviazione in entrambi i modi.
Dal punto di vista della disponibilità del backup per lo scopo previsto - ripristino della funzionalità - viene fatta una distinzione tra backup "a caldo" e "a freddo". Quelli caldi differiscono da quelli freddi solo per una cosa: sono subito pronti all'uso, mentre quelli freddi richiedono alcuni passaggi aggiuntivi per il ripristino: decrittazione, estrazione dall'archivio, ecc.
Non confondere le copie calde e fredde con le copie online e offline, che implicano l'isolamento fisico dei dati e, di fatto, sono un altro segno della classificazione dei metodi di backup. Pertanto una copia offline, non direttamente connessa al sistema su cui deve essere ripristinata, può essere calda o fredda (in termini di disponibilità per il ripristino). Una copia online può essere disponibile direttamente dove deve essere ripristinata, e molto spesso è calda, ma ce ne sono anche di fredde.
Inoltre, non dimenticare che il processo di creazione delle copie di backup stesso di solito non termina con la creazione di una copia di backup e può esserci un numero abbastanza elevato di copie. Pertanto, è necessario distinguere tra backup completi, ovvero quelli che possono essere ripristinati indipendentemente da altri backup, nonché copie differenziali (incrementali, differenziali, decrementali, ecc.) - quelle che non possono essere ripristinate in modo indipendente e richiedono il ripristino preliminare di uno o più altri backup.
I backup incrementali differenziali sono un tentativo di risparmiare spazio di archiviazione di backup. Pertanto, nella copia di backup vengono scritti solo i dati modificati dal backup precedente.
Quelli decrementali differenziali vengono creati per lo stesso scopo, ma in un modo leggermente diverso: viene eseguita una copia di backup completa, ma viene effettivamente memorizzata solo la differenza tra la nuova copia e quella precedente.
Separatamente, vale la pena considerare il processo di backup su storage, che garantisce l'assenza di archiviazione di duplicati. Pertanto, se si scrivono backup completi sopra di esso, verranno effettivamente scritte solo le differenze tra i backup, ma il processo di ripristino dei backup sarà simile al ripristino da una copia completa e completamente trasparente.
Quis custodiet ipsos custodes?
(Chi custodirà le sentinelle stesse? - lat.)
È molto spiacevole quando non ci sono copie di backup, ma è molto peggio se sembra che sia stata creata una copia di backup, ma durante il ripristino risulta che non può essere ripristinata perché:
- L'integrità dei dati di origine è stata compromessa.
- L'archivio di backup è danneggiato.
- Il ripristino funziona molto lentamente; non è possibile utilizzare dati che sono stati parzialmente recuperati.
Un processo di backup adeguatamente strutturato deve tenere conto di tali commenti, in particolare dei primi due.
L'integrità dei dati di origine può essere garantita in diversi modi. Quelli più comunemente utilizzati sono i seguenti: a) creazione di istantanee del file system a livello di blocco, b) “congelamento” dello stato del file system, c) uno speciale dispositivo a blocchi con memorizzazione della versione, d) registrazione sequenziale di file o blocchi. Vengono applicati anche checksum per garantire che i dati vengano verificati durante il ripristino.
Il danneggiamento dello storage può essere rilevato anche utilizzando i checksum. Un ulteriore metodo è l'uso di dispositivi specializzati o file system in cui i dati già registrati non possono essere modificati, ma è possibile aggiungerne di nuovi.
Per accelerare il ripristino, il ripristino dei dati viene utilizzato con più processi di ripristino, a condizione che non vi siano colli di bottiglia sotto forma di rete lenta o sistema disco lento. Per aggirare la situazione con dati parzialmente recuperati, è possibile suddividere il processo di backup in sottoattività relativamente piccole, ciascuna delle quali viene eseguita separatamente. Pertanto, diventa possibile ripristinare costantemente le prestazioni prevedendo al tempo stesso i tempi di ripristino. Questo problema risiede molto spesso nel piano organizzativo (SLA), quindi non ci soffermeremo su questo in dettaglio.
Esperto di spezie non è colui che le aggiunge ad ogni piatto, ma colui che non vi aggiunge mai nulla in più.
-IN. Sinjavskij
Le pratiche relative al software utilizzato dagli amministratori di sistema possono variare, ma i principi generali sono sempre, in un modo o nell'altro, gli stessi, in particolare:
- Si consiglia vivamente di utilizzare soluzioni già pronte.
- I programmi dovrebbero funzionare in modo prevedibile, ad es. Non dovrebbero esserci funzionalità o colli di bottiglia non documentati.
- L'impostazione di ogni programma dovrebbe essere così semplice da non dover leggere ogni volta il manuale o il foglietto illustrativo.
- Se possibile, la soluzione dovrebbe essere universale, perché i server possono variare notevolmente nelle loro caratteristiche hardware.
Esistono i seguenti programmi comuni per eseguire i backup dai dispositivi a blocchi:
- dd, familiare ai veterani dell'amministrazione di sistema, include anche programmi simili (lo stesso dd_rescue, per esempio).
- Utilità integrate in alcuni file system che creano un dump del file system.
- Utilità onnivore; ad esempio partclone.
- Decisioni proprie, spesso proprietarie; ad esempio NortonGhost e versioni successive.
Per i file system, il problema del backup è parzialmente risolto utilizzando metodi applicabili ai dispositivi a blocchi, ma il problema può essere risolto in modo più efficiente utilizzando, ad esempio:
- Rsync, un programma e protocollo generico per la sincronizzazione dello stato dei file system.
- Strumenti di archiviazione integrati (ZFS).
- Strumenti di archiviazione di terze parti; il rappresentante più popolare è tar. Ce ne sono altri, ad esempio dar, un sostituto del tar destinato ai sistemi moderni.
Vale la pena menzionare separatamente gli strumenti software per garantire la coerenza dei dati durante la creazione di copie di backup. Le opzioni più comunemente utilizzate sono:
- Montaggio del file system in modalità di sola lettura (ReadOnly) o congelamento del file system (freeze): il metodo ha un'applicabilità limitata.
- Creazione di istantanee dello stato dei file system o dei dispositivi a blocchi (LVM, ZFS).
- L'utilizzo di strumenti di terze parti per l'organizzazione delle impressioni, anche nei casi in cui per qualche motivo non è possibile fornire i punti precedenti (programmi come hotcopy).
- La tecnica copy-on-change (CopyOnWrite), tuttavia, è molto spesso legata al file system utilizzato (BTRFS, ZFS).
Pertanto, per un server di piccole dimensioni è necessario fornire uno schema di backup che soddisfi i seguenti requisiti:
- Facile da usare: non sono richiesti passaggi aggiuntivi speciali durante il funzionamento, passaggi minimi per creare e ripristinare copie.
- Universale: funziona sia su server grandi che piccoli; questo è importante quando si aumenta il numero di server o si scala.
- Installato da un gestore di pacchetti o in uno o due comandi come "scarica e decomprimi".
- Stabile: viene utilizzato un formato di archiviazione standard o consolidato.
- Veloce nel lavoro.
Candidati provenienti da coloro che più o meno soddisfano i requisiti:
- rdiff-backup
- istantanea
- rutto
- duplicazione
- duplicità
- lascia dup
- dare
- zbackup
- resto
- borgbackup
Come banco di prova verrà utilizzata una macchina virtuale (basata su XenServer) con le seguenti caratteristiche:
- 4 core da 2.5 GHz,
- 16 GB di RAM,
- 50 GB di spazio di archiviazione ibrido (sistema di archiviazione con caching su SSD pari al 20% della dimensione del disco virtuale) sotto forma di disco virtuale separato senza partizionamento,
- Canale Internet a 200 Mbps.
Quasi la stessa macchina verrà utilizzata come server ricevente di backup, solo con un disco rigido da 500 GB.
Sistema operativo - Centos 7 x64: partizione standard, partizione aggiuntiva verrà utilizzata come origine dati.
Come dati iniziali, prendiamo un sito WordPress con 40 GB di file multimediali e un database mysql. Poiché i server virtuali variano notevolmente nelle caratteristiche e anche per una migliore riproducibilità, ecco
risultati dei test del server utilizzando sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 CPU eseguite
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'ora corrente
Limite numeri primi: 20000
Inizializzazione dei thread di lavoro…
Discussioni iniziate!
Velocità della CPU:
eventi al secondo: 836.69
Throughput:
eventi/i (eps): 836.6908
tempo trascorso: 30.0039s
numero totale di eventi: 25104
Latenza (ms):
minimo: 2.38
media: 4.78
max: 22.39
95° percentile: 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=leggi l'esecuzione della memoria
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'ora corrente
Esecuzione del test della velocità della memoria con le seguenti opzioni:
dimensione del blocco: 1 KiB
dimensione totale: 102400 MiB
operazione: leggere
ambito: globale
Inizializzazione dei thread di lavoro…
Discussioni iniziate!
Operazioni totali: 50900446 (1696677.10 al secondo)
49707.47 MiB trasferiti (1656.91 MiB/sec)
Throughput:
eventi/i (eps): 1696677.1017
tempo trascorso: 30.0001s
numero totale di eventi: 50900446
Latenza (ms):
minimo: 0.00
media: 0.00
max: 24.01
95° percentile: 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=scrivi esecuzione memoria
sysbench 1.1.0-18a9f86 (utilizzando LuaJIT 2.1.0-beta3 in bundle)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'ora corrente
Esecuzione del test della velocità della memoria con le seguenti opzioni:
dimensione del blocco: 1 KiB
dimensione totale: 102400 MiB
operazione: scrivere
ambito: globale
Inizializzazione dei thread di lavoro…
Discussioni iniziate!
Operazioni totali: 35910413 (1197008.62 al secondo)
35068.76 MiB trasferiti (1168.95 MiB/sec)
Throughput:
eventi/i (eps): 1197008.6179
tempo trascorso: 30.0001s
numero totale di eventi: 35910413
Latenza (ms):
minimo: 0.00
media: 0.00
max: 16.90
95° percentile: 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 bundle)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'ora corrente
Flag di apertura file aggiuntivi: (nessuno)
128 file, 8MiB ciascuno
Dimensione totale del file 1GiB
Dimensione del blocco 4 KiB
Numero di richieste IO: 0
Rapporto di lettura/scrittura per il test IO casuale combinato: 1.50
FSYNC periodico abilitato, chiamando fsync() ogni 100 richieste.
Chiamata fsync() alla fine del test, abilitato.
Utilizzo della modalità I/O sincrona
Esecuzione di un test r/w casuale
Inizializzazione dei thread di lavoro…
Discussioni iniziate!
Throughput:
leggi: 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):
minimo: 0.00
media: 0.27
max: 18.01
95° percentile: 1.08
somma: 238469.45
Questa nota inizia alla grande
serie di articoli sul backup
- Backup, parte 1: Perché è necessario il backup, una panoramica dei metodi, delle tecnologie
- Backup Parte 2: revisione e test degli strumenti di backup basati su rsync
- Backup Parte 3: Revisione e test di duplicità, duplicazione, deja dup
- Backup Parte 4: revisione e test di zbackup, restic, borgbackup
- Backup Parte 5: Testare il backup di bacula e veeam per linux
- Backup Parte 6: Confronto degli strumenti di backup
- Backup Parte 7: Conclusioni
Fonte: habr.com