Questo articolo continua
il ciclo sul backup
- Backup, parte 2: Panoramica e testing di strumenti di backup basati su rsync
- Backup, parte 3: Panoramica e testing di duplicity, duplicaty, 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
Come abbiamo già scritto nel primo articolo, ci sono numerosi programmi di backup basati su rsync.
Tra quelli più adatti alle nostre esigenze, esaminerò 3: rdiff-backup, rsnapshot e burp.
Set di file di test
I set di file per il testing 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 fino a decine di megabyte per i file multimediali. L'obiettivo è simulare un sito statico.
Secondo set: derivato dal primo tramite la rinominazione di una sottocartella con file multimediali di dimensione 5 GB. L'obiettivo è studiare il comportamento del sistema di backup in seguito alla rinominazione della cartella.
Terzo set: si ottiene dalla prima operazione di rimozione di 3 GB di file multimediali e dall'aggiunta di nuovi 3 GB di file multimediali. L'obiettivo è studiare il comportamento del sistema di backup durante un'operazione tipica di aggiornamento del sito.
Ottieni risultati
Qualsiasi operazione di backup viene eseguita almeno 3 volte e accompagnata dal ripristino della cache del filesystem con i comandi sync e echo 3 > /proc/sys/vm/drop_caches sia dal lato del server di test che dal server di archiviazione dei backup.
Sul server che sarà la fonte dei backup è installato un software di monitoraggio — netdata, con il quale verrà valutato il carico sul server durante la copia, necessario per valutare il carico del server durante il processo di backup.
Ritengo inoltre che il server di archiviazione dei backup sia meno potente dal punto di vista della CPU rispetto al server principale, ma abbia dischi più capienti con una velocità di scrittura casuale relativamente bassa — situazione più frequente durante il backup; poiché il server di backup non dovrebbe in teoria svolgere altre attività oltre al backup, non monitorerò il suo carico tramite netdata.
Inoltre, i miei server sono cambiati, sui quali testerò 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)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 2
Inizializzazione del generatore di numeri casuali dall'ora attuale
Limite numeri primi: 20000
Inizializzazione dei thread di lavoro...
Thread avviati!
Velocità CPU:
eventi al secondo: 1081.62
Statistiche generali:
tempo totale: 30.0013s
numero totale di eventi: 32453
Latency (ms):
min: 1.48
avg: 1.85
max: 9.84
95° 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
Inizializzazione del generatore di numeri casuali dal tempo attuale
Eseguendo il test di velocità della memoria con le seguenti opzioni:
dimensione del blocco: 1KiB
dimensione totale: 102400MiB
operazione: lettura
ambito: globale
Inizializzazione dei thread worker...
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
95° 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 system LuaJIT 2.0.4)
Esecuzione del test con le seguenti opzioni:
Numero di thread: 4
Inizializzazione del generatore di numeri casuali dal tempo attuale
Esecuzione del test di velocità della memoria con le seguenti opzioni:
dimensione 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
95° percentile: 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 sorgente 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 di sistema)
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 di dimensione totale del file
Dimensione del blocco 4KiB
Numero di richieste IO: 0
Rapporto Lettura/Scrittura per il test combinato di IO casuale: 1.50
FSYNC periodico abilitato, chiamata a fsync() ogni 100 richieste.
Chiamata a fsync() alla fine del test, Abilitato.
Utilizzo della modalità I/O sincrona
Esecuzione del test di lettura/scrittura casuale
Inizializzazione dei thread di lavoro...
Thread avviati!
Operazioni sui file:
letture/s: 4587.95
scritture/s: 3058.66
fsyncs/s: 9795.73
Throughput:
lettura, MiB/s: 17.92
scritto, MiB/s: 11.95
Statistiche generali:
tempo totale: 60.0241s
numero totale di eventi: 1046492
Latencia (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 (usando LuaJIT 2.0.4 del sistema)
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, ciascuno di 8MiB
1GiB di dimensione totale del file
Dimensione del blocco 4KiB
Numero di richieste IO: 0
Rapporto lettura/scrittura per il test di IO casuale combinato: 1.50
FSYNC periodico attivato, chiamando fsync() ogni 100 richieste.
Chiamando fsync() alla fine del test, abilitato.
Utilizzando modalità I/O sincrona
Eseguendo test r/w casuale
Inizializzazione dei thread di lavoro...
Thread avviati!
Operazioni sui file:
letture/s: 11.37
scritture/s: 7.58
fsyncs/s: 29.99
Throughput:
lettura, MiB/s: 0.04
scritta, MiB/s: 0.03
Statistiche generali:
tempo totale: 73.8868s
numero totale di eventi: 3104
Latenza (ms):
min: 0.00
avg: 78.57
max: 3840.90
95° percentile: 297.92
somma: 243886.02
Equità dei thread:
eventi (avg/stddev): 776.0000/133.26
tempo di esecuzione (avg/stddev): 60.9715/1.59
Velocità della rete tra i server
iperf3 -c backup
Collegamento all'host backup, porta 5201
[ 4] locale x.x.x.x porta 59402 collegato 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 ricevitore
Metodologia di test
- Sul server di prova si sta preparando il file system con il primo set di test, sul server di storage di backup, se necessario, viene inizializzato il repository.
Il processo di backup viene avviato e il suo tempo viene misurato. - Sul server di prova avviene la migrazione dei file al secondo set di test. Viene avviato il processo di backup e il suo tempo viene misurato.
- Sul server di test è in corso la migrazione al terzo set di test. Viene avviato il processo di backup e ne viene misurato il tempo.
- Il terzo set di test ottenuto è accettato come primo nuovo; i punti 1-3 vengono ripetuti altre 2 volte.
- I dati vengono inseriti in una tabella riassuntiva, con grafici aggiunti da netdata.
- Viene redatto un rapporto su un metodo di backup specifico.
Risultati attesi
Poiché tutti e 3 i candidati si basano sulla stessa tecnologia (rsync), ci si aspetta che i risultati siano vicini a quelli dell'rsync normale, incluse tutte le sue vantaggi, vale a dire:
- I file nel repository saranno conservati "così come sono".
- La dimensione del repository crescerà solo includendo la differenza tra i backup.
- Ci sarà un carico relativamente alto sulla rete durante il trasferimento dei dati, così come un carico minimo sulla CPU.
Una prova di test dell'rsync normale sarà utilizzata come riferimento, i suoi risultati
sono i seguenti
Il collo di bottiglia si trovava sul server di archiviazione dei backup, sotto forma di un disco basato su HDD, come si vede chiaramente nei grafici a forma di sega.
I dati sono stati copiati in 4 minuti e 15 secondi.
Testing rdiff-backup
Il primo candidato è rdiff-backup, uno script Python che esegue il backup di una directory in un'altra. La copia di backup attuale viene mantenuta "così com'è", mentre i backup effettuati in precedenza vengono accumulati in una sottodirectory in modo incrementale, risparmiando così spazio.
Verificheremo la modalità operativa tipica, cioè l'avvio del processo di backup è iniziato dal cliente, mentre sul server viene avviato un processo che riceve i dati per il backup.
Diamo un'occhiata a cosa può fare nelle nostre condizioni.
Tempo di esecuzione di ciascun avvio di prova:
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 piuttosto problematico a qualsiasi grande cambiamento di dati e non sfrutta completamente la rete.
Testing rsnapshot
Il secondo candidato è rsnapshot, uno script in Perl, il cui requisito principale per un funzionamento efficace è il supporto dei link rigidi. In questo modo si risparmia spazio su disco. I file che non sono cambiati dalla precedente copia di backup faranno riferimento al file originale tramite link rigidi.
È stata anche invertita la logica del processo di backup: il server «cammina» attivamente tra i suoi clienti e raccoglie i dati.
Risultati dei test
sono ottenuti i seguenti
Primo avvio
Secondo avvio
Terzo avvio
Primo set
4m22s
4m19s
4m16s
Secondo set
2m6s
2m10s
2m6s
Terzo set
1m18s
1m10s
1m10s
Ha lavorato in modo molto rapido, molto più veloce di rdiff-backup e molto vicino a rsync puro.
Test 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 diritti 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 due volte più lentamente di rsnapshot, ma comunque abbastanza rapidamente, e sicuramente più veloce di rdiff-backup. I grafici mostrano un'andatura un po' seghettata — le prestazioni sono di nuovo limitate dal sistema di archiviazione dei backup, anche se non così marcato come con rsnapshot.
Risultati
La dimensione dei repository per tutti i candidati era più o meno la stessa, cioè inizialmente cresceva fino a 10 GB, poi fino a 15 GB, poi fino a 18 GB, e così via, il che è legato alle peculiarità del funzionamento di rsync. È importante notare anche la monocoreabilità di tutti i candidati (carico della CPU intorno al 50% su una macchina dual-core). Tutti e tre i candidati offrivano la possibilità di ripristinare l'ultima copia di sicurezza "così com'è", cioè era possibile ripristinare i file senza l'uso di alcun programma di terze parti, inclusi quelli utilizzati per creare i repository. Questo è anche un "legato ereditario" di rsync.
Conclusioni
Più complesso è il sistema di backup e più possibilità diverse ha, più lentamente funzionerà, ma per progetti non troppo esigenti, qualsiasi di essi andrà bene, tranne, forse, rdiff-backup.
Annuncio
Questo appunto continua il ciclo sui backup
Backup, parte 2: Panoramica e test degli strumenti di backup basati su rsync
Backup, parte 3: Panoramica e testing di duplicity, duplicaty, 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
