Questa nota illustra gli strumenti di backup che eseguono backup creando archivi su un server di backup.
Tra quelli che soddisfano i requisiti ci sono duplicity (che ha una bella interfaccia sotto forma di deja dup) e duplicati.
Un altro strumento di backup davvero notevole è Dar, ma poiché ha un elenco molto ampio di opzioni (la metodologia di test copre appena il 10% di ciò di cui è capace) non lo testeremo come parte del ciclo attuale.
Risultati attesi
Poiché entrambi i candidati creano archivi in un modo o nell'altro, è possibile utilizzare tar normale come guida.
Inoltre, valuteremo come viene ottimizzata la memorizzazione dei dati sul server di storage, creando copie di backup contenenti solo la differenza tra una copia completa e lo stato attuale dei file, o tra l'archivio precedente e quello attuale (incrementale, decrementale, ecc.) .
Comportamento durante la creazione dei backup:
- Un numero relativamente piccolo di file sul server di archiviazione di backup (paragonabile al numero di copie di backup o alla dimensione dei dati in GB), ma la loro dimensione è piuttosto elevata (da decine a centinaia di megabyte).
- La dimensione del repository includerà solo le modifiche: non verranno archiviati duplicati, quindi la dimensione del repository sarà inferiore rispetto al software basato su rsync.
- È previsto un carico elevato della CPU quando si utilizza la compressione e/o la crittografia e probabilmente un carico della rete e del disco piuttosto elevato se il processo di archiviazione e/o crittografia è in esecuzione su un server di archiviazione di backup.
Eseguiamo il seguente comando come valore di riferimento:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"I risultati dell'esecuzione sono stati i seguenti:
Tempo di esecuzione 3m12s. Si può vedere che la velocità è limitata dal sottosistema del disco del server di archiviazione di backup, come nell'esempio con . Solo un po' più veloce, perché... la registrazione va su un file.
Inoltre, per valutare la compressione, eseguiamo la stessa opzione, ma abilitiamo la compressione sul lato del server di backup:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"I risultati sono i seguenti:
Tempo di esecuzione 10m11s. Molto probabilmente il collo di bottiglia è il compressore a flusso singolo sul lato ricevente.
Lo stesso comando, ma con la compressione trasferita al server con i dati originali per verificare l'ipotesi che il collo di bottiglia sia un compressore a thread singolo.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"È risultato così:
Il tempo di esecuzione è stato di 9 minuti e 37 secondi. Il carico su un nucleo del compressore è chiaramente visibile, perché La velocità di trasferimento di rete e il carico sul sottosistema del disco di origine sono simili.
Per valutare la crittografia, puoi utilizzare openssl o gpg collegando un comando aggiuntivo openssl o gpg nel tubo. Per riferimento ci sarà un comando come questo:
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 venuti così:
Il tempo di esecuzione si è rivelato essere di 10 minuti e 30 secondi, poiché sul lato ricevente erano in esecuzione 2 processi: il collo di bottiglia è ancora una volta un compressore a thread singolo, oltre a un piccolo sovraccarico di crittografia.
UPD: Su richiesta di bliznezz aggiungo i test con pigz. Se utilizzi solo il compressore, occorrerebbero 6 minuti e 30 secondi, se aggiungi anche la crittografia, sarebbero circa 7 milioni. Il calo nel grafico in basso è una cache del disco non svuotata:
Test duplicati
Duplicity è un software Python per il backup creando archivi crittografati in formato tar.
Per gli archivi incrementali, viene utilizzato librsync, quindi puoi aspettarti il comportamento descritto in .
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 sono i risultati:
Questi sono i risultati che abbiamo ottenuto durante l'esecuzione senza crittografia
spoiler
Tempo di esecuzione di ogni esecuzione di prova:
Lancio 1
Lancio 2
Lancio 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Ed ecco i risultati quando la crittografia gnupg è abilitata, con una dimensione della chiave di 2048 bit:
Tempo di funzionamento sugli stessi dati, con crittografia:
Lancio 1
Lancio 2
Lancio 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
È stata indicata la dimensione del blocco: 512 megabyte, che è chiaramente visibile nei grafici; Il carico del processore è rimasto effettivamente al 50%, il che significa che il programma non utilizza più di un core del processore.
Anche il principio di funzionamento del programma è abbastanza chiaro: hanno preso un dato, lo hanno compresso e lo hanno inviato a un server di archiviazione di backup, il che può essere piuttosto lento.
Un'altra caratteristica è il tempo di esecuzione prevedibile del programma, che dipende solo dalla dimensione dei dati modificati.
L'abilitazione della crittografia non ha aumentato in modo significativo il tempo di esecuzione del programma, ma ha aumentato il carico del processore di circa il 10%, il che può essere un bel vantaggio.
Sfortunatamente, questo programma non è stato in grado di rilevare correttamente la situazione con la ridenominazione della directory e la dimensione del repository risultante si è rivelata uguale alla dimensione delle modifiche (ovvero, tutti i 18 GB), ma la possibilità di utilizzare un server non attendibile per il backup è chiaramente copre questo comportamento.
Test duplicati
Questo software è scritto in C# e viene eseguito utilizzando un set di librerie di Mono. Esiste una GUI e una versione CLI.
L'elenco approssimativo delle funzionalità principali è simile a Duplicity e include vari fornitori di servizi di archiviazione di backup, tuttavia, a differenza di Duplicity, la maggior parte delle funzionalità sono disponibili senza strumenti di terze parti. Se questo sia un vantaggio o uno svantaggio dipende dal caso specifico, ma per i principianti è molto probabilmente più semplice avere un elenco di tutte le funzionalità davanti a sé in una volta, piuttosto che dover installare ulteriori pacchetti per Python, come è il caso della doppiezza.
Un'altra piccola sfumatura: il programma scrive attivamente un database sqlite locale per conto dell'utente che avvia il backup, quindi è necessario assicurarsi inoltre che il database richiesto sia specificato correttamente ogni volta che il processo viene avviato utilizzando la cli. Quando si lavora tramite GUI o WEBGUI, i dettagli verranno nascosti all'utente.
Vediamo quali indicatori può produrre questa soluzione:
Se disattivi la crittografia (e WEBGUI sconsiglia di farlo), i risultati sono i seguenti:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Con la crittografia abilitata, utilizzando aes, appare così:
Tempo di esecuzione:
Lancio 1
Lancio 2
Lancio 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
E se usi il programma esterno gnupg, escono i seguenti risultati:
Lancio 1
Lancio 2
Lancio 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Come puoi vedere, il programma può funzionare in più thread, ma ciò non lo rende una soluzione più produttiva e, se confronti il lavoro di crittografia, sta avviando un programma esterno
si è rivelato più veloce rispetto all'utilizzo della libreria del set Mono. Ciò potrebbe essere dovuto al fatto che il programma esterno è più ottimizzato.
Un'altra cosa bella è il fatto che la dimensione del repository occupa esattamente la stessa quantità dei dati effettivamente modificati, ad es. duplicati ha rilevato una ridenominazione della directory e ha gestito correttamente questa situazione. Questo può essere visto quando si esegue il secondo test.
Nel complesso, impressioni abbastanza positive del programma, incluso il fatto che sia abbastanza amichevole con i neofiti.
Giudizio
Entrambi i candidati hanno lavorato piuttosto lentamente, ma in generale, rispetto al normale tar, ci sono progressi, almeno con i duplicati. Anche il prezzo di tale progresso è chiaro: un onere notevole
processore. In generale, non ci sono deviazioni particolari nella previsione dei risultati.
risultati
Se non hai bisogno di correre da nessuna parte e hai anche un processore di riserva, qualsiasi soluzione considerata andrà bene, in ogni caso è stato svolto parecchio lavoro che non dovrebbe essere ripetuto scrivendo script wrapper sopra tar . La presenza della crittografia è una proprietà molto necessaria se non è possibile fidarsi completamente del server per l'archiviazione delle copie di backup.
Rispetto alle soluzioni basate - le prestazioni possono essere molte volte peggiori, nonostante il fatto che nella sua forma pura tar funzioni il 20-30% più velocemente di rsync.
Ci sono risparmi sulla dimensione del repository, ma solo con i duplicati.
annuncio
Backup Parte 3: Revisione e test di duplicità, duplicati, deja dup
Backup Parte 4: revisione e test di zbackup, restic, borgbackup
Backup Parte 5: Testare il backup di bacula e veeam per linux
Backup Parte 6: Confronto degli strumenti di backup
Backup Parte 7: Conclusioni
Pubblicato da: Pavel Demkovich
Fonte: habr.com