În acest articol vor fi discutate instrumentele software pentru backup, care prin fragmentarea fluxului de date în componente separate (chunks), formează un repository.
Componentele repository-ului pot fi, de asemenea, comprimate și criptate, iar cel mai important — în cadrul proceselor repetate de backup — pot fi reutilizate.
Un backup în acest tip de repository este un lanț denumit de componente interconectate, de exemplu, bazat pe diferite funcții hash.
Există câteva soluții similare, mă voi opri la 3: zbackup, borgbackup și restic.
Rezultatele așteptate
Deoarece toți candidații cer în mod necesar crearea unui repository, unul dintre cei mai importanți factori va fi estimarea dimensiunii repository-ului. Într-un scenariu ideal, dimensiunea acestuia nu ar trebui să depășească 13 GB conform metodologiei standardizate, sau chiar mai puțin — cu condiția unei bune optimizări.
De asemenea, ar fi foarte de dorit să există posibilitatea de a crea backup-uri ale fișierelor direct, fără a folosi arhivatoare precum tar, precum și suport pentru ssh/sftp fără instrumente adiționale precum rsync și sshfs.
Comportamentul la crearea backup-urilor:
- Dimensiunea repository-ului va fi egală cu dimensiunea modificărilor sau mai mică.
- Se așteaptă o încărcare mare a procesorului atunci când se utilizează comprimarea și/sau criptarea, iar, de asemenea, este probabilă o încărcare semnificativă asupra rețelei și subsistemului de disc, dacă procesul de arhivare și/sau criptare se va desfășura pe serverul de stocare a backup-urilor.
- Dacă repository-ul este deteriorat — este probabilă o eroare temporală atât în timpul creării de noi backup-uri, cât și în timpul tentativei de recuperare. Este necesar să planificăm măsuri suplimentare pentru asigurarea integrității repository-ului sau să folosim instrumentele integrate de verificare a integrității acestuia.
Ca valoare de referință, s-a acceptat lucrul cu tar, așa cum a fost demonstrat într-unul din articolele anterioare.
Testarea zbackup
Mecanismul general de funcționare al zbackup constă în faptul că programul identifică în fluxul de date furnizat la intrare zonele care conțin date identice, apoi le comprimă opțional, le criptează, păstrând fiecare zonă o singură dată.
Pentru deduplicare se folosește o funcție hash rotundă de 64 de biți cu fereastră mobilă pentru verificarea pe byte a corespondențelor cu blocurile de date deja existente (asemănător cu ce este implementat în rsync).
Pentru compresie se utilizează lzma și lzo în execuție multi-threaded, iar pentru criptare — aes. În versiunile recente există posibilitatea de a șterge date vechi din repository în viitor.
Programul este scris în C++ cu dependențe minime. Autorul s-a inspirat evident din stilul unix-way, deoarece programul acceptă date pe stdin la crearea de backup-uri, generând un flux de date similar în stdout la restaurare. Astfel, zbackup poate fi utilizat ca un foarte bun „brick” pentru scrierea propriilor soluții de backup. De exemplu, autorul articolului folosește acest program ca principal instrument de backup pentru computerele personale din 2014.
Fluxul de date va fi tar-ul obișnuit, dacă nu se specifică altfel.
Să vedem ce rezultate vor fi:
Testarea a fost efectuată în 2 variante:
- se creează un repository și se lansează zbackup pe serverul cu datele originale, apoi conținutul repository-ului este transferat pe serverul de stocare a backup-urilor.
- se creează un repository pe serverul de stocare a backup-urilor, zbackup este lansat prin ssh pe serverul de stocare a backup-urilor, și i se furnizează datele prin pipe.
Rezultatele primei variante au fost următoarele: 43m11s — folosind repository necriptat și compresor lzma, 19m13s — când compresorul a fost înlocuit cu lzo.
Încărcarea pe serverul cu datele originale a fost următoarea (exemplul cu lzma este prezentat, cu lzo a fost o imagine similară, dar partea de rsync a fost de aproximativ un sfert din timp):
Este clar că un astfel de proces de backup este util doar în cazul unor schimbări relativ rare și mici. De asemenea, este extrem de recomandat să se limiteze funcționarea zbackup la un singur fir de execuție, altfel va exista o încărcare destul de mare pe procesor, deoarece programul știe să funcționeze eficient în mai multe fire. Încărcarea pe disc a fost mică, ceea ce în general, având în vedere sistemele moderne de disc bazate pe SSD, va fi imperceptibil. De asemenea, este clar vizibil începutul procesului de sincronizare a datelor din depozitul de date pe serverul remote, viteza de lucru este comparabilă cu cea a rsync-ului obișnuit și este limitată de performanța sistemului de disc al serverului de stocare a backup-urilor. Un dezavantaj al acestei metode este stocarea depozitului local și, prin urmare, duplicarea datelor.
O variantă mai interesantă și aplicabilă în practică este a doua opțiune de a rula zbackup direct pe serverul de stocare a backup-urilor.
În primul rând, va fi verificată funcționarea fără utilizarea criptării cu compresorul lzma:
Timpul de execuție pentru fiecare test:
Execuție 1
Execuție 2
Execuție 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Dacă activați criptarea folosind aes, rezultatele sunt destul de apropiate:
Timpul de lucru cu aceleași date, cu criptare:
Execuție 1
Execuție 2
Execuție 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Dacă criptarea este combinată cu compresia pe lzo, rezultatele sunt următoarele:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Dimensiunea depozitului rezultat a fost relativ constantă și a fost de 13gb. Aceasta înseamnă că deduplicarea funcționează corect. De asemenea, aplicarea lzo pe date deja comprimate oferă un efect semnificativ, iar timpul total de execuție al zbackup se apropie de cel al duplicity/duplicati, deși este mai lent cu 2-5 ori comparativ cu cele bazate pe librsync.
Avantajele sunt evidente — economisirea spațiului pe disc pe serverul de stocare a backup-urilor. Cât despre instrumentele de verificare a depozitului — acestea nu sunt prevăzute de creatorul zbackup, se recomandă utilizarea unui sistem RAID sau a unui furnizor de cloud.
În general, impresia este destul de plăcută, în ciuda faptului că proiectul este static de aproximativ 3 ani (ultima cerere de funcționalitate a fost acum aproximativ un an, dar fără răspuns).
Testarea borgbackup
Borgbackup este un fork al attic, un alt sistem similar cu zbackup. Este scris în python, are o listă similară de funcționalități cu zbackup, dar are și capacitatea suplimentară de:
- Montarea backup-urilor prin fuse
- Verificarea conținutului repository-ului
- Lucrul în modul client-server
- Folosirea diferitelor compresoare pentru date, precum și determinarea euristică a tipului de fișier în timpul comprimării acestuia.
- 2 opțiuni de criptare, aes și blake
- Un instrument încorporat pentru
verificarea performanței
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Rezultatele au fost următoarele:
C-Z-BIG 96.51 MB/s (10 100.00 MB fișiere all-zero: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB fișiere all-zero: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB fișiere all-zero: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB fișiere all-zero: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB fișiere random: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB fișiere random: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB fișiere random: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB fișiere random: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB fișiere all-zero: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB fișiere all-zero: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB fișiere all-zero: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB fișiere all-zero: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB fișiere random: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB fișiere random: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB fișiere random: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB fișiere random: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB fișiere all-zero: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB fișiere all-zero: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB fișiere all-zero: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB fișiere all-zero: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB fișiere random: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB fișiere random: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB fișiere random: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB fișiere random: 5.32s)
În timpul testării se va folosi euristica pentru comprimare cu determinarea tipului de fișier (compression auto), iar rezultatele vor fi următoarele:
Pentru început, să verificăm funcționarea fără criptare:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Dacă activăm autorizarea repository-ului (modul authenticated), rezultatele vor fi apropiate:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Când activăm criptarea aes, rezultatele nu s-au degradat semnificativ:
Execuție 1
Execuție 2
Execuție 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Și dacă schimbăm aes cu blake, situația se va îmbunătăți:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Ca și în cazul zbackup, dimensiunea repository-ului a fost de 13GB și chiar puțin mai mică, ceea ce este, în general, așteptat. Timpul de execuție a fost într-adevăr impresionant, fiind comparabil cu soluțiile bazate pe librsync, oferind mult mai multe opțiuni. De asemenea, a fost apreciată posibilitatea de a seta diferite parametri prin variabile de mediu, ceea ce conferă un avantaj semnificativ în utilizarea borgbackup în mod automat. Am fost, de asemenea, impresionat de încărcătura generată în timpul backup-ului: conform utilizării procesorului, borgbackup funcționează pe 1 fir.
Nu au fost observate minusuri semnificative în utilizare.
Testarea restic
Deși restic este o soluție destul de nouă (primii doi candidați erau cunoscuți încă din 2013 și mai devreme), el are caracteristici destul de bune. Este scris în Go.
Dacă compari cu zbackup, oferă suplimentar:
- Verificarea integrității depozitului (inclusiv verificarea pe părți).
- O listă uriașă de protocoale și furnizori acceptați pentru stocarea de backup-uri, precum și suport pentru rclone — rsync pentru soluții 'cloud'.
- Compararea a două backup-uri între ele.
- Montarea depozitului prin fuse.
În general, lista de funcționalități este destul de apropiată de borgbackup, în unele locuri mai mult, în altele mai puțin. Dintre caracteristici, lipsa posibilității de a dezactiva criptarea, astfel încât backup-urile vor fi întotdeauna criptate. Să vedem practic ce se poate obține din acest software:
Rezultatele obținute sunt următoarele:
Timpul de lucru:
Execuție 1
Execuție 2
Execuție 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Rezultatele obținută sunt de asemenea comparabile cu soluțiile bazate pe rsync și, în general, sunt foarte apropiate de borgbackup, dar sarcina pe procesor este mai mare (funcționează mai multe fire) și este în zigzag.
Este foarte probabil ca programul să se limiteze la performanța subsistemului de stocare pe serverul de date, așa cum s-a întâmplat deja cu rsync. Dimensiunea depozitului a fost de 13 GB, la fel ca și în cazul zbackup sau borgbackup, nu s-au descoperit defecte evidente la utilizarea acestei soluții.
Rezultate
De fapt, toți candidații au avut rezultate apropiate, totuși cu prețuri diferite. Cel mai bine s-a comportat borgbackup, puțin mai lent a fost restic, iar zbackup probabil nu merită să fie folosit,
iar dacă este deja utilizat, ar trebui să încerci să schimbi la borgbackup sau restic.
Conclusions
Cea mai promițătoare soluție pare a fi restic, deoarece acesta are cel mai bun raport între capacități și viteză, dar să nu ne grăbim cu concluziile generale.
Borgbackup în principiu nu este mai rău, iar zbackup probabil ar trebui înlocuit. Totuși, pentru a asigura aplicarea regulii 3-2-1, zbackup poate fi folosit în continuare. De exemplu, ca un complement la instrumentele de backup bazate pe (lib)rsync.
Anunț
Backup, partea 5: Testarea bacula și veeam backup pentru linux.
Backup, partea 6: Comparația uneltelor de backup
Backup, partea 7: Concluzii
Autorul publicației: Pavel Demkovich
Sursa: habr.com
