In questo articolo vengono discussi i strumenti di backup che eseguono il backup creando archivi su un server di riserva.
Tra quelli che soddisfano i requisiti ci sono duplicity (per il quale esiste una piacevole interfaccia in forma di deja dup) e duplicati.
Un altro strumento di backup molto interessante è dar, ma poiché ha un elenco di opzioni piuttosto ampio, la metodologia di test copre a malapena il 10% di ciò di cui è capace; non lo testeremo nel ciclo attuale.
Risultati attesi
Poiché entrambi i candidati in un modo o nell'altro creano archivi, come riferimento possiamo usare il comune tar.
Valuteremo inoltre quanto bene viene ottimizzato lo storage dei dati sul server di archiviazione creando backup che contengono solo la differenza tra una copia completa e lo stato attuale dei file, o tra gli archivi passati e presenti (incrementali, decrementali, ecc.).
Comportamento nella 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 sufficientemente grande nel loro formato (decine-centinaia di megabyte).
- La dimensione del repository includerà solo le modifiche: i duplicati non verranno conservati, quindi la dimensione del repository sarà inferiore rispetto a quando si utilizza un software basato su rsync.
- Ci si aspetta un carico di lavoro maggiore sulla CPU quando si utilizza la compressione e/o la crittografia, e probabilmente anche un carico di rete e di sistema di archiviazione significativo, se il processo di archiviazione e/o crittografia avviene sul server di 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 stati i seguenti:
Il tempo di esecuzione è stato di 3m12s. È evidente che la velocità è stata limitata dal sistema di archiviazione del server di backup, come nell'esempio con . Solo un po' più veloce, poiché la scrittura avviene in un unico file.
Per valutare ulteriormente la compressione, eseguiamo 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. È probabile che il collo di bottiglia sia il compressore a thread singolo sul lato ricevente.
Stessa squadra, ma con compressione spostata sul server con i dati originali per verificare l'ipotesi che il collo di bottiglia sia il compressore single-thread.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Risultato:
Il tempo di esecuzione è stato di 9m37s. È chiaro che uno dei core è saturato dal compressore, poiché la velocità di trasferimento sulla rete e il carico sul sottosistema disco di origine sono simili.
Per valutare la crittografia si possono utilizzare openssl o gpg, collegando una linea aggiuntiva openssl o gpg nel pipe. Un esempio di comando sarebbe:
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 è di nuovo il compressore single-thread, più un piccolo sovraccarico per la crittografia.
UPD: Su richiesta di bliznezz, aggiungo i test con pigz. Se si utilizza solo il compressore, si è ottenuto un tempo di 6m30s, se si aggiunge anche la crittografia, il tempo è di circa 7m. Il crollo nel grafico in basso è dovuto alla cache del disco non svuotata:
Test di duplicity
Duplicity è un software in python per il backup che crea archivi crittografati in formato tar.
Per archivi incrementali viene utilizzato librsync, quindi ci si può aspettare un comportamento descritto nella .
I backup possono essere crittografati e firmati utilizzando gnupg, il che è importante quando si utilizzano diversi provider per l'archiviazione dei backup (s3, backblaze, gdrive, ecc.).
Vediamo quali saranno i risultati:
Ecco quali risultati sono stati ottenuti senza crittografia
spoiler
Tempo di esecuzione di ciascun avvio di test:
Avvio 1
Avvio 2
Avvio 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Ecco i risultati con la crittografia gnupg attivata, con una dimensione della chiave di 2048 bit:
Tempo di esecuzione sugli stessi dati, con crittografia:
Avvio 1
Avvio 2
Avvio 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
È stata specificata una dimensione del blocco di 512 megabyte, il che è chiaramente visibile nei grafici; il carico della CPU si è mantenuto attorno al 50%, il che significa che il programma utilizza al massimo un core della CPU.
Si comprende anche abbastanza bene il principio di funzionamento del programma: abbiamo preso un pezzo di dati, lo abbiamo compresso, e l'abbiamo inviato al server di archiviazione dei backup, che può essere piuttosto lento.
Un'altra caratteristica è il tempo di lavoro del programma, che dipende solo dalle dimensioni dei dati modificati.
L'attivazione della crittografia non ha aumentato particolarmente il tempo di esecuzione del programma, ma ha incrementato il carico della CPU di circa il 10%, il che può essere un piacevole bonus.
Sfortunatamente, questo programma non è riuscito a rilevare correttamente la situazione con il rinominamento della directory, e la dimensione risultante del repository è stata uguale alla dimensione delle modifiche (cioè tutti i 18 GB), ma la possibilità di utilizzare un server non attendibile per il backup sovrasta senza dubbio questo comportamento.
Test di duplicati
Questo software è scritto in C# e viene eseguito utilizzando un insieme di librerie di Mono. Dispone di un'interfaccia grafica e di una versione CLI.
L'elenco approssimativo delle principali funzionalità è simile a quello di duplicity, includendo diversi fornitori per lo storage dei backup, ma, a differenza di duplicity, la maggior parte delle funzionalità sono disponibili senza strumenti di terze parti. Se sia un vantaggio o uno svantaggio dipende dal caso specifico, ma per i neofiti è probabilmente più facile avere un elenco completo di tutte le funzionalità piuttosto che installare pacchetti per Python come nel caso di duplicity.
Un altro piccolo dettaglio è che il programma scrive attivamente un database locale sqlite a nome dell'utente che avvia il backup, quindi è necessario prestare attenzione ad indicare correttamente il database corretto ad ogni avvio del processo usando la CLI. Quando si lavora tramite GUI o WEBGUI, i dettagli sono nascosti all'utente.
Vediamo quali risultati può fornire questa soluzione:
Se si disattiva la crittografia (anche se il WEBGUI non lo consiglia), i risultati sono i seguenti:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Con la crittografia attivata, utilizzando aes, otteniamo:
Tempo di esecuzione:
Avvio 1
Avvio 2
Avvio 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
E se si utilizza un programma esterno come 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 può funzionare in più thread, ma questo non lo rende una soluzione più performante, e se confrontiamo l'esecuzione della crittografia, l'avvio di un programma esterno
si è rivelato più veloce rispetto all'uso della libreria del pacchetto Mono. Probabilmente ciò è dovuto al fatto che il programma esterno è più ottimizzato.
Un aspetto piacevole è stato anche il fatto che la dimensione del repository occupa esattamente quanto i dati che sono stati effettivamente modificati, cioè duplicati ha rilevato il rinominamento della directory e ha gestito correttamente questa situazione. Questo può essere osservato durante l'esecuzione del secondo test.
In generale, impressioni piuttosto positive del programma, inclusa una sufficiente facilità d'uso per i principianti.
Risultati
Entrambi i candidati hanno lavorato piuttosto lentamente, ma in generale, rispetto al normale tar, c'è progresso, almeno per duplicati. Il costo di tale progresso è anche comprensibile: un carico notevole
del processore. In generale, non ci sono particolari deviazioni nelle previsioni dei risultati.
Conclusioni
Se non c'è fretta e c'è anche una riserva di elaborazione - qualsiasi delle soluzioni esaminate andrà bene, in ogni caso è stata svolta un lavoro piuttosto ampio, che non vale la pena ripetere scrivendo script di avvolgimento sopra tar. La presenza della crittografia è una caratteristica molto necessaria, se il server per la memorizzazione dei backup non può essere completamente fidato.
Se comparato con soluzioni basate su — le prestazioni potrebbero essere inferiori di diversi fattori, nonostante il fatto che in termini di tempo puro tar abbia lavorato più velocemente di rsync del 20-30%.
C'è un risparmio sulle dimensioni del repository, ma solo per duplicati.
Annuncio
Backup, parte 3: Revisione 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 for Linux
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Autore della pubblicazione: Pavel Demkovich
Fonte: habr.com
