Questo articolo confronterà gli strumenti di backup, ma prima dovresti scoprire quanto velocemente e bene gestiscono il ripristino dei dati dai backup.
Per facilitare il confronto, prenderemo in considerazione il ripristino da un backup completo, soprattutto perché tutti i candidati supportano questa modalità operativa. Per semplicità, dei numeri è già stata calcolata la media (la media aritmetica di diverse esecuzioni). I risultati saranno riepilogati in una tabella, che conterrà anche informazioni sulle funzionalità: presenza di un'interfaccia web, facilità di configurazione e funzionamento, capacità di automatizzazione, presenza di varie funzionalità aggiuntive (ad esempio, controllo dell'integrità dei dati) , eccetera. I grafici mostreranno il carico sul server in cui verranno utilizzati i dati (non il server per l'archiviazione delle copie di backup).
Recupero dati
Da allora rsync e tar verranno utilizzati come punto di riferimento semplici script per creare copie di backup.
rsync ha affrontato i dati del test impostati in 4 minuti e 28 secondi, mostrando
un tale carico
Il processo di ripristino ha riscontrato una limitazione del sottosistema del disco del server di archiviazione di backup (grafici a dente di sega). Puoi anche vedere chiaramente il caricamento di un kernel senza problemi (iowait e softirq bassi - nessun problema rispettivamente con il disco e la rete). Poiché gli altri due programmi, ovvero rdiff-backup e rsnapshot, si basano su rsync e offrono anche rsync regolare come strumento di ripristino, avranno all'incirca lo stesso profilo di carico e tempo di ripristino del backup.
Catrame l'ho fatto un po' più velocemente
2 minuti e 43 secondi:
Il carico totale del sistema è stato superiore in media del 20% a causa dell'aumento del softirq: i costi generali durante il funzionamento del sottosistema di rete sono aumentati.
Se l'archivio viene ulteriormente compresso, il tempo di ripristino aumenta a 3 minuti e 19 secondi.
con un tale carico sul server principale (disimballaggio sul lato del server principale):
Il processo di decompressione occupa entrambi i core del processore poiché sono in esecuzione due processi. In generale, questo è il risultato atteso. Inoltre, un risultato comparabile (3 minuti e 20 secondi) è stato ottenuto eseguendo gzip sul lato server con i backup; il profilo di carico sul server principale era molto simile all'esecuzione di tar senza il compressore gzip (vedere il grafico precedente).
В rdiff-backup puoi sincronizzare l'ultimo backup effettuato utilizzando il normale rsync (i risultati saranno simili), ma i backup più vecchi devono ancora essere ripristinati utilizzando il programma rdiff-backup, che ha completato il ripristino in 17 minuti e 17 secondi, mostrando
questo carico:
Forse questo aveva lo scopo, almeno, di limitare la velocità degli autori . Il processo di ripristino di una copia di backup richiede poco meno della metà di un core, con prestazioni proporzionalmente comparabili (ovvero 2-5 volte più lente) su disco e rete con rsync.
Ristantanea Per il ripristino, suggerisce di utilizzare rsync regolare, quindi i risultati saranno simili. In generale, è così che è andata a finire.
Rutto Ho completato l'attività di ripristino di un backup in 7 minuti e 2 secondi con
con questo carico:
Ha funzionato abbastanza rapidamente e almeno è molto più conveniente del puro rsync: non è necessario ricordare alcun flag, un'interfaccia CLI semplice e intuitiva, supporto integrato per più copie, sebbene sia due volte più lento. Se hai bisogno di ripristinare i dati dall'ultimo backup effettuato, puoi utilizzare rsync, con alcuni avvertimenti.
Il programma ha mostrato approssimativamente la stessa velocità e carico Backup PC quando si abilita la modalità di trasferimento rsync, distribuire il backup per
7 minuti e 42 secondi:
Ma in modalità di trasferimento dati, BackupPC ha affrontato il tar più lentamente: in 12 minuti e 15 secondi, il carico del processore era generalmente inferiore
una volta e mezza:
Duplicity senza crittografia ha mostrato risultati leggermente migliori, ripristinando un backup in 10 minuti e 58 secondi. Se attivi la crittografia utilizzando gpg, il tempo di ripristino aumenta a 15 minuti e 3 secondi. Inoltre, quando si crea un repository per l'archiviazione delle copie, è possibile specificare la dimensione dell'archivio che verrà utilizzata durante la suddivisione del flusso di dati in entrata. In generale, sugli hard disk convenzionali, anche a causa della modalità operativa a thread singolo, non c'è molta differenza. Potrebbe apparire con dimensioni di blocco diverse quando viene utilizzato lo storage ibrido. Il carico sul server principale durante il ripristino era il seguente:
nessuna crittografia
con crittografia
Duplicati ha mostrato un tasso di recupero paragonabile, completandolo in 13 minuti e 45 secondi. Sono stati necessari circa altri 5 minuti per verificare la correttezza dei dati recuperati (per un totale di circa 19 minuti). Il carico era
piuttosto elevato:
Quando la crittografia aes era abilitata internamente, il tempo di ripristino era di 21 minuti e 40 secondi, con l'utilizzo della CPU al massimo (entrambi i core!) durante il ripristino; Durante il controllo dei dati, era attivo un solo thread, che occupava un core del processore. Il controllo dei dati dopo il ripristino ha richiesto gli stessi 5 minuti (quasi 27 minuti in totale).
risultato
duplicati è stato un po' più veloce nel ripristino quando si utilizza il programma gpg esterno per la crittografia, ma in generale le differenze rispetto alla modalità precedente sono minime. Il tempo di funzionamento è stato di 16 minuti e 30 secondi, con verifica dei dati in 6 minuti. Il carico era
è la seguente:
AMANDA, usando tar, lo ha completato in 2 minuti e 49 secondi, il che, in linea di principio, è molto vicino al normale tar. Carico sul sistema in linea di principio
lo stesso:
Quando si ripristina un backup utilizzando zbackup Sono stati ottenuti i seguenti risultati:
crittografia, compressione lzma
Durata 11 minuti e 8 secondi
Crittografia AES, compressione lzma
Orario di lavoro 14 minuti
Crittografia AES, compressione lzo
Durata 6 minuti e 19 secondi
Nel complesso, non male. Tutto dipende dalla velocità del processore sul server di backup, che può essere vista chiaramente dal tempo di esecuzione del programma con diversi compressori. Sul lato del server di backup, è stato avviato un normale tar, quindi se lo confrontiamo, il ripristino è 3 volte più lento. Potrebbe valere la pena verificare il funzionamento in modalità multi-thread, con più di due thread.
BorgBackup in modalità non crittografata era un po 'più lento di tar, in 2 minuti e 45 secondi, tuttavia, a differenza di tar, è diventato possibile deduplicare il repository. Il carico si è rivelato essere
seguenti:
Se abiliti la crittografia basata su Blake, la velocità di ripristino del backup sarà leggermente più lenta. Il tempo di recupero in questa modalità è di 3 minuti e 19 secondi e il carico è sparito
come questo:
La crittografia AES è leggermente più lenta, il tempo di ripristino è di 3 minuti e 23 secondi, il carico è particolarmente elevato
non è cambiato:
Poiché Borg può funzionare in modalità multi-thread, il carico del processore è massimo e quando vengono attivate funzioni aggiuntive, il tempo di funzionamento aumenta semplicemente. Apparentemente vale la pena esplorare il multithreading in modo simile a zbackup.
Resto ha affrontato il recupero un po' più lentamente, il tempo di funzionamento è stato di 4 minuti e 28 secondi. Il carico sembrava
come segue:
Apparentemente il processo di ripristino funziona in diversi thread, ma l'efficienza non è elevata come quella di BorgBackup, ma paragonabile in termini di tempo al normale rsync.
Con urBackup È stato possibile ripristinare i dati in 8 minuti e 19 secondi, il carico era
è la seguente:
Il carico non è ancora molto elevato, addirittura inferiore a quello del catrame. In alcuni punti si verificano esplosioni, ma non più del carico di un core.
Selezione e giustificazione dei criteri di confronto
Come affermato in uno degli articoli precedenti, il sistema di backup deve soddisfare i seguenti criteri:
- Facilità d'uso
- Universalismo
- stabilità
- rapidità
Vale la pena considerare ogni punto separatamente in modo più dettagliato.
Facilità di funzionamento
È meglio quando c'è un pulsante "Fai tutto bene", ma se torni ai programmi reali, la cosa più conveniente sarà un principio operativo familiare e standard.
La maggior parte degli utenti probabilmente starà meglio se non dovrà ricordare un mucchio di chiavi per cli, configurare una serie di opzioni diverse, spesso oscure, tramite web o tui, o impostare notifiche su operazioni non riuscite. Ciò include anche la capacità di “adattare” facilmente una soluzione di backup all’infrastruttura esistente, nonché l’automazione del processo di backup. C'è anche la possibilità di installazione utilizzando un gestore di pacchetti o con uno o due comandi come "scarica e decomprimi". curl ссылка | sudo bash - un metodo complesso, poiché occorre verificare cosa arriva tramite il collegamento.
Ad esempio, tra i candidati considerati, una soluzione semplice è burp, rdiff-backup e restic, che dispongono di tasti mnemonici per diverse modalità operative. Leggermente più complessi sono borg e duplicity. La più difficile è stata AMANDA. Il resto si colloca a metà strada in termini di facilità d'uso. In ogni caso, se ti servono più di 30 secondi per leggere il manuale utente, oppure devi andare su Google o su un altro motore di ricerca, e anche scorrere un lungo foglio di aiuto, la decisione è difficile, in un modo o nell'altro.
Alcuni dei candidati considerati sono in grado di inviare automaticamente un messaggio tramite e-mailjabber, mentre altri si affidano ad avvisi configurati nel sistema. Inoltre, molto spesso le soluzioni complesse hanno impostazioni di avviso non del tutto ovvie. In ogni caso, se il programma di backup produce un codice di ritorno diverso da zero, che verrà compreso correttamente dal servizio di sistema per le attività periodiche (un messaggio verrà inviato all'amministratore di sistema o direttamente al monitoraggio), la situazione è semplice. Ma se il sistema di backup, che non viene eseguito su un server di backup, non può essere configurato, il modo più ovvio per dire il problema è che la complessità è già eccessiva. In ogni caso, inviare avvisi e altri messaggi solo all'interfaccia web o al registro è una cattiva pratica, poiché molto spesso verranno ignorati.
Per quanto riguarda l'automazione, un semplice programma può leggere le variabili di ambiente che ne impostano la modalità operativa, oppure ha una CLI sviluppata che può duplicare completamente il comportamento quando si lavora attraverso un'interfaccia web, ad esempio. Ciò include anche la possibilità di funzionamento continuo, la disponibilità di opportunità di espansione, ecc.
Universalismo
Riprendendo in parte il paragrafo precedente riguardante l'automazione, non dovrebbe essere un problema particolare “adattare” il processo di backup all'infrastruttura esistente.
Vale la pena notare che l'uso di porte non standard (beh, ad eccezione dell'interfaccia web) per il lavoro, l'implementazione della crittografia in modo non standard, lo scambio di dati utilizzando un protocollo non standard sono segni di una -soluzione universale. Nella maggior parte dei casi, tutti i candidati in un modo o nell'altro li possiedono per l'ovvio motivo: semplicità e versatilità di solito non vanno d'accordo. Come eccezione - rutto, ce ne sono altri.
Come segno: la capacità di lavorare utilizzando il normale ssh.
Velocità di lavoro
Il punto più controverso e controverso. Da un lato, abbiamo avviato il processo, ha funzionato il più rapidamente possibile e non ha interferito con i compiti principali. D'altro canto, durante il periodo di backup si verifica un aumento del traffico e del carico del processore. Vale anche la pena notare che i programmi più veloci per fare copie sono solitamente i più poveri in termini di funzioni importanti per gli utenti. Ancora una volta: se per ottenere uno sfortunato file di testo di diverse decine di byte con una password, e per questo motivo l'intero servizio costa (sì, sì, capisco che il processo di backup molto spesso non è da biasimare qui), ed è necessario rileggere in sequenza tutti i file nel repository o espandere l'intero archivio: il sistema di backup non è mai veloce. Un altro punto che spesso diventa un ostacolo è la velocità di distribuzione di un backup da un archivio. C'è un chiaro vantaggio qui per coloro che possono semplicemente copiare o spostare i file nella posizione desiderata senza troppe manipolazioni (rsync, ad esempio), ma molto spesso il problema deve essere risolto in modo organizzativo, empiricamente: misurando il tempo di ripristino del backup e informare apertamente gli utenti al riguardo.
stabilità
Va inteso così: da un lato la copia di backup deve poter essere riutilizzata in qualsiasi modo, dall'altro deve essere resistente a diversi problemi: interruzione della rete, guasto del disco, cancellazione di parte del deposito.
Confronto degli strumenti di backup
Ora di creazione della copia
Copia il tempo di recupero
Installazione facile
Configurazione semplice
Uso semplice
Automazione semplice
Hai bisogno di un client-server?
Verifica dell'integrità del repository
Copie differenziali
Funzionamento tramite tubo
Universalismo
indipendenza
Trasparenza del repository
Шифрование
compressione
Deduplicazione
interfaccia web
Riempimento fino alla nuvola
Supporto Windows
contrassegno
rsync
4m15s
4m28s
sì
no
no
no
sì
no
no
sì
no
sì
sì
no
no
no
no
no
sì
6
Catrame
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ì
Backup Rdiff
16m26s
17m17s
sì
sì
sì
sì
sì
no
sì
no
sì
no
sì
no
sì
sì
sì
no
sì
11
Ristantanea
4m19s
4m28s
sì
sì
sì
sì
no
no
sì
no
sì
no
sì
no
no
sì
sì
no
sì
12,5
Rutto
11m9s
7m2s
sì
no
sì
sì
sì
sì
sì
no
sì
sì
no
no
sì
no
sì
no
sì
10,5
Duplicity
nessuna 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
nessuna 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
nessuna 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
nessuna 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
Resto
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
Backup PC
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 tabella:
- Verde, autonomia inferiore a cinque minuti, oppure risposta “Sì” (ad eccezione della colonna “Hai bisogno di un client server?”), 1 punto
- Giallo, tempo di funzionamento da cinque a dieci minuti, 0.5 punti
- Rosso, il tempo di lavoro è superiore a dieci minuti, oppure la risposta è “No” (ad eccezione della colonna “Hai bisogno di un client server?”), 0 punti
Secondo la tabella sopra, lo strumento di backup più semplice, veloce e allo stesso tempo conveniente e potente è BorgBackup. Restic ha preso il secondo posto, il resto dei candidati considerati si è piazzato più o meno allo stesso modo con uno spread di uno o due punti alla fine.
Ringrazio tutti coloro che hanno letto la serie fino alla fine, vi invito a discutere le opzioni e offrire le vostre, se presenti. Man mano che la discussione procede la tabella potrà essere ampliata.
Il risultato della serie sarà l'articolo finale, in cui si tenterà di sviluppare uno strumento di backup ideale, veloce e gestibile che consenta di distribuire nuovamente una copia nel più breve tempo possibile e allo stesso tempo sia comodo e facile da configurare e mantenere.
annuncio
Backup Parte 6: Confronto degli strumenti di backup
Backup Parte 7: Conclusioni
Fonte: habr.com