{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, parte 6: Confronto degli strumenti di backup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nIn questo articolo verr\u00e0 effettuato un confronto degli strumenti di backup, ma prima \u00e8 importante capire come gestiscono il ripristino dei dati da backup in modo rapido ed efficace.
\nPer semplificare il confronto, verr\u00e0 considerato il ripristino da un backup completo, poich\u00e9 questo modo di operare \u00e8 supportato da tutti i candidati. Per semplificare, i numeri sono stati gi\u00e0 mediati (media aritmetica di vari avvii). I risultati saranno riassunti in una tabella, che conterr\u00e0 anche informazioni riguardo alle funzionalit\u00e0: presenza di un'interfaccia web, facilit\u00e0 di configurazione e utilizzo, capacit\u00e0 di automazione, disponibilit\u00e0 di varie funzionalit\u00e0 aggiuntive (ad esempio, verifica dell'integrit\u00e0 dei dati) e cos\u00ec via. I grafici mostreranno il carico del server dove i dati verranno applicati (non il server per lo storage dei backup).
\n<\/a><\/noindex><\/p>\n

Ripristino dei dati<\/h2>\n

\nCome punto di riferimento verranno utilizzati rsync e tar, poich\u00e9 \u00e8 su di essi che solitamente si basano<\/a><\/noindex> i semplici script per effettuare backup.<\/p>\n

Rsync<\/i> ha completato il set di dati di test in 4 minuti e 28 secondi, mostrando <\/p>\n

questo carico<\/b>\"Backup,
\n
\nIl processo di ripristino \u00e8 stato limitato dalle restrizioni del sottosistema di memorizzazione dei backup (grafici a zig-zag). \u00c8 anche evidente il carico su un singolo core senza particolari problemi (basso iowait e softirq \u2014 nessun problema con disco e rete, rispettivamente). Poich\u00e9 gli altri due programmi, cio\u00e8 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.<\/p>\n

Tar<\/i> \u00e8 riuscito a completare il processo leggermente pi\u00f9 velocemente, in <\/p>\n

2 minuti e 43 secondi:<\/b>\"Backup,
\n
\nIl carico totale del sistema \u00e8 stato superiore di media del 20% a causa dell\u2019aumento del softirq \u2014 sono aumentati i costi operativi del sottosistema di rete.<\/p>\n

Se l'archivio viene compresso ulteriormente, il tempo di ripristino aumenta a 3 minuti e 19 secondi con
\nquesto carico sul server principale (decompressione sul lato del server principale):<\/b>\"Backup,
\n
\nIl processo di estrazione utilizza entrambi i core della CPU, poich\u00e9 vengono eseguiti due processi. Nel complesso, \u00e8 un risultato atteso. Anche un risultato comparabile (3 minuti e 20 secondi) \u00e8 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).<\/p>\n

In rdiff-backup<\/i> \u00e8 possibile sincronizzare l'ultimo backup effettuato utilizzando il comune rsync (i risultati saranno simili), ma i backup pi\u00f9 vecchi devono comunque essere ripristinati utilizzando il programma rdiff-backup, che ha completato il ripristino in 17 minuti e 17 secondi, mostrando <\/p>\n

questo carico:<\/b>\"Backup,
\n
\nPotrebbe essere stata questa l'intenzione, ad ogni modo per limitare la velocit\u00e0 gli autori propongono questa soluzione<\/a><\/noindex>. Il processo di ripristino del backup richiede poco meno della met\u00e0 di un core, con prestazioni proporzionalmente comparabili (cio\u00e8 da 2 a 5 volte pi\u00f9 lente) in termini di disco e rete con rsync.<\/p>\n

Rsnapshot<\/i> propone di utilizzare il comune rsync per il ripristino, quindi i suoi risultati saranno simili. In effetti, \u00e8 stato cos\u00ec.<\/p>\n

Burp<\/i> ha completato il compito di ripristino del backup in 7 minuti e 2 secondi con
\nquesto carico:<\/b>\"Backup,
\n
\nHa funzionato abbastanza velocemente, e almeno \u00e8 molto pi\u00f9 conveniente rispetto al semplice rsync: non \u00e8 necessario ricordare alcun flag, interfaccia cli semplice e intuitiva, supporto integrato per pi\u00f9 copie, anche se \u00e8 circa due volte pi\u00f9 lento. Se i dati devono essere ripristinati dall'ultimo backup effettuato, \u00e8 possibile utilizzare rsync, con alcune piccole avvertenze.<\/p>\n

Un programma BackupPC<\/i> ha mostrato una velocit\u00e0 e un carico simili attivando la modalit\u00e0 di trasferimento rsync, completando il backup in <\/p>\n

7 minuti e 42 secondi:<\/b>\"Backup,
\n
\nTuttavia, in modalit\u00e0 di trasferimento dati con tar, BackupPC ha impiegato pi\u00f9 tempo: 12 minuti e 15 secondi, e il carico della CPU \u00e8 stato in generale inferiore <\/p>\n

