Acest articol va compara soluțiile de backup, dar mai întâi este bine să aflăm cum se descurcă rapid și eficient cu restaurarea datelor din backup-uri.
Pentru a simplifica comparația, se va considera restaurarea dintr-un backup complet, mai ales că acest mod de operare este susținut de toți candidații. Pentru simplitate, cifrele sunt deja mediate (media aritmetică din mai multe execuții). Rezultatele vor fi centralizate într-un tabel, care va conține și informații despre funcționalități: existența unei interfețe web, ușurința în configurare și utilizare, capacitatea de automatizare, disponibilitatea diferitelor funcționalități suplimentare (de exemplu, verificarea integrității datelor) etc. Graficele vor arăta încărcarea serverului, unde datele vor fi aplicate (nu serverul pentru stocarea backup-urilor).
Recuperarea datelor
Ca punct de referință, vor fi utilizate rsync și tar, deoarece celor mai simple scripturi pentru realizarea backup-urilor.
Rsync a finalizat setul de date de test în 4 minute și 28 de secunde, arătând
această încărcare.
Procesul de restaurare a întâmpinat limitarea subsistemului de disc al serverului de stocare a backup-urilor (graficele au o formă sinuoasă). De asemenea, este evidentă încărcarea unui singur nucleu fără probleme semnificative (iowait scăzut și softirq — fără probleme cu discul și rețeaua, respectiv). Deoarece celelalte două programe, și anume rdiff-backup și rsnapshot, se bazează pe rsync și oferă, de asemenea, rsync obișnuit ca mijloc de restaurare, va avea un profil de încărcare similar și timpul de restaurare al backup-ului.
Tar a finalizat ușor mai repede, în
2 minute și 43 de secunde:
Încărcarea totală a sistemului a fost cu 20% mai mare în medie din cauza creșterii softirq — cheltuielile indirecte legate de funcționarea subsistemului de rețea au crescut.
Dacă arhiva este comprimată suplimentar, timpul de restaurare crește la 3 minute și 19 secunde cu
această încărcare pe serverul principal (dezarhivare pe partea serverului principal):
Procesul de decompresie utilizează ambele nuclee ale procesorului, deoarece rulează două procese. În general - un rezultat așteptat. De asemenea, un rezultat comparabil (3 minute și 20 de secunde) a fost obținut prin rularea gzip pe server cu copiile de rezervă, profilul de încărcare pe serverul principal fiind foarte asemănător cu rularea tar fără compresorul gzip (vezi graficul anterior).
În rdiff-backup se poate sincroniza ultima copie de rezervă realizată folosind rsync obișnuit (rezultatele vor fi similare), dar copiile de rezervă mai vechi tot trebuie restaurate folosind programul rdiff-backup, care a reușit să efectueze restaurarea în 17 minute și 17 secunde, arătând
o astfel de încărcare:
Este posibil să fi fost așa conceput, în orice caz pentru limitarea vitezei autorii . Procesul de restaurare a copiei de rezervă durează puțin mai puțin de jumătate dintr-un nucleu, cu o performanță proporțional comparabilă (adică de 2-5 ori mai lentă) pe disc și rețea cu rsync.
Rsnapshot pentru restaurare oferă utilizarea rsync obișnuit, astfel încât rezultatele sale vor fi similare. În general, așa a și fost.
Burp a reușit să îndeplinească sarcina de restaurare a copiei de rezervă în 7 minute și 2 secunde cu
o astfel de încărcare:
A funcționat destul de repede și, cel puțin, mult mai convenabil decât rsync-ul simplu: nu trebuie să ții minte vreo opțiune, are o interfață cli simplă și intuitivă, suport încorporat pentru mai multe copii — dar este de aproximativ două ori mai lent. Dacă datele trebuie restaurate din ultima copie de rezervă realizată — se poate folosi rsync, cu mici precizări.
Programul BackupPC a arătat o viteză și o încărcare aproximativ asemănătoare în modul de transmitere rsync, desfășurând copia de rezervă în
7 minute și 42 de secunde:
Însă în modul de transmitere a datelor cu tar, BackupPC s-a descurcat mai lent: în 12 minute și 15 secunde, încărcarea pe procesor fiind în general mai mică
cu o dată și jumătate:
Duplicity fără criptare a arătat rezultate puțin mai bune, reușind să recupereze o copie de rezervă în 10 minute și 58 de secunde. Dacă se activează criptarea cu gpg, timpul de recuperare crește la 15 minute și 3 secunde. De asemenea, când se creează un depozit pentru stocarea copiilor, se poate specifica dimensiunea arhivei care va fi utilizată pentru fragmentarea fluxului de date. În general, pe hard disk-urile obișnuite, la fel și din cauza modului de lucru pe un singur fir, nu există o diferență semnificativă. Aceasta va apărea, probabil, la dimensiuni diferite ale blocurilor, când se folosesc stocări hibride. Sarcina pe serverul principal în timpul recuperării a fost astfel:
fără criptare
cu criptare
Duplicati a arătat o viteză de recuperare comparabilă, reușind în 13 minute și 45 de secunde. În plus, au fost necesare aproximativ 5 minute pentru a verifica corectitudinea datelor recuperate (în total aproximativ 19 minute). Sarcina a fost
destul de mare:
Când criptarea aes a fost activată prin mijloace interne, timpul de recuperare a fost de 21 de minute și 40 de secunde, iar sarcina pe procesor a fost maximă (ambele nuclee!) în timpul recuperării; în timpul verificării datelor a fost activ un singur fir, ocupând un nucleu procesor. Verificarea datelor după recuperare a durat aceleași 5 minute (în total aproape 27 de minute).
Rezultatul
Puțin mai repede, duplicati a reușit să recupereze folosind un program extern gpg pentru criptare, dar în general diferențele față de modul anterior sunt minime. Timpul de funcționare a fost de 16 minute și 30 de secunde, cu verificarea datelor în 6 minute. Sarcina a fost
de această natură:
AMANDA, folosind tar, a reușit în 2 minute și 49 de secunde, ceea ce, în principiu, este foarte apropiat de tar-ul obișnuit. Sarcina pe sistem a fost în principiu
la fel:
În timpul recuperării unei copii de rezervă cu ajutorul zbackup au rezultat următoarele:
criptare, compresie lzma
Timpul de funcționare 11 minute și 8 secunde
criptare aes, compresie lzma
Timpul de funcționare 14 minute
criptare aes, compresie lzo
Timpul de funcționare 6 minute, 19 secunde
În general, nu e rău. Totul depinde de viteza procesorului pe serverul de backup, ceea ce se observă clar în timpul de funcționare al programului cu diferite compresoare. Pe partea serverului de backup, a fost utilizat tar obișnuit, așa că, comparând cu acesta, recuperarea funcționează de 3 ori mai lent. Poate ar trebui să verificăm funcționarea în modul multi-threading, cu un număr de fire mai mare de două.
BorgBackup în modul fără criptare, s-a descurcat puțin mai lent decât tar, în 2 minute și 45 de secunde, însă, spre deosebire de același tar, a apărut posibilitatea deduplicării repozitoriului. Sarcina a fost
următoarea:
Dacă activăm criptarea bazată pe blake, viteza de recuperare a backup-ului se încetinește puțin. Timpul de recuperare în acest mod este de 3 minute și 19 secunde, iar sarcina a fost
astfel:
Criptarea aes funcționează puțin mai lent, timpul de recuperare este de 3 minute și 23 de secunde, sarcina nu s-a schimbat semnificativ:
не поменялась:
Deoarece Borg poate funcționa în modul multi-threading, sarcina procesorului este maximă, iar activarea funcțiilor suplimentare mărește doar timpul de funcționare. Se pare că ar trebui să investigăm multi-threading-ul funcționării în mod similar cu zbackup.
Restic s-a descurcat cu recuperarea puțin mai lent, timpul de lucru a fost de 4 minute și 28 de secunde. Sarcina a arătat
așa:
Se pare că procesul de recuperare funcționează pe mai multe fire, dar eficiența nu este la fel de ridicată ca la BorgBackup, totuși este comparabilă ca timp cu rsync obișnuit.
Folosind UrBackup a reușit să recupereze datele în 8 minute și 19 secunde, sarcina a fost
de această natură:
În continuare se observă o sarcină nu foarte mare, chiar mai mică decât la tar. Au fost unele vârfuri, dar nu mai mult decât încărcarea unui nucleu.
Alegerea și justificarea criteriilor pentru comparare
După cum a fost menționat în unul dintre articolele anterioare, sistemul de backup trebuie să corespundă următoarelor criterii:
- Ușurința în utilizare
- Universalitate
- Stabilitate
- Viteza
Ar trebui să analizăm fiecare punct separat mai detaliat.
Ușurința în utilizare
Cel mai bine este când există un singur buton „Fă totul bine”, dar dacă revenim la programele reale, cel mai convenabil va fi un principiu de lucru familiar și standard.
Majoritatea utilizatorilor vor prefera, cel mai probabil, să nu țină minte o mulțime de chei pentru cli, să nu configureze o serie de opțiuni diferite, adesea neclare, prin web sau tui, și să nu seteze alertă pentru erori. De asemenea, se include posibilitatea de a integra cu ușurință o soluție de backup în infrastructura existentă, precum și automatizarea procesului de backup. Este important și faptul că se poate instala printr-un manager de pachete sau cu una-două comenzi de tipul „descarcă și dezarhivează”. curl link | sudo bash — o metodă complicată, deoarece trebuie să verifici ce primești prin link.
De exemplu, dintre candidații analizați, soluțiile simple sunt burp, rdiff-backup și restic, care au chei memorabile pentru diferite moduri de funcționare. Un pic mai complexe sunt borg și duplicity. Cea mai complicată a fost AMANDA. Celelalte sunt undeva la mijloc ca ușurință de utilizare. În orice caz, dacă trebuie să îți ia mai mult de 30 de secunde pentru a citi un ghid de utilizare sau trebuie să cauți pe Google sau alt motor de căutare, precum și să răsfoiești o fâșie lungă de ajutor — soluția este complicată, într-un fel sau altul.
O parte dintre candidații analizați pot trimite automat mesaje prin e-mail/jabber, în timp ce altele depind de alertele configurate în sistem. De cele mai multe ori, soluțiile complicate au setări de alertă care nu sunt foarte evidente. În oricum, dacă programul de backup returnează un cod de eroare non-zero, care este corect interpretat de serviciul de sistem pentru sarcini periodice (mesajul va ajunge la administratorul sistemului sau direct în monitorizare) — situația este simplă. Dar dacă sistemul de backup, care nu operează pe serverul de backup, nu poate comunica în mod evident despre problemă fără configurare — complexitatea devine excesivă. În orice caz, emiterea de alerte și alte mesaje doar în interfața web sau în jurnal — este o practică proastă, deoarece acestea vor fi adesea ignorate.
În ceea ce privește automatizarea — un program simplu trebuie să poată citi variabilele de mediu care stabilesc modul său de operare, sau să aibă un cli bine dezvoltat, care să poată reproduca complet comportamentul de funcționare prin interfața web, de exemplu. De asemenea, se include posibilitatea de a lucra în mod continuu, existența unor opțiuni de extensie etc.
Universalitate
Se intersectează parțial cu subcapitolul anterior în ceea ce privește automatizarea, nu ar trebui să fie o problemă deosebită „înglobarea” procesului de backup în infrastructura existentă.
Merită menționat că utilizarea porturilor nestandard (cu excepția interfeței web) pentru funcționare, implementarea criptării într-un mod nespecificat, schimbul de date printr-un protocol nestandard — sunt semnele unei soluții non-uniuniversal. În mare parte, toți candidații le au într-un fel sau altul dintr-un motiv destul de evident: simplitatea și universalitatea sunt de obicei incompatibile. Ca excepție — burp, există și altele.
Ca semn, exista posibilitatea de a funcționa folosind ssh obișnuit.
Viteza de funcționare
Cel mai controversat și disputat punct. Pe de o parte — am pornit procesul, a fost realizat cât mai rapid și nu interferează cu sarcinile principale. Pe de altă parte — un vârf de trafic și o încărcătură pe procesor în timpul backup-ului. De asemenea, merită menționat că cele mai rapide programe de realizare a copiilor sunt de obicei cele mai sărace în funcții importante pentru utilizatori. Din nou: dacă pentru a extrage un nenorocit de fișier text cu o dimensiune de câteva zeci de байти cu parolă, iar din cauza acestuia întregul serviciu e afectat (da-da, înțeleg că aici procesul de backup nu e vinovat în cele mai multe cazuri), și trebuie să citesc secvențial toate fișierele din repository sau să decomprim un întreg arhivă — sistemul de backup nu este nicidecum rapid. Un alt punct care devine adesea o piatră de încercare — viteza de restaurare a backup-ului din arhivă. Aici există un avantaj clar pentru cei care pot pur și simplu să copieze sau să mute fișierele în locul dorit fără manipulări speciale (de exemplu, rsync), dar de cele mai multe ori problema trebuie rezolvată organizatoric, empiric: măsurând timpul de recuperare a backup-ului și comunicând deschis utilizatorilor despre acest lucru.
Stabilitate
Trebuie înțeles astfel: pe de o parte, trebuie să existe posibilitatea de a restaura backup-ul în orice fel, pe de altă parte — rezistența la diverse probleme: întreruperea rețelei, defecțiunea discului, ștergerea unei părți a repository-ului.
Compararea soluțiilor de backup
Timpul de creare a copiei
Timpul de restaurare a copiei
Instalare simplă
Configurare simplă
Utilizare simplă
Automatizare simplă
Este necesar un client-server?
Verificarea integrității repository-ului
Copii diferențiale
Lucrează prin pipe
Universalitate
Independență
Transparența repository-ului
Criptare
Compresie
Deduplicarea
Interfața web
Încărcare în cloud
Suport pentru Windows
Punctaj
Rsync
4m15s
4m28s
da
nu
nu
nu
da
nu
nu
da
nu
da
da
nu
nu
nu
nu
nu
da
6
Tar
pure
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
Duplicity
fără 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
fără 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
fără 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
BorgBackup
fără 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
tar
12m34s
12m15s
Legenda tabelului:
- Verde, timpul de funcționare este mai mic de cinci minute sau răspuns „Da” (cu excepția coloanei „Necesită client-server?”), 1 punct
- Galben, timpul de funcționare cinci-zece minute, 0.5 puncte
- Roșu, timpul de funcționare este mai mare de zece minute sau răspuns „Nu” (cu excepția coloanei „Necesită client-server?”), 0 puncte
Conform tabelului de mai sus, cel mai simplu, rapid și în același timp convenabil și puternic instrument pentru backup este BorgBackup. Pe locul doi se află Restic, iar ceilalți candidați analizați s-au plasat aproximativ la fel, cu o discrepanță de unu-doi puncte la final.
Mulțumesc tuturor celor care au citit ciclul până la capăt, propun să discutăm opțiunile, să oferiți contribuțiile voastre, dacă aveți. Pe măsură ce discutăm, tabelul poate fi completat.
Rezultatul ciclului va fi un articol final, în care va fi o încercare de a găsi un instrument ideal, rapid și gestionabil pentru backup, care să permită restaurarea rapidă a copiei și în același timp să ofere comoditate și ușurință în configurare și întreținere.
Anunț
Backup, partea 6: Comparația uneltelor de backup
Backup, partea 7: Concluzii
Sursa: habr.com
