In questo articolo verrà effettuato un confronto degli strumenti di backup, ma prima è importante capire come gestiscono il ripristino dei dati da backup in modo rapido ed efficace.
Per semplificare il confronto, verrà considerato il ripristino da un backup completo, poiché questo modo di operare è supportato da tutti i candidati. Per semplificare, i numeri sono stati già mediati (media aritmetica di vari avvii). I risultati saranno riassunti in una tabella, che conterrà anche informazioni riguardo alle funzionalità: presenza di un'interfaccia web, facilità di configurazione e utilizzo, capacità di automazione, disponibilità di varie funzionalità aggiuntive (ad esempio, verifica dell'integrità dei dati) e così via. I grafici mostreranno il carico del server dove i dati verranno applicati (non il server per lo storage dei backup).
Ripristino dei dati
Come punto di riferimento verranno utilizzati rsync e tar, poiché i semplici script per effettuare backup.
Rsync ha completato il set di dati di test in 4 minuti e 28 secondi, mostrando
questo carico
Il processo di ripristino è stato limitato dalle restrizioni del sottosistema di memorizzazione dei backup (grafici a zig-zag). È anche evidente il carico su un singolo core senza particolari problemi (basso iowait e softirq — nessun problema con disco e rete, rispettivamente). Poiché gli altri due programmi, cioè rdiff-backup e rsnapshot, si basano su rsync e offrono come strumento di ripristino il consueto rsync, avranno un profilo di carico e tempi di ripristino simili.
Tar è riuscito a completare il processo leggermente più velocemente, in
2 minuti e 43 secondi:
Il carico totale del sistema è stato superiore di media del 20% a causa dell’aumento del softirq — sono aumentati i costi operativi del sottosistema di rete.
Se l'archivio viene compresso ulteriormente, il tempo di ripristino aumenta a 3 minuti e 19 secondi con
questo carico sul server principale (decompressione sul lato del server principale):
Il processo di estrazione utilizza entrambi i core della CPU, poiché vengono eseguiti due processi. Nel complesso, è un risultato atteso. Anche un risultato comparabile (3 minuti e 20 secondi) è stato ottenuto eseguendo gzip sul server con i backup; il profilo di carico sul server principale era abbastanza simile a quello di tar senza il compressore gzip (vedi grafico precedente).
In rdiff-backup è possibile sincronizzare l'ultimo backup effettuato utilizzando il comune rsync (i risultati saranno simili), ma i backup più vecchi devono comunque essere ripristinati utilizzando il programma rdiff-backup, che ha completato il ripristino in 17 minuti e 17 secondi, mostrando
questo carico:
Potrebbe essere stata questa l'intenzione, ad ogni modo per limitare la velocità gli autori . Il processo di ripristino del backup richiede poco meno della metà di un core, con prestazioni proporzionalmente comparabili (cioè da 2 a 5 volte più lente) in termini di disco e rete con rsync.
Rsnapshot propone di utilizzare il comune rsync per il ripristino, quindi i suoi risultati saranno simili. In effetti, è stato così.
Burp ha completato il compito di ripristino del backup in 7 minuti e 2 secondi con
questo carico:
Ha funzionato abbastanza velocemente, e almeno è molto più conveniente rispetto al semplice rsync: non è necessario ricordare alcun flag, interfaccia cli semplice e intuitiva, supporto integrato per più copie, anche se è circa due volte più lento. Se i dati devono essere ripristinati dall'ultimo backup effettuato, è possibile utilizzare rsync, con alcune piccole avvertenze.
Un programma BackupPC ha mostrato una velocità e un carico simili attivando la modalità di trasferimento rsync, completando il backup in
7 minuti e 42 secondi:
Tuttavia, in modalità di trasferimento dati con tar, BackupPC ha impiegato più tempo: 12 minuti e 15 secondi, e il carico della CPU è stato in generale inferiore
di un fattore e mezzo:
Duplicity senza crittografia ha mostrato risultati leggermente migliori, completando il ripristino del backup in 10 minuti e 58 secondi. Se si attiva la crittografia tramite gpg, il tempo di ripristino aumenta a 15 minuti e 3 secondi. Inoltre, durante la creazione del repository per archiviare le copie, è possibile specificare la dimensione dell'archivio che sarà utilizzata per suddividere il flusso di dati in ingresso. In generale, su normali dischi rigidi, a causa della modalità di lavoro a thread singolo, non c'è una differenza particolare. Questa potrebbe apparire con diverse dimensioni dei blocchi, quando vengono utilizzati archiviazioni ibride. Il carico sul server principale durante il ripristino è stato il seguente:
senza crittografia
con crittografia
Duplicati ha mostrato una velocità di ripristino comparabile, completando in 13 minuti e 45 secondi. Altri circa 5 minuti sono stati necessari per verificare la correttezza dei dati ripristinati (in totale circa 19 minuti). Il carico durante questo è stato
abbastanza elevato:
Quando la crittografia aes è stata attivata tramite strumenti interni, il tempo di ripristino è stato di 21 minuti e 40 secondi, con un carico massimo della CPU (entrambi i core!) durante il ripristino; durante la verifica dei dati solo un thread era attivo, occupando un core della CPU. La verifica dei dati dopo il ripristino ha richiesto gli stessi 5 minuti (in totale quasi 27 minuti).
Risultato
Leggermente più veloce, Duplicati ha gestito il ripristino utilizzando un programma esterno gpg per la crittografia, ma in generale le differenze rispetto alla modalità precedente sono minime. Il tempo di lavoro è stato di 16 minuti e 30 secondi, con una verifica dei dati di 6 minuti. Il carico era
di questo tipo:
AMANDA, che utilizza tar, ha completato in 2 minuti e 49 secondi, che, in principio, è molto vicino a un normale tar. Il carico sul sistema è di fatto
simile:
Durante il ripristino del backup utilizzando zbackup si sono ottenuti i seguenti risultati:
crittografia, compressione lzma
Tempo di lavoro 11 minuti e 8 secondi
crittografia aes, compressione lzma
Tempo di lavoro 14 minuti
crittografia aes, compressione lzo
Tempo di lavoro 6 minuti, 19 secondi
In generale, non è male. Tutto dipende dalla velocità della CPU sul server di backup, che è chiaramente visibile nei tempi di esecuzione del programma con diversi compressori. Dal lato del server di backup, veniva eseguito il normale tar, quindi se lo confrontiamo con lui, il ripristino funziona tre volte più lentamente. Potrebbe valere la pena controllare il funzionamento in modalità multithreading, con un numero di thread superiore a due.
BorgBackup in modalità senza crittografia ha funzionato un po' più lentamente del tar, impiegando 2 minuti e 45 secondi, tuttavia, a differenza dello stesso tar, è stata data la possibilità di deduplicare il repository. Il carico risultante è stato
il seguente:
Se si attiva la crittografia basata su blake, la velocità di ripristino del backup rallenta leggermente. Il tempo di ripristino in questa modalità è di 3 minuti e 19 secondi, e il carico è risultato
così:
La crittografia aes funziona leggermente più lentamente, il tempo di ripristino è di 3 minuti e 23 secondi, il carico non è particolarmente
cambiato:
Poiché Borg può funzionare in modalità multithreading, il carico della CPU è massimo, mentre attivando funzioni aggiuntive aumenta semplicemente il tempo di esecuzione. Probabilmente, vale la pena esplorare la multithreading in modo simile a zbackup.
Restic ha gestito il ripristino un po' più lentamente, il tempo di esecuzione è stato di 4 minuti e 28 secondi. Il carico risultante è stato
in questo modo:
Probabilmente, il processo di ripristino funziona in più thread, ma l'efficienza non è così alta come quella di BorgBackup, ma è comparabile nel tempo con il normale rsync.
Utilizzando UrBackup è riuscito a ripristinare i dati in 8 minuti e 19 secondi, il carico risultante è stato
di questo tipo:
Si nota ancora un carico non molto elevato, anche inferiore a quello del tar. Ci sono picchi occasionali, ma non oltre il carico di un core.
Scelta e giustificazione dei criteri di confronto
Come è stato detto in uno degli articoli precedenti, il sistema di backup deve soddisfare i seguenti criteri:
- Semplicità di utilizzo
- Versatilità
- Stabilità
- Velocità
Vale la pena considerare ogni punto in dettaglio.
Semplicità di utilizzo
È meglio quando c'è un solo pulsante "Fai tutto bene", ma tornando ai programmi reali, il principio di funzionamento più familiare e standard sarà il più comodo.
Per la maggior parte degli utenti, sarà probabilmente meglio non dover memorizzare una serie di chiavi per il CLI, configurare una serie di diverse opzioni, spesso poco comprensibili, tramite web o TUI, e impostare avvisi per il fallimento delle operazioni. Questo include anche la possibilità di integrare facilmente una soluzione di backup nell'infrastruttura esistente, oltre all'automazione del processo di backup. È importante anche avere la possibilità di installazione tramite un gestore di pacchetti, o con uno o due comandi come "scarica e decomprimi". curl link | sudo bash — metodo complesso, in quanto è necessario verificare cosa arriva dal link.
Ad esempio, tra i candidati esaminati, soluzioni semplici includono burp, rdiff-backup e restic, che possiedono chiavi mnemoniche per diverse modalità operative. Un po' più complessi sono borg e duplicity. La più complessa era AMANDA. Gli altri si trovano a metà strada in termini di facilità d'uso. In ogni caso, se è necessario più di 30 secondi per leggere il manuale utente, o è necessario cercare su Google o un altro motore di ricerca, così come scorrere un lungo documento di aiuto, la soluzione è complessa, in un modo o nell'altro.
Alcuni dei candidati esaminati sono in grado di inviare automaticamente un messaggio via e-mail o Jabber, mentre altri fanno affidamento su avvisi impostati nel sistema. Tuttavia, spesso le soluzioni complesse hanno impostazioni di avviso non del tutto ovvie. In ogni caso, se il programma di backup restituisce un codice di uscita diverso da zero, che verrà correttamente interpretato dal servizio di sistema delle attività programmate (dove il messaggio andrà all'amministratore di sistema o direttamente nel monitoraggio) — la situazione è semplice. Ma se il sistema di backup, non funzionante sul server di backup, non può segnalare un problema in modo chiaro e diretto senza configurazione — la complessità è già eccessiva. In ogni caso, l'emissione di avvisi e altri messaggi solo nell'interfaccia web e/o nel log è una cattiva prassi, in quanto spesso verranno ignorati.
Per quanto riguarda l'automazione, un programma semplice è in grado di leggere le variabili di ambiente che impostano la sua modalità operativa, oppure ha un CLI avanzato che può duplicare completamente il comportamento tramite interfaccia web, ad esempio. Questo include anche la possibilità di lavoro in streaming, la presenza di funzionalità di estensione, e così via.
Versatilità
Parzialmente sovrapposto alla sezione precedente in termini di automazione, non dovrebbe essere particolarmente problematico "inserire" il processo di backup nell'infrastruttura esistente.
È importante notare che l'uso di porte non standard (tranne per l'interfaccia web) per il funzionamento, l'implementazione della crittografia in modo non standard, lo scambio di dati tramite protocolli non standard sono segni di una soluzione non universale. La maggior parte dei candidati presenta queste caratteristiche per una ragione ovvia: semplicità e universalità di solito non sono compatibili. Un'eccezione è burp, ma ce ne sono anche altre.
Una caratteristica chiave è la possibilità di operare utilizzando il normale ssh.
Velocità di funzionamento
Il punto più controverso e discusso. Da un lato, abbiamo avviato il processo, ha funzionato il più rapidamente possibile e non ostacola le attività principali. D'altra parte, c'è un picco nel traffico e nel carico della CPU durante il backup. È anche importante notare che i programmi più veloci per eseguire copie sono spesso i più poveri di funzioni importanti per gli utenti. Ancora una volta: se per recuperare un unico file di testo di poche decine di byte con una password, l'intero servizio ne risente (sì, capisco che in questo caso il processo di backup non è di solito il colpevole), e occorre leggere sequenzialmente tutti i file nel repository o estrarre un intero archivio — il sistema di backup non è affatto veloce. Un altro punto che spesso diventa un ostacolo è la velocità di ripristino di un backup da un archivio. Qui hanno un vantaggio chiaro coloro che possono semplicemente copiare o spostare file nella posizione desiderata senza troppe complicazioni (ad esempio rsync), ma più spesso è necessario affrontare il problema in modo organizzativo, in modo empirico: misurare il tempo di ripristino del backup e comunicarlo apertamente agli utenti.
Stabilità
Si deve capire così: da un lato, deve esserci la possibilità di ripristinare il backup in qualsiasi caso, dall'altro — resilienza a vari problemi: interruzione della rete, guasto del disco, eliminazione di parte del repository.
Confronto degli strumenti di backup
Tempo di creazione della copia
Tempo di ripristino della copia
Installazione semplice
Configurazione semplice
Utilizzo semplice
Automazione semplice
È necessario un client-server?
Verifica dell'integrità del repository
Backup differenziali
Funzionamento tramite pipe
Versatilità
Indipendenza
Trasparenza del repository
Crittografia
Compressione
è la creazione di un archivio senza file duplicati (se il deduplicatore sa dove può essere scaricato l'originale del pacchetto, riduce i duplicati dall'archivio).
Interfaccia web
Caricamento nel cloud
Supporto Windows
Punteggio
Rsync
4m15s
4m28s
sì
no
no
no
sì
no
no
sì
no
sì
sì
no
no
no
no
no
sì
6
Tar
puro
3m12s
2m43s
sì
no
no
no
no
no
sì
sì
no
sì
no
no
no
no
no
no
sì
8,5
gzip
9m37s
3m19s
sì
Rdiff-backup
16m26s
17m17s
sì
sì
sì
sì
sì
no
sì
no
sì
no
sì
no
sì
sì
sì
no
sì
11
Rsnapshot
4m19s
4m28s
sì
sì
sì
sì
no
no
sì
no
sì
no
sì
no
no
sì
sì
no
sì
12,5
Burp
11m9s
7m2s
sì
no
sì
sì
sì
sì
sì
no
sì
sì
no
no
sì
no
sì
no
sì
10,5
Duplicity
niente crittografia
16m48s
10m58s
sì
sì
no
sì
no
sì
sì
no
no
sì
no
sì
sì
no
sì
no
sì
11
gpg
17m27s
15m3s
Duplicati
niente crittografia
20m28s
13m45s
no
sì
no
no
no
sì
sì
no
no
sì
no
sì
sì
sì
sì
sì
sì
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
niente crittografia
40m3s
11m8s
sì
sì
no
no
no
sì
sì
sì
no
sì
no
sì
sì
sì
no
no
no
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
niente crittografia
4m7s
2m45s
sì
sì
sì
sì
sì
sì
sì
sì
sì
sì
no
sì
sì
sì
sì
no
sì
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
sì
sì
sì
sì
no
sì
sì
sì
sì
sì
no
sì
no
sì
no
sì
sì
15,5
UrBackup
8m21s
8m19s
sì
sì
sì
no
sì
no
sì
no
sì
sì
no
sì
sì
sì
sì
no
sì
12
Amanda
9m3s
2m49s
sì
no
no
sì
sì
sì
sì
no
sì
sì
sì
sì
sì
no
sì
sì
sì
13
BackupPC
rsync
12m22s
7m42s
sì
no
sì
sì
sì
sì
sì
no
sì
no
no
sì
sì
no
sì
no
sì
10,5
tar
12m34s
12m15s
Legenda della tabella:
- Verde, tempo di attività inferiore a cinque minuti, o risposta "Sì" (eccetto per la colonna "È necessario un client server?"), 1 punto
- Giallo, tempo di attività cinque-dieci minuti, 0,5 punti
- Rosso, tempo di attività superiore a dieci minuti, o risposta "No" (eccetto per la colonna "È necessario un client server?"), 0 punti
Secondo la tabella sopra, lo strumento più semplice, veloce e allo stesso tempo comodo e potente per il backup è BorgBackup. Secondo posto per Restic, gli altri candidati esaminati hanno ottenuto punteggi simili con una dispersione di uno o due punti alla fine.
Ringrazio tutti coloro che hanno finalmente letto il ciclo, propongo di discutere le opzioni e di proporre le proprie, se ci sono. Con il proseguimento della discussione, la tabella può essere ampliata.
Il risultato del ciclo sarà un articolo finale, in cui si cercherà di delineare il mezzo ideale, veloce e gestibile per il backup, che consenta di ripristinare una copia rapidamente e allo stesso tempo di avere comodità e semplicità nella configurazione e manutenzione.
Annuncio
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Fonte: habr.com
