{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, partea 6: Compara\u021bia uneltelor de backup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nAcest articol va compara solu\u021biile de backup, dar mai \u00eent\u00e2i este bine s\u0103 afl\u0103m cum se descurc\u0103 rapid \u0219i eficient cu restaurarea datelor din backup-uri.
\nPentru a simplifica compara\u021bia, se va considera restaurarea dintr-un backup complet, mai ales c\u0103 acest mod de operare este sus\u021binut de to\u021bi candida\u021bii. Pentru simplitate, cifrele sunt deja mediate (media aritmetic\u0103 din mai multe execu\u021bii). Rezultatele vor fi centralizate \u00eentr-un tabel, care va con\u021bine \u0219i informa\u021bii despre func\u021bionalit\u0103\u021bi: existen\u021ba unei interfe\u021be web, u\u0219urin\u021ba \u00een configurare \u0219i utilizare, capacitatea de automatizare, disponibilitatea diferitelor func\u021bionalit\u0103\u021bi suplimentare (de exemplu, verificarea integrit\u0103\u021bii datelor) etc. Graficele vor ar\u0103ta \u00eenc\u0103rcarea serverului, unde datele vor fi aplicate (nu serverul pentru stocarea backup-urilor).
\n<\/a><\/noindex><\/p>\n

Recuperarea datelor<\/h2>\n

\nCa punct de referin\u021b\u0103, vor fi utilizate rsync \u0219i tar, deoarece acestea sunt de obicei baza<\/a><\/noindex> celor mai simple scripturi pentru realizarea backup-urilor.<\/p>\n

Rsync<\/i> a finalizat setul de date de test \u00een 4 minute \u0219i 28 de secunde, ar\u0103t\u00e2nd <\/p>\n

aceast\u0103 \u00eenc\u0103rcare.<\/b>\"Backup,
\n
\nProcesul de restaurare a \u00eent\u00e2mpinat limitarea subsistemului de disc al serverului de stocare a backup-urilor (graficele au o form\u0103 sinuoas\u0103). De asemenea, este evident\u0103 \u00eenc\u0103rcarea unui singur nucleu f\u0103r\u0103 probleme semnificative (iowait sc\u0103zut \u0219i softirq \u2014 f\u0103r\u0103 probleme cu discul \u0219i re\u021beaua, respectiv). Deoarece celelalte dou\u0103 programe, \u0219i anume rdiff-backup \u0219i rsnapshot, se bazeaz\u0103 pe rsync \u0219i ofer\u0103, de asemenea, rsync obi\u0219nuit ca mijloc de restaurare, va avea un profil de \u00eenc\u0103rcare similar \u0219i timpul de restaurare al backup-ului.<\/p>\n

Tar<\/i> a finalizat u\u0219or mai repede, \u00een <\/p>\n

2 minute \u0219i 43 de secunde:<\/b>\"Backup,
\n
\n\u00cenc\u0103rcarea total\u0103 a sistemului a fost cu 20% mai mare \u00een medie din cauza cre\u0219terii softirq \u2014 cheltuielile indirecte legate de func\u021bionarea subsistemului de re\u021bea au crescut.<\/p>\n

Dac\u0103 arhiva este comprimat\u0103 suplimentar, timpul de restaurare cre\u0219te la 3 minute \u0219i 19 secunde cu
\naceast\u0103 \u00eenc\u0103rcare pe serverul principal (dezarhivare pe partea serverului principal):<\/b>\"Backup,
\n
\nProcesul de decompresie utilizeaz\u0103 ambele nuclee ale procesorului, deoarece ruleaz\u0103 dou\u0103 procese. \u00cen general - un rezultat a\u0219teptat. De asemenea, un rezultat comparabil (3 minute \u0219i 20 de secunde) a fost ob\u021binut prin rularea gzip pe server cu copiile de rezerv\u0103, profilul de \u00eenc\u0103rcare pe serverul principal fiind foarte asem\u0103n\u0103tor cu rularea tar f\u0103r\u0103 compresorul gzip (vezi graficul anterior).<\/p>\n

\u00cen rdiff-backup<\/i> se poate sincroniza ultima copie de rezerv\u0103 realizat\u0103 folosind rsync obi\u0219nuit (rezultatele vor fi similare), dar copiile de rezerv\u0103 mai vechi tot trebuie restaurate folosind programul rdiff-backup, care a reu\u0219it s\u0103 efectueze restaurarea \u00een 17 minute \u0219i 17 secunde, ar\u0103t\u00e2nd <\/p>\n

o astfel de \u00eenc\u0103rcare:<\/b>\"Backup,
\n
\nEste posibil s\u0103 fi fost a\u0219a conceput, \u00een orice caz pentru limitarea vitezei autorii ofer\u0103 o astfel de solu\u021bie<\/a><\/noindex>. Procesul de restaurare a copiei de rezerv\u0103 dureaz\u0103 pu\u021bin mai pu\u021bin de jum\u0103tate dintr-un nucleu, cu o performan\u021b\u0103 propor\u021bional comparabil\u0103 (adic\u0103 de 2-5 ori mai lent\u0103) pe disc \u0219i re\u021bea cu rsync.<\/p>\n

Rsnapshot<\/i> pentru restaurare ofer\u0103 utilizarea rsync obi\u0219nuit, astfel \u00eenc\u00e2t rezultatele sale vor fi similare. \u00cen general, a\u0219a a \u0219i fost.<\/p>\n

Burp<\/i> a reu\u0219it s\u0103 \u00eendeplineasc\u0103 sarcina de restaurare a copiei de rezerv\u0103 \u00een 7 minute \u0219i 2 secunde cu
\no astfel de \u00eenc\u0103rcare:<\/b>\"Backup,
\n
\nA func\u021bionat destul de repede \u0219i, cel pu\u021bin, mult mai convenabil dec\u00e2t rsync-ul simplu: nu trebuie s\u0103 \u021bii minte vreo op\u021biune, are o interfa\u021b\u0103 cli simpl\u0103 \u0219i intuitiv\u0103, suport \u00eencorporat pentru mai multe copii \u2014 dar este de aproximativ dou\u0103 ori mai lent. Dac\u0103 datele trebuie restaurate din ultima copie de rezerv\u0103 realizat\u0103 \u2014 se poate folosi rsync, cu mici preciz\u0103ri.<\/p>\n

Programul BackupPC<\/i> a ar\u0103tat o vitez\u0103 \u0219i o \u00eenc\u0103rcare aproximativ asem\u0103n\u0103toare \u00een modul de transmitere rsync, desf\u0103\u0219ur\u00e2nd copia de rezerv\u0103 \u00een <\/p>\n

7 minute \u0219i 42 de secunde:<\/b>\"Backup,
\n
\n\u00cens\u0103 \u00een modul de transmitere a datelor cu tar, BackupPC s-a descurcat mai lent: \u00een 12 minute \u0219i 15 secunde, \u00eenc\u0103rcarea pe procesor fiind \u00een general mai mic\u0103 <\/p>\n

cu o dat\u0103 \u0219i jum\u0103tate:<\/b>\"Backup,
\n
\nDuplicity<\/i> f\u0103r\u0103 criptare a ar\u0103tat rezultate pu\u021bin mai bune, reu\u0219ind s\u0103 recupereze o copie de rezerv\u0103 \u00een 10 minute \u0219i 58 de secunde. Dac\u0103 se activeaz\u0103 criptarea cu gpg, timpul de recuperare cre\u0219te la 15 minute \u0219i 3 secunde. De asemenea, c\u00e2nd se creeaz\u0103 un depozit pentru stocarea copiilor, se poate specifica dimensiunea arhivei care va fi utilizat\u0103 pentru fragmentarea fluxului de date. \u00cen general, pe hard disk-urile obi\u0219nuite, la fel \u0219i din cauza modului de lucru pe un singur fir, nu exist\u0103 o diferen\u021b\u0103 semnificativ\u0103. Aceasta va ap\u0103rea, probabil, la dimensiuni diferite ale blocurilor, c\u00e2nd se folosesc stoc\u0103ri hibride. Sarcina pe serverul principal \u00een timpul recuper\u0103rii a fost astfel:<\/p>\n

f\u0103r\u0103 criptare<\/b>\"Backup,
\n
\ncu criptare<\/b>\"Backup,
\n
\nDuplicati<\/i> a ar\u0103tat o vitez\u0103 de recuperare comparabil\u0103, reu\u0219ind \u00een 13 minute \u0219i 45 de secunde. \u00cen plus, au fost necesare aproximativ 5 minute pentru a verifica corectitudinea datelor recuperate (\u00een total aproximativ 19 minute). Sarcina a fost <\/p>\n

destul de mare:<\/b>\"Backup,
\n
\nC\u00e2nd criptarea aes a fost activat\u0103 prin mijloace interne, timpul de recuperare a fost de 21 de minute \u0219i 40 de secunde, iar sarcina pe procesor a fost maxim\u0103 (ambele nuclee!) \u00een timpul recuper\u0103rii; \u00een timpul verific\u0103rii datelor a fost activ un singur fir, ocup\u00e2nd un nucleu procesor. Verificarea datelor dup\u0103 recuperare a durat acelea\u0219i 5 minute (\u00een total aproape 27 de minute).<\/p>\n

Rezultatul<\/b>\"Backup,
\n
\nPu\u021bin mai repede, duplicati a reu\u0219it s\u0103 recupereze folosind un program extern gpg pentru criptare, dar \u00een general diferen\u021bele fa\u021b\u0103 de modul anterior sunt minime. Timpul de func\u021bionare a fost de 16 minute \u0219i 30 de secunde, cu verificarea datelor \u00een 6 minute. Sarcina a fost <\/p>\n

de aceast\u0103 natur\u0103:<\/b>\"Backup,
\n
\nAMANDA<\/i>, folosind tar, a reu\u0219it \u00een 2 minute \u0219i 49 de secunde, ceea ce, \u00een principiu, este foarte apropiat de tar-ul obi\u0219nuit. Sarcina pe sistem a fost \u00een principiu <\/p>\n

la fel:<\/b>\"Backup,
\n
\n\u00cen timpul recuper\u0103rii unei copii de rezerv\u0103 cu ajutorul zbackup<\/i> au rezultat urm\u0103toarele:<\/p>\n

criptare, compresie lzma<\/b>\"Backup,
\n
\nTimpul de func\u021bionare 11 minute \u0219i 8 secunde<\/p>\n

criptare aes, compresie lzma<\/b>\"Backup,
\n
\nTimpul de func\u021bionare 14 minute<\/p>\n

criptare aes, compresie lzo<\/b>\"Backup,
\n
\nTimpul de func\u021bionare 6 minute, 19 secunde<\/p>\n

\u00cen general, nu e r\u0103u. Totul depinde de viteza procesorului pe serverul de backup, ceea ce se observ\u0103 clar \u00een timpul de func\u021bionare al programului cu diferite compresoare. Pe partea serverului de backup, a fost utilizat tar obi\u0219nuit, a\u0219a c\u0103, compar\u00e2nd cu acesta, recuperarea func\u021bioneaz\u0103 de 3 ori mai lent. Poate ar trebui s\u0103 verific\u0103m func\u021bionarea \u00een modul multi-threading, cu un num\u0103r de fire mai mare de dou\u0103.<\/p>\n

BorgBackup<\/i> \u00een modul f\u0103r\u0103 criptare, s-a descurcat pu\u021bin mai lent dec\u00e2t tar, \u00een 2 minute \u0219i 45 de secunde, \u00eens\u0103, spre deosebire de acela\u0219i tar, a ap\u0103rut posibilitatea deduplic\u0103rii repozitoriului. Sarcina a fost <\/p>\n

urm\u0103toarea:<\/b>\"Backup,
\n
\nDac\u0103 activ\u0103m criptarea bazat\u0103 pe blake, viteza de recuperare a backup-ului se \u00eencetine\u0219te pu\u021bin. Timpul de recuperare \u00een acest mod este de 3 minute \u0219i 19 secunde, iar sarcina a fost <\/p>\n

astfel:<\/b>\"Backup,
\n
\nCriptarea aes func\u021bioneaz\u0103 pu\u021bin mai lent, timpul de recuperare este de 3 minute \u0219i 23 de secunde, sarcina nu s-a schimbat semnificativ: <\/p>\n

nu s-a schimbat:<\/b>\"Backup,
\n
\nDeoarece Borg poate func\u021biona \u00een modul multi-threading, sarcina procesorului este maxim\u0103, iar activarea func\u021biilor suplimentare m\u0103re\u0219te doar timpul de func\u021bionare. Se pare c\u0103 ar trebui s\u0103 investig\u0103m multi-threading-ul func\u021bion\u0103rii \u00een mod similar cu zbackup.<\/p>\n

Restic<\/i> s-a descurcat cu recuperarea pu\u021bin mai lent, timpul de lucru a fost de 4 minute \u0219i 28 de secunde. Sarcina a ar\u0103tat <\/p>\n

a\u0219a:<\/b>\"Backup,
\n
\nSe pare c\u0103 procesul de recuperare func\u021bioneaz\u0103 pe mai multe fire, dar eficien\u021ba nu este la fel de ridicat\u0103 ca la BorgBackup, totu\u0219i este comparabil\u0103 ca timp cu rsync obi\u0219nuit.<\/p>\n

Folosind UrBackup<\/i> a reu\u0219it s\u0103 recupereze datele \u00een 8 minute \u0219i 19 secunde, sarcina a fost <\/p>\n

de aceast\u0103 natur\u0103:<\/b>\"Backup,
\n
\n\u00cen continuare se observ\u0103 o sarcin\u0103 nu foarte mare, chiar mai mic\u0103 dec\u00e2t la tar. Au fost unele v\u00e2rfuri, dar nu mai mult dec\u00e2t \u00eenc\u0103rcarea unui nucleu.<\/p>\n

Alegerea \u0219i justificarea criteriilor pentru comparare<\/h2>\n

\nDup\u0103 cum a fost men\u021bionat \u00een unul dintre articolele anterioare, sistemul de backup trebuie s\u0103 corespund\u0103 urm\u0103toarelor criterii:<\/p>\n