di un fattore e mezzo:<\/b>\"Backup,
\n
\nDuplicity<\/i> 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, \u00e8 possibile specificare la dimensione dell'archivio che sar\u00e0 utilizzata per suddividere il flusso di dati in ingresso. In generale, su normali dischi rigidi, a causa della modalit\u00e0 di lavoro a thread singolo, non c'\u00e8 una differenza particolare. Questa potrebbe apparire con diverse dimensioni dei blocchi, quando vengono utilizzati archiviazioni ibride. Il carico sul server principale durante il ripristino \u00e8 stato il seguente:<\/p>\n

senza crittografia<\/b>\"Backup,
\n
\ncon crittografia<\/b>\"Backup,
\n
\nDuplicati<\/i> ha mostrato una velocit\u00e0 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 \u00e8 stato <\/p>\n

abbastanza elevato:<\/b>\"Backup,
\n
\nQuando la crittografia aes \u00e8 stata attivata tramite strumenti interni, il tempo di ripristino \u00e8 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).<\/p>\n

Risultato<\/b>\"Backup,
\n
\nLeggermente pi\u00f9 veloce, Duplicati ha gestito il ripristino utilizzando un programma esterno gpg per la crittografia, ma in generale le differenze rispetto alla modalit\u00e0 precedente sono minime. Il tempo di lavoro \u00e8 stato di 16 minuti e 30 secondi, con una verifica dei dati di 6 minuti. Il carico era <\/p>\n

di questo tipo:<\/b>\"Backup,
\n
\nAMANDA<\/i>, che utilizza tar, ha completato in 2 minuti e 49 secondi, che, in principio, \u00e8 molto vicino a un normale tar. Il carico sul sistema \u00e8 di fatto <\/p>\n

simile:<\/b>\"Backup,
\n
\nDurante il ripristino del backup utilizzando zbackup<\/i> si sono ottenuti i seguenti risultati:<\/p>\n

crittografia, compressione lzma<\/b>\"Backup,
\n
\nTempo di lavoro 11 minuti e 8 secondi<\/p>\n

crittografia aes, compressione lzma<\/b>\"Backup,
\n
\nTempo di lavoro 14 minuti<\/p>\n

crittografia aes, compressione lzo<\/b>\"Backup,
\n
\nTempo di lavoro 6 minuti, 19 secondi<\/p>\n

In generale, non \u00e8 male. Tutto dipende dalla velocit\u00e0 della CPU sul server di backup, che \u00e8 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\u00f9 lentamente. Potrebbe valere la pena controllare il funzionamento in modalit\u00e0 multithreading, con un numero di thread superiore a due.<\/p>\n

BorgBackup<\/i> in modalit\u00e0 senza crittografia ha funzionato un po' pi\u00f9 lentamente del tar, impiegando 2 minuti e 45 secondi, tuttavia, a differenza dello stesso tar, \u00e8 stata data la possibilit\u00e0 di deduplicare il repository. Il carico risultante \u00e8 stato <\/p>\n

il seguente:<\/b>\"Backup,
\n
\nSe si attiva la crittografia basata su blake, la velocit\u00e0 di ripristino del backup rallenta leggermente. Il tempo di ripristino in questa modalit\u00e0 \u00e8 di 3 minuti e 19 secondi, e il carico \u00e8 risultato <\/p>\n

cos\u00ec:<\/b>\"Backup,
\n
\nLa crittografia aes funziona leggermente pi\u00f9 lentamente, il tempo di ripristino \u00e8 di 3 minuti e 23 secondi, il carico non \u00e8 particolarmente <\/p>\n

cambiato:<\/b>\"Backup,
\n
\nPoich\u00e9 Borg pu\u00f2 funzionare in modalit\u00e0 multithreading, il carico della CPU \u00e8 massimo, mentre attivando funzioni aggiuntive aumenta semplicemente il tempo di esecuzione. Probabilmente, vale la pena esplorare la multithreading in modo simile a zbackup.<\/p>\n

Restic<\/i> ha gestito il ripristino un po' pi\u00f9 lentamente, il tempo di esecuzione \u00e8 stato di 4 minuti e 28 secondi. Il carico risultante \u00e8 stato <\/p>\n

in questo modo:<\/b>\"Backup,
\n
\nProbabilmente, il processo di ripristino funziona in pi\u00f9 thread, ma l'efficienza non \u00e8 cos\u00ec alta come quella di BorgBackup, ma \u00e8 comparabile nel tempo con il normale rsync.<\/p>\n

Utilizzando UrBackup<\/i> \u00e8 riuscito a ripristinare i dati in 8 minuti e 19 secondi, il carico risultante \u00e8 stato <\/p>\n

di questo tipo:<\/b>\"Backup,
\n
\nSi 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.<\/p>\n

Scelta e giustificazione dei criteri di confronto<\/h2>\n

\nCome \u00e8 stato detto in uno degli articoli precedenti, il sistema di backup deve soddisfare i seguenti criteri:<\/p>\n