Questa nota di riepilogo prosegue , scritta su richiesta dei lettori, parlerà di UrBackup, BackupPC e AMANDA.
Panoramica di UrBackup.
Su richiesta dell'utente aggiungo una panoramica di UrBackup, un sistema client-server per il backup. Permette di creare backup completi e incrementali, supporta il funzionamento con snapshot dei dispositivi (solo Win?), e può anche creare backup di file. Il client può trovarsi nella stessa rete del server o connettersi tramite Internet. È dichiarato il tracciamento delle modifiche, che consente di trovare rapidamente le differenze tra i backup. C'è anche supporto per la deduplicazione dei dati sul lato server, risparmiando così spazio. Le connessioni di rete sono criptate, c'è anche un'interfaccia web per gestire il server. Vediamo a cosa è capace:
In modalità di creazione di un backup completo si sono ottenuti i seguenti risultati:
Tempo di esecuzione:
Primo avvio
Secondo avvio
Terzo avvio
Primo test
8m20s
8m19s
8m24s
Secondo test
8m30s
8m34s
8m20s
Terzo test
8m10s
8m14s
8m12s
In modalità di creazione di backup incrementali:
Tempo di esecuzione:
Primo avvio
Secondo avvio
Terzo avvio
Primo test
8m10s
8m10s
8m12s
Secondo test
3m50s
4m12s
3m34s
Terzo test
2m50s
2m35s
2m38s
La dimensione del repository in entrambi i casi è stata di circa 14 GB, il che indica che la deduplicazione funziona sul lato server. Va anche notato che c'è una discrepanza tra il tempo di creazione del backup sul server e quello sul client, cosa che è chiaramente visibile dai grafici ed è un bel bonus, poiché l'interfaccia web mostra il tempo di esecuzione del processo di backup sul lato server senza considerare
lo stato del client. In generale, i grafici per il backup completo e incrementale sono indistinguibili. Probabilmente, la differenza sta solo nel modo in cui viene elaborato sul lato server. Inoltre, ho apprezzato il basso utilizzo della CPU sul sistema soggetto al backup.
Panoramica di BackupPC
Su richiesta dell'utente Aggiungo una recensione di BackupPC. Questo software si installa su un server di archiviazione di backup, è scritto in perl e opera sopra vari strumenti di backup, principalmente rsync e tar. Come trasporto utilizza ssh e smb, e dispone anche di un'interfaccia web basata su cgi (si installa sopra apache). Nell'interfaccia web è presente un ampio elenco di impostazioni. Tra le caratteristiche c'è la possibilità di impostare un tempo minimo tra i backup, oltre a un periodo durante il quale i backup non verranno creati. Quando si sceglie il file system per il server di backup, è importante controllare il supporto per i link simbolici. Così, non si può suddividere il file system per lo storage in punti di montaggio. In generale, un'impressione piuttosto positiva, vediamo di cosa è capace questo software:
In modalità di creazione di backup completi con rsync si sono ottenuti i seguenti risultati:
Primo avvio
Secondo avvio
Terzo avvio
Primo test
12m25s
12m14s
12m27s
Secondo test
7m41s
7m44s
7m35s
Terzo test
10m11s
10m0s
9m54s
Se si utilizzano backup completi e tar:
Primo avvio
Secondo avvio
Terzo avvio
Primo test
12m41s
12m25s
12m45s
Secondo test
12m35s
12m45s
12m14s
Terzo test
12m43s
12m25s
12m5s
In modalità di creazione di backup incrementali, è stato necessario rinunciare a tar, poiché con tali impostazioni i backup non venivano creati.
I risultati della creazione di backup incrementali utilizzando rsync sono i seguenti:
Primo avvio
Secondo avvio
Terzo avvio
Primo test
11m55s
11m50s
12m25s
Secondo test
2m42s
2m50s
2m30s
Terzo test
6m00s
5m35s
5m30s
In generale, è evidente un lieve vantaggio in velocità per rsync, e inoltre rsync utilizza la rete in modo più efficiente. Questo può essere parzialmente controbilanciato da un minore utilizzo della cpu con tar come programma di backup. Un altro vantaggio di rsync è la gestione delle copie incrementali. La dimensione del repository durante la creazione di backup completi è identica, pari a 16 gb, mentre nel caso delle copie incrementali — 14 gb per singolo passaggio, il che significa una deduplicazione efficace.
Recensione di AMANDA
Su richiesta dell'utente Aggiungo i test di AMANDA,
I risultati del test eseguito con tar come archiviatore e attivando la compressione sono i seguenti:
Primo avvio
Secondo avvio
Terzo avvio
Primo test
9m5s
8m59s
9m6s
Secondo test
0m5s
0m5s
0m5s
Terzo test
2m40s
2m47s
2m45s
Il programma carica completamente un core della CPU, ma a causa del disco limitato in iops sul lato server del repository di backup non può sviluppare una grande velocità di trasferimento dati. In generale, la configurazione ha creato un po' più di problemi rispetto agli altri partecipanti, poiché l'autore del programma non utilizza ssh come mezzo di trasporto, ma implementa uno schema simile con le chiavi, creando e mantenendo una CA completa. C'è la possibilità di limitare ampiamente il client e il server di backup: ad esempio, se non possono fidarsi completamente l'uno dell'altro, si può, come opzione, vietare l'inizio del ripristino del backup dal lato del server, impostando il valore della variabile corrispondente a zero nel file di configurazione. È possibile collegare un'interfaccia web per la gestione, ma in generale il sistema configurato può essere completamente automatizzato con piccoli script Bash (o SCM, per esempio Ansible). Esiste un sistema di configurazione del repository non banale, apparentemente legato al supporto di un ampio elenco di dispositivi di archiviazione diversi (cartridge LTO, dischi rigidi, ecc.). Va anche notato che tra tutti i programmi analizzati in questo articolo, AMANDA è l'unico che è riuscito a riconoscere la rinominazione della directory. La dimensione del repository in un singolo ciclo è stata di 13 GB.
Annuncio
Backup, parte 6: Confronto degli strumenti di backup
Backup, parte 7: Conclusioni
Fonte: habr.com
