Acest articol va compara instrumentele de backup, dar mai întâi ar trebui să aflați cât de repede și de bine fac față restabilirii datelor din backup.
Pentru ușurință în comparație, vom lua în considerare restaurarea dintr-o copie de rezervă completă, mai ales că toți candidații acceptă acest mod de operare. Pentru simplitate, numerele sunt deja mediate (media aritmetică a mai multor rulări). Rezultatele vor fi rezumate într-un tabel, care va conține, de asemenea, informații despre capabilități: prezența unei interfețe web, ușurința de configurare și operare, capacitatea de automatizare, prezența diferitelor caracteristici suplimentare (de exemplu, verificarea integrității datelor) , etc. Graficele vor arăta încărcarea serverului unde vor fi utilizate datele (nu serverul pentru stocarea copiilor de rezervă).
Recuperare date
rsync și tar vor fi folosite ca punct de referință din moment ce scripturi simple pentru a face copii de rezervă.
Rsync a făcut față setului de date de testare în 4 minute și 28 de secunde, arătând
o astfel de încărcătură
Procesul de recuperare a lovit o limitare a subsistemului de disc al serverului de stocare de rezervă (grafice cu dinți de ferăstrău). De asemenea, puteți vedea clar încărcarea unui nucleu fără probleme (iowait și softirq scăzut - fără probleme cu discul și respectiv rețea). Deoarece celelalte două programe, și anume rdiff-backup și rsnapshot, se bazează pe rsync și oferă, de asemenea, rsync obișnuit ca instrument de recuperare, acestea vor avea aproximativ același profil de încărcare și timp de recuperare de rezervă.
Gudron am făcut-o puțin mai repede
2 minute și 43 de secunde:
Sarcina totală a sistemului a fost mai mare în medie cu 20% datorită creșterii softirq - costurile generale în timpul funcționării subsistemului de rețea au crescut.
Dacă arhiva este comprimată în continuare, timpul de recuperare crește la 3 minute și 19 secunde.
cu o astfel de încărcare pe serverul principal (despachetarea pe partea laterală a serverului principal):
Procesul de decompresie ocupă ambele nuclee de procesor deoarece există două procese care rulează. În general, acesta este rezultatul așteptat. De asemenea, un rezultat comparabil (3 minute și 20 de secunde) a fost obținut la rularea gzip pe partea de server cu copii de siguranță; profilul de încărcare pe serverul principal a fost foarte asemănător cu rularea tar fără compresorul gzip (vezi graficul anterior).
В rdiff-backup puteți sincroniza ultima copie de rezervă pe care ați făcut-o folosind rsync obișnuit (rezultatele vor fi similare), dar copiile de rezervă mai vechi trebuie încă restaurate folosind programul rdiff-backup, care a finalizat restaurarea în 17 minute și 17 secunde, arătând
aceasta sarcina:
Poate că acest lucru era menit, cel puțin pentru a limita viteza autorilor . Procesul de restaurare a unei copii de rezervă în sine necesită puțin mai puțin de jumătate dintr-un nucleu, cu performanțe proporțional comparabile (adică de 2-5 ori mai lentă) pe disc și rețea cu rsync.
Rsnapshot Pentru recuperare, sugerează utilizarea rsync-ului obișnuit, astfel încât rezultatele sale vor fi similare. În general, așa a ieșit.
burp Am finalizat sarcina de a restabili o copie de rezervă în 7 minute și 2 secunde cu
cu aceasta sarcina:
A funcționat destul de repede și cel puțin este mult mai convenabil decât rsync pur: nu trebuie să vă amintiți niciun semnal, o interfață cli simplă și intuitivă, suport încorporat pentru mai multe copii - deși este de două ori mai lent. Dacă trebuie să restaurați datele din ultima copie de rezervă pe care ați făcut-o, puteți utiliza rsync, cu câteva avertismente.
Programul a arătat aproximativ aceeași viteză și încărcare BackupPC la activarea modului de transfer rsync, implementarea copiei de rezervă pentru
7 minute și 42 de secunde:
Dar în modul de transfer de date, BackupPC a făcut față cu gudronul mai lent: în 12 minute și 15 secunde, sarcina procesorului a fost în general mai mică
o dată și jumătate:
Duplicitate fără criptare a arătat rezultate puțin mai bune, restabilind o copie de rezervă în 10 minute și 58 de secunde. Dacă activați criptarea utilizând gpg, timpul de recuperare crește la 15 minute și 3 secunde. De asemenea, atunci când creați un depozit pentru stocarea copiilor, puteți specifica dimensiunea arhivei care va fi utilizată la împărțirea fluxului de date primit. În general, pe hard disk-urile convenționale, și datorită modului de operare cu un singur fir, nu există prea multă diferență. Poate apărea la diferite dimensiuni de bloc atunci când se utilizează stocarea hibridă. Încărcarea pe serverul principal în timpul recuperării a fost după cum urmează:
fara criptare
cu criptare
Duplicati a arătat o rată de recuperare comparabilă, finalizând-o în 13 minute și 45 de secunde. A durat încă aproximativ 5 minute pentru a verifica corectitudinea datelor recuperate (în total aproximativ 19 minute). Sarcina a fost
destul de inalt:
Când criptarea aes a fost activată intern, timpul de recuperare a fost de 21 de minute și 40 de secunde, cu utilizarea CPU la maxim (ambele nuclee!) în timpul recuperării; La verificarea datelor, a fost activ un singur fir, ocupând un nucleu de procesor. Verificarea datelor după recuperare a durat aceleași 5 minute (aproape 27 de minute în total).
Rezultat
duplicati a fost puțin mai rapid cu recuperarea când se folosește programul extern gpg pentru criptare, dar în general diferențele față de modul anterior sunt minime. Timpul de funcționare a fost de 16 minute 30 de secunde, cu verificarea datelor în 6 minute. Sarcina a fost
este după cum urmează:
AMANDA, folosind gudron, l-a completat în 2 minute și 49 de secunde, ceea ce, în principiu, este foarte aproape de gudronul obișnuit. Încărcare pe sistem în principiu
aceeași:
Când restaurați o copie de rezervă folosind zbackup s-au obtinut urmatoarele rezultate:
criptare, compresie lzma
Timp de rulare 11 minute și 8 secunde
Criptare AES, compresie lzma
Timp de lucru 14 minute
Criptare AES, compresie lzo
Timp de rulare 6 minute, 19 secunde
Per total, nu e rau. Totul depinde de viteza procesorului de pe serverul de rezervă, care poate fi văzută clar din timpul de rulare a programului cu diferite compresoare. Pe partea de server de rezervă, a fost lansat un tar obișnuit, așa că dacă îl comparați cu acesta, recuperarea este de 3 ori mai lentă. Poate merită să verificați funcționarea în modul cu mai multe fire, cu mai mult de două fire.
Borg Backup în modul necriptat a fost puțin mai lent decât tar, în 2 minute și 45 de secunde, cu toate acestea, spre deosebire de tar, a devenit posibilă deduplicarea depozitului. Sarcina s-a dovedit a fi
Următorul:
Dacă activați criptarea bazată pe blake, viteza de recuperare a backupului este puțin mai mică. Timpul de recuperare în acest mod este de 3 minute și 19 secunde, iar sarcina a dispărut
asa:
Criptarea AES este puțin mai lentă, timpul de recuperare este de 3 minute și 23 de secunde, încărcarea este în special
nu s-a schimbat:
Deoarece Borg poate funcționa în modul multi-threaded, sarcina procesorului este maximă, iar atunci când sunt activate funcții suplimentare, timpul de funcționare pur și simplu crește. Aparent, merită să explorați multithreading-ul într-un mod similar cu zbackup.
Restic a făcut față recuperării puțin mai încet, timpul de operare a fost de 4 minute și 28 de secunde. Sarcina arăta ca
după cum urmează:
Aparent, procesul de recuperare funcționează în mai multe fire, dar eficiența nu este la fel de mare ca cea a BorgBackup, dar comparabilă în timp cu rsync-ul obișnuit.
Cu urBackup A fost posibil să se restabilească datele în 8 minute și 19 secunde, încărcarea a fost
este după cum urmează:
Sarcina încă nu este foarte mare, chiar mai mică decât cea a gudronului. În unele locuri există explozii, dar nu mai mult decât sarcina unui nucleu.
Selectarea și justificarea criteriilor de comparare
După cum sa menționat într-unul dintre articolele anterioare, sistemul de rezervă trebuie să îndeplinească următoarele criterii:
- Ușurință în utilizare
- versatilitatea
- stabilitate
- Rapiditate
Merită să luați în considerare fiecare punct separat, mai detaliat.
Ușurință de operare
Cel mai bine este când există un singur buton „Fă totul bine”, dar dacă revii la programe reale, cel mai convenabil lucru va fi un principiu de funcționare familiar și standard.
Majoritatea utilizatorilor vor fi cel mai probabil mai bine dacă nu trebuie să-și amintească o grămadă de taste pentru cli, să configureze o mulțime de opțiuni diferite, adesea obscure, prin web sau tui, sau să configureze notificări despre operarea nereușită. Aceasta include, de asemenea, capacitatea de a „încadra” cu ușurință o soluție de backup în infrastructura existentă, precum și automatizarea procesului de backup. Există, de asemenea, posibilitatea instalării folosind un manager de pachete, sau în una sau două comenzi precum „descărcați și despachetați”. curl ссылка | sudo bash - o metodă complexă, deoarece trebuie să verificați ce ajunge prin link.
De exemplu, dintre candidații luați în considerare, o soluție simplă este burp, rdiff-backup și restic, care au taste mnemonice pentru diferite moduri de operare. Puțin mai complexe sunt borg și duplicity. Cel mai dificil a fost AMANDA. Restul sunt undeva la mijloc în ceea ce privește ușurința în utilizare. În orice caz, dacă aveți nevoie de mai mult de 30 de secunde pentru a citi manualul de utilizare, sau trebuie să mergeți la Google sau un alt motor de căutare și, de asemenea, să parcurgeți o foaie lungă de ajutor, decizia este dificilă, într-un fel sau altul.
Unii dintre candidații luați în considerare sunt capabili să trimită automat un mesaj prin e-mailjabber, în timp ce alții se bazează pe alertele configurate în sistem. Mai mult, de cele mai multe ori soluțiile complexe nu au setări de alertă complet evidente. În orice caz, dacă programul de rezervă produce un cod de returnare diferit de zero, care va fi înțeles corect de către serviciul de sistem pentru sarcini periodice (un mesaj va fi trimis administratorului de sistem sau direct la monitorizare) - situația este simplă. Dar dacă sistemul de rezervă, care nu rulează pe un server de rezervă, nu poate fi configurat, modul evident de a spune despre problemă este că complexitatea este deja excesivă. În orice caz, emiterea de avertismente și alte mesaje numai către interfața web sau către jurnal este o practică proastă, deoarece de cele mai multe ori acestea vor fi ignorate.
În ceea ce privește automatizarea, un program simplu poate citi variabile de mediu care îi stabilesc modul de funcționare, sau are un cli dezvoltat care poate duplica complet comportamentul atunci când lucrează printr-o interfață web, de exemplu. Aceasta include și posibilitatea de funcționare continuă, disponibilitatea oportunităților de extindere etc.
versatilitatea
Reluând parțial subsecțiunea anterioară referitoare la automatizare, nu ar trebui să fie o problemă deosebită „încadrarea” procesului de backup în infrastructura existentă.
Este demn de remarcat faptul că utilizarea porturilor non-standard (ei bine, cu excepția interfeței web) pentru muncă, implementarea criptării într-un mod non-standard, schimbul de date folosind un protocol non-standard sunt semne ale unui non-standard. -solutie universala. În cea mai mare parte, toți candidații le au într-un fel sau altul din motivul evident: simplitatea și versatilitatea de obicei nu merg împreună. Ca o excepție - burp, există și altele.
Ca semn - capacitatea de a lucra folosind ssh obișnuit.
Viteza de lucru
Cel mai controversat și controversat punct. Pe de o parte, am lansat procesul, a funcționat cât mai repede posibil și nu a interferat cu sarcinile principale. Pe de altă parte, există o creștere a traficului și a încărcării procesorului în perioada de rezervă. De asemenea, este de remarcat faptul că cele mai rapide programe pentru realizarea de copii sunt de obicei cele mai sărace în ceea ce privește funcțiile care sunt importante pentru utilizatori. Din nou: dacă pentru a obține un fișier text nefericit cu o dimensiune de câteva zeci de octeți cu o parolă și, din această cauză, întregul serviciu costă (da, da, înțeleg că procesul de backup nu este cel mai adesea de vină aici), și trebuie să recitiți secvențial toate fișierele din depozit sau să extindeți întreaga arhivă - sistemul de backup nu este niciodată rapid. Un alt punct care devine adesea o piatră de poticnire este viteza de implementare a unei copii de rezervă dintr-o arhivă. Există aici un avantaj clar pentru cei care pot pur și simplu să copieze sau să mute fișiere în locația dorită fără prea multe manipulări (rsync, de exemplu), dar cel mai adesea problema trebuie rezolvată într-un mod organizatoric, empiric: prin măsurarea timpului de recuperare a backupului. și informând deschis utilizatorii despre acest lucru.
stabilitate
Ar trebui înțeles astfel: pe de o parte, trebuie să fie posibilă implementarea copiei de rezervă înapoi în orice fel, pe de altă parte, trebuie să fie rezistentă la diverse probleme: întreruperea rețelei, defecțiunea discului, ștergerea unei părți din repertoriu.
Comparația instrumentelor de backup
Timpul de creare a copiei
Copiați timpul de recuperare
Instalare usoara
Configurare ușoară
Ușor de folosit
Automatizare simplă
Ai nevoie de un client server?
Verificarea integrității depozitului
Copii diferențiale
Lucrează prin conductă
versatilitatea
Independenţă
Transparența depozitului
Criptare
Comprimare
Deduplicarea
Interfață web
Umplere până la nor
Suport Windows
marca
Rsync
4m15s
4m28s
da
nu
nu
nu
da
nu
nu
da
nu
da
da
nu
nu
nu
nu
nu
da
6
Gudron
pur
3m12s
2m43s
da
nu
nu
nu
nu
nu
da
da
nu
da
nu
nu
nu
nu
nu
nu
da
8,5
gzip
9m37s
3m19s
da
Rdiff-backup
16m26s
17m17s
da
da
da
da
da
nu
da
nu
da
nu
da
nu
da
da
da
nu
da
11
Rsnapshot
4m19s
4m28s
da
da
da
da
nu
nu
da
nu
da
nu
da
nu
nu
da
da
nu
da
12,5
burp
11m9s
7m2s
da
nu
da
da
da
da
da
nu
da
da
nu
nu
da
nu
da
nu
da
10,5
Duplicitate
fara criptare
16m48s
10m58s
da
da
nu
da
nu
da
da
nu
nu
da
nu
da
da
nu
da
nu
da
11
GPG
17m27s
15m3s
Duplicati
fara criptare
20m28s
13m45s
nu
da
nu
nu
nu
da
da
nu
nu
da
nu
da
da
da
da
da
da
11
aes
29m41s
21m40s
GPG
26m19s
16m30s
zbackup
fara criptare
40m3s
11m8s
da
da
nu
nu
nu
da
da
da
nu
da
nu
da
da
da
nu
nu
nu
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
Borg Backup
fara criptare
4m7s
2m45s
da
da
da
da
da
da
da
da
da
da
nu
da
da
da
da
nu
da
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
da
da
da
da
nu
da
da
da
da
da
nu
da
nu
da
nu
da
da
15,5
urBackup
8m21s
8m19s
da
da
da
nu
da
nu
da
nu
da
da
nu
da
da
da
da
nu
da
12
Amanda
9m3s
2m49s
da
nu
nu
da
da
da
da
nu
da
da
da
da
da
nu
da
da
da
13
BackupPC
rsync
12m22s
7m42s
da
nu
da
da
da
da
da
nu
da
nu
nu
da
da
nu
da
nu
da
10,5
gudron
12m34s
12m15s
Legenda tabelului:
- Verde, timp de funcționare mai mic de cinci minute sau răspundeți „Da” (cu excepția coloanei „Aveți nevoie de un server client?”), 1 punct
- Galben, timp de funcționare cinci până la zece minute, 0.5 puncte
- Roșu, timpul de lucru este mai mare de zece minute sau răspunsul este „Nu” (cu excepția coloanei „Ai nevoie de un server client?”), 0 puncte
Conform tabelului de mai sus, cel mai simplu, mai rapid și, în același timp, convenabil și puternic instrument de backup este BorgBackup. Restic a ocupat locul doi, restul candidaților luați în considerare au fost plasați aproximativ egal cu un spread de unul sau două puncte la final.
Le mulțumesc tuturor celor care au citit seria până la sfârșit, vă invit să discutați opțiunile și să le oferi pe ale tale, dacă există. Pe măsură ce discuția avansează, tabelul poate fi extins.
Rezultatul seriei va fi articolul final, în care va exista o încercare de a dezvolta un instrument de backup ideal, rapid și ușor de gestionat, care vă permite să implementați o copie înapoi în cel mai scurt timp posibil și, în același timp, să fiți comod și ușor. pentru a configura și întreține.
Anunţ
Backup Partea 6: Comparația instrumentelor de backup
Backup Partea 7: Concluzii
Sursa: www.habr.com