In questo articolo esaminiamo strumenti di backup che eseguono il salvataggio creando archivi su un server di riserva.
Tra quelli che soddisfano i requisiti ci sono duplicity (che ha una comoda interfaccia chiamata deja dup) e duplicati.
Un altro strumento di backup notevole è dar, ma poiché ha un elenco molto ampio di opzioni, la nostra metodologia di test copre a malapena il 10% di quello che è in grado di fare, quindi non lo testeremo in questo ciclo.
Risultati attesi
Poiché entrambi i candidati in un modo o nell'altro creano archivi, possiamo utilizzare il normale tar come riferimento.
Valuteremo anche quanto bene viene ottimizzato lo storage dei dati sul server di backup creando copie che contengono solo la differenza tra una copia completa e lo stato attuale dei file, o tra archivi passati e presenti (incrementali, decrementali, ecc.).
Comportamento durante la creazione dei backup:
- Un numero relativamente ridotto di file sul server di backup (paragonabile al numero di backup o alla dimensione dei dati in GB), ma con una dimensione sufficientemente grande (decine-centinaia di megabyte).
- La dimensione del repository includerà solo le modifiche—i duplicati non saranno memorizzati, quindi la dimensione del repository sarà inferiore rispetto all'utilizzo di software basato su rsync.
- Ci si aspetta un carico maggiore sulla CPU quando si utilizza la compressione e/o la crittografia, e probabilmente anche un carico significativo sulla rete e sul sottosistema disco, se il processo di archiviazione e/o crittografia viene eseguito sul server di archiviazione dei backup.
Come valore di riferimento, eseguiamo il seguente comando:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"I risultati dell'esecuzione sono i seguenti:
Il tempo di esecuzione è stato di 3m12s. È evidente che la velocità è stata limitata dal sottosistema disco del server di archiviazione dei backup, proprio come nell'esempio con . Solo un po' più veloce, poiché la scrittura avviene in un unico file.
Per valutare la compressione, eseguiamo anche la stessa variante, ma attiviamo la compressione sul server di backup:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"I risultati sono i seguenti:
Il tempo di esecuzione è stato di 10m11s. Il collo di bottiglia è probabilmente il compressore monostream sul lato ricevente.
La stessa comando, ma con il trasferimento della compressione sul server con i dati di origine per verificare l'ipotesi che il collo di bottiglia è il compressore a thread singolo.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Ecco cosa è successo:
Il tempo di esecuzione è stato di 9m37s. È evidente il carico di un core da parte del compressore, poiché la velocità di trasmissione sulla rete e il carico sul sottosistema disco sorgente sono simili.
Per valutare la crittografia puoi utilizzare openssl o gpg, aggiungendo un comando supplementare openssl o gpg in pipe. Come riferimento, ci sarà questo comando:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"I risultati sono stati i seguenti:
Il tempo di esecuzione è stato di 10m30s, poiché sono stati avviati 2 processi sul lato ricevente — il collo di bottiglia è nuovamente il compressore a thread singolo, più qualche spesa aggiuntiva per la crittografia.
UPD: Su richiesta di bliznezz, aggiungo i test con pigz. Se si utilizza solo il compressore — ci è voluto 6m30s, se si aggiunge anche la crittografia — circa 7m. Il fallimento nell'inferiore grafico — cache disco non ripristinata:
Test di duplicity
Duplicity è un software in python per il backup creando archivi crittografati in formato tar.
Per gli archivi incrementali si utilizza librsync, quindi ci si può aspettare il comportamento descritto nella .
Le copie di sicurezza possono essere crittografate e firmate con gnupg, il che è importante quando si utilizzano diversi fornitori per la memorizzazione di backup (s3, backblaze, gdrive, ecc.)
Vediamo quali saranno i risultati:
Questi sono i risultati ottenuti eseguendo senza crittografia
spoiler
Tempo di esecuzione di ciascun avvio di prova:
Avvio 1
Avvio 2
Avvio 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Ecco i risultati con la crittografia gnupg abilitata, con una dimensione della chiave di 2048 bit:
Tempo di lavoro con gli stessi dati, con crittografia:
Avvio 1
Avvio 2
Avvio 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
È stata specificata la dimensione del blocco — 512 megabyte, come si vede chiaramente nei grafici; il carico della CPU è rimasto effettivamente intorno al 50%, muovendo il programma a utilizzare non più di un core del processore.
Si vede anche abbastanza bene il principio di funzionamento del programma: prendersi un pezzo di dati, comprimerlo, inviarlo al server di archiviazione di backup, che può essere piuttosto lento.
Un'altra caratteristica è che il tempo di esecuzione del programma è prevedibile e dipende solo dalla dimensione dei dati modificati.
L'attivazione della crittografia non ha aumentato particolarmente il tempo di esecuzione del programma, ma ha aumentato il carico della CPU di circa il 10%, il che può essere un buon bonus.
Sfortunatamente, questo programma non è riuscito a rilevare correttamente la situazione di rinominazione della directory, e la dimensione risultante del repository è risultata essere uguale alla dimensione delle modifiche (cioè tutti i 18 GB), ma la possibilità di utilizzare un server non fidato per il backup supera decisamente un tale comportamento.
Test di duplicati
Questo software è scritto in C# e si avvia utilizzando un insieme di librerie di Mono. È disponibile sia una versione GUI che una versione CLI.
L'elenco delle principali funzionalità è simile a quello di duplicity, compresi vari fornitori per l'archiviazione dei backup; tuttavia, a differenza di duplicity, la maggior parte delle funzionalità è disponibile senza strumenti di terze parti. Che si tratti di un vantaggio o di uno svantaggio dipende dal caso specifico, ma per i principianti è probabilmente più semplice avere a disposizione un elenco di tutte le funzionalità piuttosto che dover installare pacchetti per Python, come nel caso di duplicity.
Un altro piccolo dettaglio: il programma scrive attivamente un database locale sqlite a nome dell'utente che avvia il backup, quindi è necessario prestare attenzione a specificare correttamente il database corretto ad ogni avvio del processo usando il cli. Quando si utilizza GUI o WEBGUI, i dettagli saranno nascosti all'utente.
Vediamo quali risultati può fornire questa soluzione:
Se si disattiva la crittografia (anche se WEBGUI sconsiglia di farlo), i risultati sono i seguenti:
Tempo di lavoro:
Avvio 1
Avvio 2
Avvio 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Con la crittografia attivata, utilizzando aes, i risultati sono:
Tempo di lavoro:
Avvio 1
Avvio 2
Avvio 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Se si utilizza un programma esterno gnupg, i risultati sono i seguenti:
Avvio 1
Avvio 2
Avvio 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Come si può vedere, il programma è in grado di lavorare in più thread, ma ciò non lo rende una soluzione più performante, e confrontando il funzionamento della crittografia, l'avvio di un programma esterno
risulta essere più veloce rispetto all'uso della libreria del pacchetto Mono. Questo potrebbe essere dovuto al fatto che il programma esterno è più ottimizzato.
Un aspetto positivo è stato il fatto che la dimensione del repository occupa esattamente la quantità di dati effettivamente modificati, ovvero duplicati ha rilevato la rinominazione della directory e ha gestito correttamente questa situazione. Questo è visibile durante l'esecuzione del secondo test.
In generale, impressioni piuttosto positive sul programma, compresa una sufficiente facilità d'uso per i principianti.
Risultati
Entrambi i candidati hanno lavorato in modo piuttosto lento, ma nel complesso, rispetto al solito tar, c'è progresso, almeno per duplicati. Il prezzo di questo progresso è chiaro: un carico evidente
sulla CPU. In generale, non ci sono particolari deviazioni nelle previsioni dei risultati.
Conclusioni
Se non c'è fretta e c'è una capacità di CPU disponibile, qualsiasi soluzione considerata andrà bene, in ogni caso è stato fatto un lavoro abbastanza grande che non vale la pena ripetere scrivendo script wrapper sopra tar. La crittografia è una caratteristica molto utile se il server per il backup non può essere completamente affidabile.
Se si confronta con soluzioni basate su — le prestazioni possono essere inferiori anche di diversi ordini di grandezza, nonostante il fatto che tar, in forma puramente grezza, abbia funzionato più velocemente di rsync del 20-30%.
C'è un risparmio sulle dimensioni del repository, ma solo con duplicati.
Annuncio
Backup, parte 3: Panoramica e test di duplicity, duplicati, deja dup
Backup, parte 4: Panoramica e test di zbackup, restic, borgbackup
Backup, parte 5: Test di bacula e veeam backup per linux
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Autore della pubblicazione: Pavel Demkovich
Fonte: habr.com
