{"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 confronteremo i strumenti di backup, ma prima \u00e8 opportuno conoscere quanto velocemente ed efficacemente gestiscono il ripristino dei dati dai backup.
\nPer semplificare il confronto, verr\u00e0 considerato il ripristino da un backup completo, dato che questa modalit\u00e0 \u00e8 supportata da tutti i candidati. Per facilitare la comprensione, i numeri sono stati presi gi\u00e0 mediati (la media aritmetica di diversi avvii). I risultati saranno riassunti in una tabella, che conterr\u00e0 anche informazioni sulle funzionalit\u00e0: presenza di un'interfaccia web, facilit\u00e0 di configurazione e utilizzo, capacit\u00e0 di automazione, presenza di diverse 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 i server dedicati ai backup).
\n<\/a><\/noindex><\/p>\n

Recupero dei dati<\/h2>\n

\nI punti di riferimento saranno rsync e tar, poich\u00e9 su di essi si basano di solito<\/a><\/noindex> i pi\u00f9 semplici script per la creazione di backup.<\/p>\n

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

un carico del genere<\/b>\"Backup,
\n
\nIl processo di recupero \u00e8 stato ostacolato dalle limitazioni del sottosistema di archiviazione del server di backup (grafici a dente di sega). \u00c8 chiaramente visibile anche il carico di un singolo core senza particolari problemi (basso iowait e softirq \u2014 nessun problema con il disco e la rete, rispettivamente). Poich\u00e9 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.<\/p>\n

Tar<\/i> ha completato la procedura un po' pi\u00f9 velocemente, in <\/p>\n

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

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

In rdiff-backup<\/i> \u00e8 possibile sincronizzare l'ultimo backup effettuato utilizzando il normale 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
\nForse \u00e8 stato progettato in questo modo, almeno per limitare la velocit\u00e0, gli autori propongono questa soluzione<\/a><\/noindex>. Il processo di ripristino del backup richiede un po' meno della met\u00e0 di un core, con prestazioni proporzionalmente comparabili (cio\u00e8 da 2 a 5 volte pi\u00f9 lente) su disco e rete con rsync.<\/p>\n

Rsnapshot<\/i> per il ripristino suggerisce di utilizzare il normale rsync, quindi i suoi risultati saranno simili. In generale, \u00e8 esattamente cos\u00ec che \u00e8 andata.<\/p>\n

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

Un programma ha mostrato circa la stessa velocit\u00e0 e carico BackupPC<\/i> attivando la modalit\u00e0 di trasferimento rsync, completando il ripristino in <\/p>\n

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

di un fattore e mezzo:<\/b>\"Backup,
\n
\nDuplicity<\/i> 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, \u00e8 possibile specificare la dimensione dell'archivio che verr\u00e0 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\u00e0 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:<\/p>\n

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

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

Risultato<\/b>\"Backup,
\n
\nDuplicati \u00e8 riuscito a completare il ripristino un po' pi\u00f9 velocemente utilizzando un programma esterno gpg per la crittografia, ma nel complesso le differenze rispetto alla modalit\u00e0 precedente sono minime. Il tempo di esecuzione \u00e8 stato di 16 minuti e 30 secondi, con un controllo dei dati di 6 minuti. Il carico \u00e8 stato <\/p>\n

tale:<\/b>\"Backup,
\n
\nAMANDA<\/i>, che utilizza tar, ha impiegato 2 minuti e 49 secondi, il che \u00e8 piuttosto vicino al normale tar. Il carico del sistema \u00e8 stato sostanzialmente <\/p>\n

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

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

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

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

In generale, non c'\u00e8 male. Tutto dipende dalla velocit\u00e0 del processore sul server di backup, il che \u00e8 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\u00f9 lentamente. Forse vale la pena verificare l'operativit\u00e0 in modalit\u00e0 multithreading, con un numero di thread superiore a due.<\/p>\n

BorgBackup<\/i> in modalit\u00e0 senza crittografia ha eseguito un po' pi\u00f9 lentamente di tar, impiegando 2 minuti e 45 secondi, tuttavia, a differenza del tar, \u00e8 stata offerta la possibilit\u00e0 di deduplicazione del repository. In questo caso, 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 diminuisce leggermente. Il tempo di ripristino in questa modalit\u00e0 \u00e8 di 3 minuti e 19 secondi, e il carico \u00e8 risultato <\/p>\n

questo:<\/b>\"Backup,
\n
\nLa crittografia aes funziona un po' pi\u00f9 lentamente, il tempo di ripristino \u00e8 di 3 minuti e 23 secondi, e il carico non \u00e8 cambiato particolarmente: <\/p>\n

non \u00e8 cambiato:<\/b>\"Backup,
\n
\nDal momento che Borg pu\u00f2 funzionare in modalit\u00e0 multithreading, il carico della CPU \u00e8 massimo, mentre attivando funzionalit\u00e0 aggiuntive aumenta semplicemente il tempo di esecuzione. \u00c8 evidente che vale la pena esaminare il multithreading in modo analogo a zbackup.<\/p>\n

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

cos\u00ec:<\/b>\"Backup,
\n
\n\u00c8 evidente che 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

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

tale:<\/b>\"Backup,
\n
\nSi nota ancora un carico non molto elevato, addirittura inferiore a quello di tar. Ci sono picchi qua e l\u00e0, ma non supera il carico di un singolo core.<\/p>\n

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

\nCome accennato in uno dei precedenti articoli, il sistema di backup deve soddisfare i seguenti criteri:<\/p>\n