In questo articolo confronteremo i strumenti di backup, ma prima è opportuno conoscere quanto velocemente ed efficacemente gestiscono il ripristino dei dati dai backup.
Per semplificare il confronto, verrà considerato il ripristino da un backup completo, dato che questa modalità è supportata da tutti i candidati. Per facilitare la comprensione, i numeri sono stati presi già mediati (la media aritmetica di diversi avvii). I risultati saranno riassunti in una tabella, che conterrà anche informazioni sulle funzionalità: presenza di un'interfaccia web, facilità di configurazione e utilizzo, capacità di automazione, presenza di diverse 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 i server dedicati ai backup).
Recupero dei dati
I punti di riferimento saranno rsync e tar, poiché i più semplici script per la creazione di backup.
Rsync ha gestito il set di dati di prova in 4 minuti e 28 secondi, mostrando
un carico del genere
Il processo di recupero è stato ostacolato dalle limitazioni del sottosistema di archiviazione del server di backup (grafici a dente di sega). È chiaramente visibile anche il carico di un singolo core senza particolari problemi (basso iowait e softirq — nessun problema con il disco e la rete, rispettivamente). Poiché anche gli altri due programmi, ovvero rdiff-backup e rsnapshot, si basano su rsync e offrono come metodo di recupero il normale rsync, avranno un profilo di carico e un tempo di recupero simili.
Tar ha completato la procedura un po' più velocemente, in
2 minuti e 43 secondi:
Il carico totale del sistema è aumentato in 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 recupero aumenta a 3 minuti e 19 secondi con
questo carico sul server principale (estrazione sul lato del server principale):
Il processo di estrazione utilizza entrambi i core della CPU poiché esegue due processi. In generale, questo è un risultato atteso. Un risultato comparabile (3 minuti e 20 secondi) è stato ottenuto eseguendo gzip sul server con le backup, il profilo di carico sul server principale era molto simile a quello dell'esecuzione di tar senza il compressore gzip (vedi il grafico precedente).
In rdiff-backup è possibile sincronizzare l'ultimo backup effettuato utilizzando il normale 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:
Forse è stato progettato in questo modo, almeno per limitare la velocità, gli autori . Il processo di ripristino del backup richiede un po' meno della metà di un core, con prestazioni proporzionalmente comparabili (cioè da 2 a 5 volte più lente) su disco e rete con rsync.
Rsnapshot per il ripristino suggerisce di utilizzare il normale rsync, quindi i suoi risultati saranno simili. In generale, è esattamente così che è andata.
Burp ha gestito il ripristino del backup in 7 minuti e 2 secondi con
questo carico:
Ha funzionato abbastanza rapidamente e, almeno, è molto più comodo rispetto al semplice rsync: non è necessario ricordare alcuna opzione, interfaccia cli semplice e intuitiva, supporto integrato per più copie, anche se è circa due volte più lento. Se è necessario ripristinare i dati dall'ultimo backup effettuato, è possibile utilizzare rsync, con alcune piccole avvertenze.
Un programma ha mostrato circa la stessa velocità e carico BackupPC attivando la modalità di trasferimento rsync, completando il ripristino in
7 minuti e 42 secondi:
Tuttavia, in modalità di trasferimento dati con tar, BackupPC ha impiegato di più: 12 minuti e 15 secondi, con un carico della CPU complessivamente inferiore
di un fattore e mezzo:
Duplicity senza crittografia ha mostrato risultati leggermente migliori, riuscendo a ripristinare il backup in 10 minuti e 58 secondi. Attivando la crittografia tramite gpg, il tempo di ripristino aumenta a 15 minuti e 3 secondi. Inoltre, durante la creazione del repository per il salvataggio dei backup, è possibile specificare la dimensione dell'archivio che verrà utilizzata per suddividere il flusso di dati in ingresso. In generale, non ci sono differenze significative su normali dischi rigidi, specialmente a causa del funzionamento in modalità monothread. Potrebbero apparire differenze con diverse dimensioni dei blocchi quando vengono utilizzati storage ibridi. Il carico sul server principale durante il ripristino era il seguente:
senza crittografia
con crittografia
Duplicati ha mostrato una velocità di ripristino comparabile, riuscendo in 13 minuti e 45 secondi. Circa 5 minuti sono stati necessari per verificare l'accuratezza dei dati ripristinati (complessivamente circa 19 minuti). In questo caso, il carico era
abbastanza elevato:
Quando la crittografia aes è stata attivata internamente, il tempo di ripristino è stato di 21 minuti e 40 secondi, con il carico della CPU al massimo (entrambi i core!) durante il ripristino; durante il controllo dei dati era attivo solo un thread, occupando un core della CPU. Il controllo dei dati dopo il ripristino ha richiesto gli stessi 5 minuti (per un totale di quasi 27 minuti).
Risultato
Duplicati è riuscito a completare il ripristino un po' più velocemente utilizzando un programma esterno gpg per la crittografia, ma nel complesso le differenze rispetto alla modalità precedente sono minime. Il tempo di esecuzione è stato di 16 minuti e 30 secondi, con un controllo dei dati di 6 minuti. Il carico è stato
tale:
AMANDA, che utilizza tar, ha impiegato 2 minuti e 49 secondi, il che è piuttosto vicino al normale tar. Il carico del sistema è stato sostanzialmente
identico:
Durante il ripristino del backup con zbackup si sono ottenuti i seguenti risultati:
crittografia, compressione lzma
Tempo di esecuzione 11 minuti e 8 secondi
crittografia aes, compressione lzma
Tempo di esecuzione 14 minuti
crittografia aes, compressione lzo
Tempo di esecuzione 6 minuti e 19 secondi
In generale, non c'è male. Tutto dipende dalla velocità del processore sul server di backup, il che è chiaramente visibile dal tempo di esecuzione del programma con diversi compressori. Dal lato del server di backup, veniva eseguito il classico tar, quindi, se lo si confronta con questo, il ripristino funziona tre volte più lentamente. Forse vale la pena verificare l'operatività in modalità multithreading, con un numero di thread superiore a due.
BorgBackup in modalità senza crittografia ha eseguito un po' più lentamente di tar, impiegando 2 minuti e 45 secondi, tuttavia, a differenza del tar, è stata offerta la possibilità di deduplicazione del repository. In questo caso, il carico risultante è stato
il seguente:
Se si attiva la crittografia basata su blake, la velocità di ripristino del backup diminuisce leggermente. Il tempo di ripristino in questa modalità è di 3 minuti e 19 secondi, e il carico è risultato
questo:
La crittografia aes funziona un po' più lentamente, il tempo di ripristino è di 3 minuti e 23 secondi, e il carico non è cambiato particolarmente:
non è cambiato:
Dal momento che Borg può funzionare in modalità multithreading, il carico della CPU è massimo, mentre attivando funzionalità aggiuntive aumenta semplicemente il tempo di esecuzione. È evidente che vale la pena esaminare il multithreading in modo analogo a zbackup.
Restic ha gestito il ripristino con un po' di lentezza, il tempo di esecuzione è stato di 4 minuti e 28 secondi. Il carico appariva
così:
È evidente che 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.
Con UrBackup è riuscito a ripristinare i dati in 8 minuti e 19 secondi, il carico era
tale:
Si nota ancora un carico non molto elevato, addirittura inferiore a quello di tar. Ci sono picchi qua e là, ma non supera il carico di un singolo core.
Scelta e giustificazione dei criteri di confronto
Come accennato in uno dei precedenti articoli, il sistema di backup deve soddisfare i seguenti criteri:
- Facilità d'uso
- Versatilità
- Stabilità
- Velocità
È opportuno esaminare ogni punto in modo più dettagliato.
Facilità d'uso
È ideale avere un solo pulsante "Fai tutto bene", ma tornando ai programmi reali, il principio di funzionamento più comodo è uno standard e familiare.
Per la maggior parte degli utenti, è probabilmente meglio non dover memorizzare un sacco di chiavi per il cli, configurare molte opzioni diverse, spesso poco chiare, tramite web o tui, e impostare notifiche 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. Inoltre, c'è la possibilità di installazione tramite package manager, o con un paio di comandi come "scarica e decomprimi". curl link | sudo bash — un metodo complesso, poiché è necessario controllare cosa arriva dal link.
Ad esempio, delle soluzioni esaminate, le più semplici sono burp, rdiff-backup e restic, che presentano chiavi mnemoniche per diverse modalità di funzionamento. Leggermente più complesse sono borg e duplicity. La più complicata è stata AMANDA. Le altre si collocano a metà strada in termini di facilità d'uso. In ogni caso, se occorre più di 30 secondi per leggere il manuale utente, o se è necessario cercare su Google o un altro motore di ricerca, oltre a sfogliare una lunga pagina di aiuto, la soluzione è considerata complessa, in un modo o nell'altro.
Alcuni dei candidati esaminati sono in grado di inviare automaticamente un messaggio via e-mail jabber, mentre altri si affidano alle notifiche impostate nel sistema. Tuttavia, spesso le configurazioni complesse presentano impostazioni di notifica non del tutto chiare. In ogni caso, se il programma di backup restituisce un codice di uscita diverso da zero, che viene compreso correttamente dal servizio di sistema dei compiti pianificati (invio di un messaggio all'amministratore di sistema o direttamente al monitoraggio) — la situazione è semplice. Ma se il sistema di backup, che non opera sul server di backup, non riesce a segnalare un problema in modo chiaro e ovvio senza configurazione — la complessità diventa eccessiva. In ogni caso, l'emissione di avvisi e altri messaggi solo nell'interfaccia web o nel registro è una cattiva prassi, poiché il più delle volte verranno ignorati.
Per quanto riguarda l'automazione, un semplice programma è in grado di leggere le variabili d'ambiente che definiscono il suo modo di operare o dispone di un'interfaccia CLI avanzata, in grado di replicare completamente il comportamento quando si utilizza l'interfaccia web, per esempio. Inoltre, rientra in questo concetto anche la possibilità di operare in streaming, con funzioni di estensione e così via.
Versatilità
Questo punto si ricollega parzialmente al precedente in termini di automazione e non dovrebbe essere particolarmente difficile 'integrare' il processo di backup nell'infrastruttura esistente.
Vale la pena notare che l'uso di porte non standard (a parte l'interfaccia web) per le operazioni, la realizzazione di crittografia in modo non convenzionale e lo scambio di dati tramite protocolli non standard sono segni di una soluzione non universale. Per la maggior parte, tutti i candidati li presentano in un modo o nell'altro per una ragione evidente: semplicità e universalità di solito non sono compatibili. Come eccezione, c'è burp, e ci sono anche altre opzioni.
Come indicatore, la possibilità di operare usando SSH normale.
Velocità di funzionamento
Il punto più controverso e discusso. Da un lato, il processo è stato avviato, ha funzionato nel minor tempo possibile e non interferisce con le attività principali. Dall'altro, si verifica un picco di traffico e carico sulla CPU durante il backup. Vale anche la pena notare che i programmi più veloci per il backup di solito hanno poche funzionalità, importanti per gli utenti. Ancora una volta: se per recuperare un file di testo di pochi decina di byte con una password è necessario rientrare in tutti i file del repository, o estrarre un'intera archiviazione — il sistema di backup non è affatto veloce. Un altro punto che spesso diventa un oggetto di scontro è la velocità di ripristino del backup dall'archivio. Qui chiaramente hanno un vantaggio coloro che possono semplicemente copiare o spostare i file nella posizione necessaria senza particolari manipolazioni (ad esempio rsync), ma più spesso il problema deve essere affrontato in modo organizzativo, empiricamente: misurare il tempo di ripristino del backup e comunicarlo apertamente agli utenti.
Stabilità
Deve essere chiaro: da un lato, deve esserci la possibilità di ripristinare un backup in qualsiasi momento, dall'altro, deve esserci 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
Facile utilizzo
Automazione semplice
È necessario un client-server?
Verifica dell'integrità del repository
Copie differenziali
Funziona tramite pipe
Versatilità
Indipendenza
Trasparenza del repository
Crittografia
Compressione
Deduplicazione
Interfaccia web
Caricamento nel cloud
Supporto per Windows
Punteggio
Rsync
4m15s
4m28s
sì
no
no
no
sì
no
no
sì
no
sì
sì
no
no
no
no
no
sì
6
Tar
pure
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
no encryption
16m48s
10m58s
sì
sì
no
sì
no
sì
sì
no
no
sì
no
sì
sì
no
sì
no
sì
11
gpg
17m27s
15m3s
Duplicati
no encryption
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
no encryption
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
no encryption
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 operazione inferiore a cinque minuti, oppure risposta «Sì» (eccetto la colonna «È necessario un client-server?»), 1 punto
- Giallo, tempo di operazione tra cinque e dieci minuti, 0.5 punti
- Rosso, tempo di operazione superiore a dieci minuti, oppure risposta «No» (eccetto 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. Al secondo posto si è classificato Restic, mentre gli altri candidati esaminati si sono posizionati in modo simile con una variazione di uno o due punti alla fine.
Ringrazio tutti coloro che hanno letto il ciclo fino alla fine, propongo di discutere le opzioni e di suggerire le proprie, se ci sono. Man mano che la discussione avanza, la tabella potrebbe essere aggiornata.
Il risultato di questo ciclo sarà un articolo conclusivo in cui si cercherà di definire lo strumento ideale per il backup, veloce e gestibile, che permette di ripristinare rapidamente una copia e allo stesso tempo di avere facilità e semplicità nell'impostazione e nella gestione.
Annuncio
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Fonte: habr.com
