Con questo articolo continuiamo
il ciclo sul backup
- Backup, parte 2: Panoramica e test di strumenti di backup basati su rsync
- Backup, parte 3: Panoramica e test di duplicity, duplicaty, 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
Come abbiamo già scritto nel primo articolo, ci sono un numero piuttosto elevato di programmi di backup basati su rsync.
Di quelli che si adattano meglio alle nostre esigenze, esaminerò 3: rdiff-backup, rsnapshot e burp.
Set di file di prova
I set di file per il test saranno identici per tutti i candidati, comprese le future articoli.
Primo set: 10 GB di file multimediali e circa 50 MB di codice sorgente del sito in PHP, con dimensioni dei file che vanno da pochi kilobyte per il codice sorgente a decine di megabyte per i file multimediali. L'obiettivo è simulare un sito statico.
Secondo set: deriva dal primo rinominando la sottocartella con file multimediali di 5 GB. L'obiettivo è studiare il comportamento del sistema di backup alla rinomina della directory.
Terzo set: deriva dal primo rimuovendo 3 GB di file multimediali e aggiungendo 3 GB di nuovi file multimediali. L'obiettivo è studiare il comportamento del sistema di backup durante un'operazione tipica di aggiornamento del sito.
Ottenere risultati
Qualsiasi backup viene eseguito almeno 3 volte e accompagnato dal flush della cache del file system tramite i comandi sync e echo 3 > /proc/sys/vm/drop_caches sia dal lato del server di test che dal server di archiviazione del backup.
Sul server, che sarà fonte dei backup, è installato il software di monitoraggio — netdata, attraverso il quale verrà valutato il carico sul server durante il backup, necessario per valutare il carico del processo di backup.
Credo anche che il server di archiviazione dei backup sia più lento a livello di CPU rispetto al server principale, ma abbia dischi più capienti con una velocità di scrittura casuale relativamente bassa — una situazione comune durante il backup, e poiché il server di backup non dovrebbe eseguire altre attività oltre al backup, non monitorerò il suo carico con netdata.
Ho anche cambiato i server su cui verificherò diversi sistemi di backup.
Attualmente hanno le seguenti caratteristicheProcessore
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (utilizzando system LuaJIT 2.0.4)
Eseguendo il test con le seguenti opzioni:
Numero di thread: 2
Inizializzando il generatore di numeri casuali dal tempo attuale
Limite dei numeri primi: 20000
Inizializzando i thread di lavoro...
Thread avviati!
Velocità CPU:
eventi al secondo: 1081.62
Statistiche generali:
tempo totale: 30.0013s
numero totale di eventi: 32453
Latenza (ms):
min: 1.48
avg: 1.85
max: 9.84
95esimo percentile: 2.07
somma: 59973.40
Equità dei thread:
eventi (avg/stddev): 16226.5000/57.50
tempo di esecuzione (avg/stddev): 29.9867/0.00
Memoria RAM, lettura…
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (utilizzando system LuaJIT 2.0.4)
Eseguendo il test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dal tempo attuale
Eseguendo il test di velocità della memoria con le seguenti opzioni:
dimensione blocco: 1KiB
dimensione totale: 102400MiB
operazione: lettura
campo: globale
Inizializzando i thread di lavoro...
Thread avviati!
Operazioni totali: 104857600 (5837637.63 al secondo)
102400.00 MiB trasferiti (5700.82 MiB/sec)
Statistiche generali:
tempo totale: 17.9540s
numero totale di eventi: 104857600
Latenza (ms):
min: 0.00
avg: 0.00
max: 66.08
95esimo percentile: 0.00
somma: 18544.64
Equità dei thread:
eventi (avg/stddev): 26214400.0000/0.00
tempo di esecuzione (avg/stddev): 4.6362/0.12
… e scrittura
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (utilizzando LuaJIT 2.0.4 del sistema)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dall'orario attuale
Esecuzione del test di velocità della memoria con le seguenti opzioni:
dimensione del blocco: 1KiB
dimensione totale: 102400MiB
operazione: scrittura
ambito: globale
Inizializzazione dei thread di lavoro...
Thread avviati!
Operazioni totali: 91414596 (3046752.56 al secondo)
89272.07 MiB trasferiti (2975.34 MiB/sec)
Statistiche generali:
tempo totale: 30.0019s
numero totale di eventi: 91414596
Latenza (ms):
min: 0.00
avg: 0.00
max: 1022.90
percentile 95: 0.00
somma: 66430.91
Equità dei thread:
eventi (avg/stddev): 22853649.0000/945488.53
tempo di esecuzione (avg/stddev): 16.6077/1.76
Disco sul server di origine dati
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (utilizzando LuaJIT 2.0.4 del sistema)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzando il generatore di numeri casuali dall'orario attuale
Flag di apertura file extra: (nessuno)
128 file, 8MiB ciascuno
1GiB dimensione totale del file
Dimensione del blocco 4KiB
Numero di richieste di I/O: 0
Rapporto di lettura/scrittura per il test di I/O casuale combinato: 1.50
FSYNC periodico abilitato, chiamando fsync() ogni 100 richieste.
Chiamando fsync() alla fine del test, abilitato.
Utilizzando la modalità I/O sincrona
Esecuzione del test di r/w casuale
Inizializzazione dei thread di lavoro...
Thread avviati!
Operazioni su file:
letture/s: 4587.95
scritture/s: 3058.66
fsyncs/s: 9795.73
Throughput:
lettura, MiB/s: 17.92
scritti, MiB/s: 11.95
Statistiche generali:
tempo totale: 60.0241s
numero totale di eventi: 1046492
Latenza (ms):
min: 0.00
avg: 0.23
max: 14.45
percentile 95: 0.94
somma: 238629.34
Equità dei thread:
eventi (avg/stddev): 261623.0000/1849.14
tempo di esecuzione (avg/stddev): 59.6573/0.00
Disco sul server di archiviazione dei backup
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (utilizzando system LuaJIT 2.0.4)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dall'ora attuale
Flag di apertura file extra: (nessuno)
128 file, 8MiB ciascuno
1GiB dimensione totale del file
Dimensione del blocco 4KiB
Numero di richieste IO: 0
Rapporto Read/Write per il test IO casuale combinato: 1.50
FSYNC periodico abilitato, chiamando fsync() ogni 100 richieste.
Chiamata a fsync() alla fine del test, abilitata.
Utilizzando la modalità I/O sincrona
Eseguendo il test casuale r/w
Inizializzazione dei thread di lavoro...
Thread avviati!
Operazioni sui file:
letture/s: 11.37
scritture/s: 7.58
fsyncs/s: 29.99
Prestazioni:
lettura, MiB/s: 0.04
scritto, MiB/s: 0.03
Statistiche generali:
tempo totale: 73.8868s
numero totale di eventi: 3104
Latenza (ms):
minima: 0.00
media: 78.57
massima: 3840.90
percentile 95: 297.92
somma: 243886.02
Equità dei thread:
eventi (media/deviazione standard): 776.0000/133.26
tempo di esecuzione (media/deviazione standard): 60.9715/1.59
Velocità della rete tra i server
iperf3 -c backup
Connessione all'host backup, porta 5201
[ 4] locale x.x.x.x porta 59402 connesso a y.y.y.y porta 5201
[ ID] Intervallo Trasferimento Larghezza di banda Retr Cwnd
[ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervallo Trasferimento Larghezza di banda Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 mittente
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec ricevente
Metodo di test
- Sul server di test viene preparato il file system con il primo set di test, sul server di backup il repository viene inizializzato se necessario.
Si avvia il processo di backup e si misura il suo tempo. - Sul server di test viene eseguita la migrazione dei file al secondo set di test. Si avvia il processo di backup e si misura il suo tempo.
- Sul server di test viene eseguita la migrazione al terzo set di test. Si avvia il processo di backup e si misura il suo tempo.
- Il terzo set di test ottenuto viene considerato come nuovo primo; i punti 1-3 vengono ripetuti altre 2 volte.
- I dati vengono inseriti nella tabella di sintesi, vengono aggiunti grafici con netdata.
- Si elabora un rapporto sul singolo metodo di backup.
Risultati attesi
Poiché tutti e 3 i candidati si basano sulla stessa tecnologia (rsync), ci si aspetta che i risultati siano vicini a quelli del normale rsync, comprese tutte le sue vantaggi, ovvero:
- I file nel repository verranno memorizzati 'così come sono'.
- La dimensione del repository crescerà solo includendo la differenza tra i backup.
- Ci sarà un carico relativamente elevato sulla rete durante il trasferimento dei dati, e un carico ridotto sulla CPU.
Il test di un normale rsync sarà utilizzato come punto di riferimento, i suoi risultati
sono i seguenti
Il collo di bottiglia si trovava sul server di archiviazione dei backup sotto forma di disco basato su HDD, che è chiaramente visibile nei grafici a forma di sega.
I dati sono stati copiati in 4 minuti e 15 secondi.
Testing di rdiff-backup
Il primo candidato è rdiff-backup, uno script in python che esegue il backup di una cartella in un'altra. In questo modo, il backup corrente è conservato 'così com'è', mentre i backup effettuati in precedenza vengono memorizzati in una sottocartella speciale in modo incrementale, risparmiando spazio.
Controlliamo la modalità operativa tipica, cioè l'avvio del processo di backup è iniziato autonomamente dal cliente, mentre sul server viene avviato un processo che riceve i dati.
Vediamo di cosa è capace nelle nostre condizioni.
Tempo di esecuzione di ciascun avvio di test:
Primo avvio
Secondo avvio
Terzo avvio
Primo set
16m32s
16m26s
16m19s
Secondo set
2h5m
2h10m
2h8m
Terzo set
2h9m
2h10m
2h10m
Rdiff-backup reagisce in modo molto sensibile a qualsiasi grande cambiamento nei dati, e non ottimizza completamente la rete.
Testing di rsnapshot
Il secondo candidato è rsnapshot, uno script in perl il cui principale requisito per un funzionamento efficace è il supporto per i link rigidi. In questo modo si risparmia spazio su disco. I file che non sono cambiati dalla precedente copia di sicurezza rimanderanno al file originale tramite link rigidi.
Inoltre, è stata invertita la logica del processo di backup: il server 'va attivamente' dai suoi clienti e raccoglie i dati.
Risultati dei test
sono stati i seguenti
Primo avvio
Secondo avvio
Terzo avvio
Primo set
4m22s
4m19s
4m16s
Secondo set
2m6s
2m10s
2m6s
Terzo set
1m18s
1m10s
1m10s
Ha funzionato molto velocemente, molto più veloce di rdiff-backup e molto vicino a rsync puro.
Testing di burp
Un'altra opzione è l'implementazione in C sopra librsync – burp, che ha un'architettura client-server inclusa l'autenticazione dei clienti, oltre a un'interfaccia web (non inclusa nella fornitura di base). Un'altra caratteristica interessante è il backup senza diritto di ripristino per i clienti.
Diamo un'occhiata aprestazioni.
Primo avvio
Secondo avvio
Terzo avvio
Primo set
11m21s
11m10s
10m56s
Secondo set
5m37s
5m40s
5m35s
Terzo set
3m33s
3m24s
3m40s
Ha lavorato 2 volte più lentamente di rsnapshot, tuttavia è comunque abbastanza veloce, sicuramente più veloce di rdiff-backup. I grafici presentano una leggera ondulazione – le prestazioni si scontrano ancora con il sottosistema di archiviazione dei backup, anche se questo non è così pronunciato come con rsnapshot.
Risultati
La dimensione dei repository per tutti i candidati era abbastanza simile, cioè inizialmente crescevano fino a 10 GB, poi fino a 15 GB, poi fino a 18 GB e così via, il che è legato alla particolare modalità operativa di rsync. È anche importante notare che tutti i candidati utilizzano un solo thread (carico CPU di circa il 50% su una macchina dual-core). Tutti e tre i candidati offrivano la possibilità di ripristinare l'ultimo backup "così com'è", il che significa che era possibile ripristinare file senza utilizzare alcun programma di terze parti, inclusi quelli utilizzati per creare i repository. Questo è anche un'eredità di rsync.
Conclusioni
Più complesso è il sistema di backup e più opzioni ha, più lentamente funzionerà, ma per progetti non particolarmente esigenti basterà uno qualsiasi di essi, forse eccetto rdiff-backup.
Annuncio
Questa nota prosegue il ciclo sui backup
Backup, parte 2: Panoramica e test di strumenti di backup basati su rsync
Backup, parte 3: Panoramica e test di duplicity, duplicaty, 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
