Šajā rakstā tiks salīdzināti dublēšanas rīki, taču vispirms jānoskaidro, cik ātri un labi tie tiek galā ar datu atjaunošanu no dublējumkopijām.
Lai atvieglotu salīdzināšanu, mēs apsvērsim iespēju atjaunot no pilnas dublējuma, jo īpaši tāpēc, ka visi kandidāti atbalsta šo darbības režīmu. Vienkāršības labad skaitļi jau ir vidēji (vairāku skrējienu vidējais aritmētiskais). Rezultāti tiks apkopoti tabulā, kurā būs arī informācija par iespējām: tīmekļa saskarnes esamība, iestatīšanas un darbības vienkāršība, iespēja automatizēt, dažādu papildu funkciju klātbūtne (piemēram, datu integritātes pārbaude) utt. Grafikos būs redzama servera noslodze, kurā tiks izmantoti dati (nevis serveris rezerves kopiju glabāšanai).
Datu atkopšana
rsync un tar tiks izmantoti kā atskaites punkts kopš vienkārši skripti rezerves kopiju veidošanai.
Rsync ar testa datu kopu tika galā 4 minūtēs un 28 sekundēs, parādot
tāda slodze
Atkopšanas process skāra dublējuma krātuves servera diska apakšsistēmas ierobežojumu (zāģzoba diagrammas). Var arī skaidri redzēt viena kodola ielādi bez problēmām (zems iowait un softirq - nav problēmas ar disku un tīklu, attiecīgi). Tā kā pārējās divas programmas, proti, rdiff-backup un rsnapshot, ir balstītas uz rsync un piedāvā arī parasto rsync kā atkopšanas rīku, tām būs aptuveni vienāds ielādes profils un dublējuma atkopšanas laiks.
Darva paveicu to nedaudz ātrāk
2 minūtes un 43 sekundes:
Kopējā sistēmas noslodze bija vidēji par 20% lielāka, jo palielinājās softirq - pieauga pieskaitāmās izmaksas tīkla apakšsistēmas darbības laikā.
Ja arhīvs tiek vēl vairāk saspiests, atkopšanas laiks palielinās līdz 3 minūtēm 19 sekundēm.
ar šādu slodzi uz galvenā servera (izpakošana galvenā servera pusē):
Dekompresijas process aizņem abus procesora kodolus, jo darbojas divi procesi. Kopumā tas ir gaidītais rezultāts. Tāpat salīdzināms rezultāts (3 minūtes un 20 sekundes) tika iegūts, palaižot gzip servera pusē ar dublējumkopijām; slodzes profils galvenajā serverī bija ļoti līdzīgs tar palaišanai bez gzip kompresora (skatiet iepriekšējo grafiku).
В rdiff-dublējums jūs varat sinhronizēt pēdējo dublējumu, ko izveidojāt, izmantojot parasto rsync (rezultāti būs līdzīgi), taču vecāki dublējumkopijas joprojām ir jāatjauno, izmantojot rdiff-backup programmu, kas pabeidza atjaunošanu 17 minūtēs un 17 sekundēs, parādot
šī slodze:
Varbūt tas bija paredzēts, lai vismaz ierobežotu autoru ātrumu . Pats rezerves kopijas atjaunošanas process aizņem nedaudz mazāk par pusi no viena kodola ar proporcionāli salīdzināmu veiktspēju (t.i., 2–5 reizes lēnāku) diskā un tīklā ar rsync.
Fotoattēla momentuzņēmums Atkopšanai tiek ieteikts izmantot parasto rsync, tāpēc tā rezultāti būs līdzīgi. Kopumā sanāca tā.
Atrauga Dublējuma atjaunošanas uzdevumu paveicu 7 minūtēs un 2 sekundēs ar
ar šo slodzi:
Tas darbojās diezgan ātri un vismaz ir daudz ērtāk nekā tīrā rsync: jums nav jāatceras nekādi karodziņi, vienkāršs un intuitīvs klipa interfeiss, iebūvēts atbalsts vairākām kopijām, lai gan tas ir divas reizes lēnāks. Ja jums ir jāatjauno dati no pēdējās izveidotās dublējuma, varat izmantot rsync, ievērojot dažus brīdinājumus.
Programma rādīja aptuveni tādu pašu ātrumu un slodzi BackupPC iespējojot rsync pārsūtīšanas režīmu, izvietojot dublējumu
7 minūtes un 42 sekundes:
Bet datu pārsūtīšanas režīmā BackupPC ar darvu tika galā lēnāk: 12 minūtēs un 15 sekundēs procesora slodze kopumā bija mazāka.
pusotru reizi:
Divkosība bez šifrēšanas uzrādīja nedaudz labākus rezultātus, atjaunojot dublējumu 10 minūtēs un 58 sekundēs. Ja aktivizējat šifrēšanu, izmantojot gpg, atkopšanas laiks palielinās līdz 15 minūtēm un 3 sekundēm. Tāpat, veidojot repozitoriju kopiju glabāšanai, var norādīt arhīva lielumu, kas tiks izmantots, sadalot ienākošo datu straumi. Kopumā parastajos cietajos diskos, arī pateicoties viena vītnes darbības režīmam, nav daudz atšķirību. Ja tiek izmantota hibrīda krātuve, tas var parādīties dažādos bloku izmēros. Galvenā servera slodze atkopšanas laikā bija šāda:
nav šifrēšanas
ar šifrēšanu
Dublikāts uzrādīja salīdzināmu atveseļošanās ātrumu, pabeidzot to 13 minūtēs un 45 sekundēs. Pagāja vēl aptuveni 5 minūtes, lai pārbaudītu atgūto datu pareizību (kopā apmēram 19 minūtes). Slodze bija
diezgan augsts:
Kad AES šifrēšana tika iespējota iekšēji, atkopšanas laiks bija 21 minūte 40 sekundes ar maksimālo CPU noslogojumu (abi kodoli!) atkopšanas laikā; Pārbaudot datus, aktīvs bija tikai viens pavediens, kas aizņem vienu procesora kodolu. Datu pārbaude pēc atkopšanas aizņēma tās pašas 5 minūtes (kopā gandrīz 27 minūtes).
Piedzīvojiet efektīvu rezultātu spēku
duplicati bija nedaudz ātrāks ar atkopšanu, ja šifrēšanai izmantoja ārējo gpg programmu, taču kopumā atšķirības no iepriekšējā režīma ir minimālas. Darbības laiks bija 16 minūtes 30 sekundes, datu pārbaude notika 6 minūtēs. Slodze bija
tāds:
AMANDA, izmantojot darvu, to paveica 2 minūtēs 49 sekundēs, kas principā ir ļoti tuvu parastajai darvai. Sistēmas slodze principā
tas pats:
Atjaunojot dublējumu, izmantojot zbackup tika iegūti šādi rezultāti:
šifrēšana, lzma saspiešana
Darbības laiks 11 minūtes un 8 sekundes
AES šifrēšana, lzma saspiešana
Darbības laiks 14 minūtes
AES šifrēšana, lzo saspiešana
Darbības laiks 6 minūtes, 19 sekundes
Kopumā nav slikti. Tas viss ir atkarīgs no procesora ātruma rezerves serverī, ko var skaidri redzēt no programmas darbības laika ar dažādiem kompresoriem. Rezerves servera pusē tika palaists parasta darva, tāpēc, ja salīdzina ar to, atkopšana ir 3 reizes lēnāka. Iespējams, ir vērts pārbaudīt darbību vairāku vītņu režīmā ar vairāk nekā diviem pavedieniem.
BorgBackup nešifrētā režīmā tas bija nedaudz lēnāks par tar, 2 minūtēs 45 sekundēs, tomēr atšķirībā no darvas radās iespēja dedublēt repozitoriju. Slodze izrādījās
sekojošais:
Ja iespējojat šifrēšanu, kuras pamatā ir Bleika, dublējuma atkopšanas ātrums ir nedaudz lēnāks. Atkopšanas laiks šajā režīmā ir 3 minūtes 19 sekundes, un slodze ir pazudusi
kā šis:
AES šifrēšana ir nedaudz lēnāka, atkopšanas laiks ir 3 minūtes 23 sekundes, īpaši slodze
nav mainījies:
Tā kā Borg var strādāt vairāku vītņu režīmā, procesora slodze ir maksimāla, un, aktivizējot papildu funkcijas, darbības laiks vienkārši palielinās. Acīmredzot ir vērts izpētīt vairākpavedienu izmantošanu līdzīgi kā zbackup.
Atpūta ar atveseļošanos tika galā nedaudz lēnāk, darbības laiks bija 4 minūtes 28 sekundes. Krava izskatījās
tā:
Acīmredzot atkopšanas process darbojas vairākos pavedienos, taču efektivitāte nav tik augsta kā BorgBackup, bet laika ziņā salīdzināma ar parasto rsync.
Ar urBackup Datus varēja atjaunot 8 minūtēs un 19 sekundēs, slodze bija
tāds:
Slodze joprojām nav ļoti liela, pat zemāka par darvu. Vietām ir pārrāvumi, bet ne vairāk kā viena serdeņa slodze.
Salīdzināšanas kritēriju izvēle un pamatojums
Kā minēts vienā no iepriekšējiem rakstiem, rezerves sistēmai jāatbilst šādiem kritērijiem:
- Lietošanas ērtums
- daudzpusība
- stabilitāte
- Ātrums
Ir vērts sīkāk apsvērt katru punktu atsevišķi.
Vienkārša darbība
Vislabāk, ja ir viena poga “Dari visu labi”, bet, atgriežoties pie īstām programmām, ērtākais būs kāds pazīstams un standarta darbības princips.
Lielākajai daļai lietotāju, visticamāk, būs labāk, ja viņiem nebūs jāatceras cli taustiņu kopa, jākonfigurē dažādas, bieži vien neskaidras opcijas, izmantojot tīmekļa vai tui, vai jāiestata paziņojumi par neveiksmīgu darbību. Tas ietver arī iespēju viegli “ievietot” rezerves risinājumu esošajā infrastruktūrā, kā arī dublēšanas procesa automatizāciju. Ir arī iespēja instalēt, izmantojot pakotņu pārvaldnieku vai vienā vai divās komandās, piemēram, “lejupielādēt un izpakot”. curl ссылка | sudo bash - sarežģīta metode, jo jums ir jāpārbauda, kas tiek saņemts, izmantojot saiti.
Piemēram, no aplūkotajiem kandidātiem vienkāršs risinājums ir burp, rdiff-backup un restic, kuriem ir mnemoniskie taustiņi dažādiem darbības režīmiem. Nedaudz sarežģītākas ir borgs un divkosība. Visgrūtākā bija AMANDA. Pārējie lietošanas ērtuma ziņā ir kaut kur pa vidu. Jebkurā gadījumā, ja lietotāja rokasgrāmatas izlasīšanai ir nepieciešamas vairāk nekā 30 sekundes vai jāiet uz Google vai citu meklētājprogrammu, kā arī jāritina gara palīdzības lapa, lēmums ir grūts, tā vai citādi.
Daži no aplūkotajiem kandidātiem spēj automātiski nosūtīt ziņojumu, izmantojot e-pastu, bet citi paļaujas uz konfigurētiem brīdinājumiem sistēmā. Turklāt visbiežāk sarežģītiem risinājumiem nav pilnīgi skaidri brīdinājuma iestatījumi. Jebkurā gadījumā, ja dublēšanas programma ģenerē nulles atgriešanas kodu, ko sistēmas serviss pareizi sapratīs periodiskiem uzdevumiem (tiks nosūtīts ziņojums sistēmas administratoram vai tieši uzraudzībā) - situācija ir vienkārša. Bet, ja dublēšanas sistēmu, kas nedarbojas uz rezerves servera, nevar konfigurēt, acīmredzams veids, kā teikt par problēmu, ir tāds, ka jau tā ir pārmērīga sarežģītība. Jebkurā gadījumā brīdinājumu un citu ziņojumu izsniegšana tikai tīmekļa saskarnei vai žurnālam ir slikta prakse, jo visbiežāk tie tiks ignorēti.
Runājot par automatizāciju, vienkārša programma var nolasīt vides mainīgos, kas nosaka tās darbības režīmu, vai arī tai ir izstrādāts klips, kas var pilnībā dublēt uzvedību, piemēram, strādājot ar tīmekļa saskarni. Tas ietver arī nepārtrauktas darbības iespēju, paplašināšanās iespēju pieejamību utt.
daudzpusība
Daļēji sasaucoties ar iepriekšējo apakšnodaļu par automatizāciju, nevajadzētu būt īpašai problēmai dublēšanas procesa “ievietošana” esošajā infrastruktūrā.
Ir vērts atzīmēt, ka nestandarta portu (labi, izņemot tīmekļa saskarni) izmantošana darbam, šifrēšanas ieviešana nestandarta veidā, datu apmaiņa, izmantojot nestandarta protokolu, liecina par nestandarta protokolu. - universāls risinājums. Lielākoties visiem kandidātiem tās ir vienā vai otrā veidā acīmredzama iemesla dēļ: vienkāršība un daudzpusība parasti neiet kopā. Kā izņēmums - atraugas, ir arī citi.
Kā zīme - spēja strādāt, izmantojot parasto ssh.
Darba ātrums
Pretrunīgākais un strīdīgākais punkts. No vienas puses, mēs uzsākām procesu, tas darbojās pēc iespējas ātrāk un netraucēja galveno uzdevumu veikšanai. No otras puses, dublēšanas periodā palielinās trafika un procesora slodze. Ir arī vērts atzīmēt, ka ātrākās programmas kopiju izgatavošanai parasti ir visnabadzīgākās lietotājiem svarīgo funkciju ziņā. Vēlreiz: ja lai iegūtu vienu neveiksmīgu vairāku desmitu baitu lielu teksta failu ar paroli, un tā dēļ maksā visu servisu (jā, jā, es saprotu, ka dublēšanas process šeit visbiežāk nav vainojams), un jums ir jāpārlasa secīgi visi repozitorijā esošie faili vai jāpaplašina viss arhīvs - dublēšanas sistēma nekad nav ātra. Vēl viens jautājums, kas bieži kļūst par klupšanas akmeni, ir arhīva dublējuma izvietošanas ātrums. Šeit ir nepārprotama priekšrocība tiem, kuri var vienkārši kopēt vai pārvietot failus uz vēlamo vietu bez lielām manipulācijām (piemēram, rsync), taču visbiežāk problēma ir jārisina organizatoriskā veidā, empīriski: mērot dublējuma atjaunošanas laiku. un atklāti informēt lietotājus par to.
stabilitāte
Tas ir jāsaprot šādi: no vienas puses, ir jābūt iespējai jebkādā veidā izvietot atpakaļ rezerves kopiju, no otras puses, tai jābūt izturīgai pret dažādām problēmām: tīkla pārtraukumiem, diska kļūmēm, daļas izdzēšanu. krātuve.
Dublēšanas rīku salīdzinājums
Kopijas izveides laiks
Kopiju atkopšanas laiks
Viegla uzstādīšana
Viegla uzstādīšana
Vienkārša lietošana
Vienkārša automatizācija
Vai jums ir nepieciešams klienta serveris?
Pārbauda repozitorija integritāti
Diferenciālās kopijas
Darbs caur caurulēm
daudzpusība
Neatkarība
Repozitorija caurspīdīgums
Šifrēšana
saspiešana
Deduplikācija
Web interfeiss
Piepildīšana līdz mākonim
Atbalsts Windows
Rezultāts
Rsync
4m15
4m28
jā
nē
nē
nē
jā
nē
nē
jā
nē
jā
jā
nē
nē
nē
nē
nē
jā
6
Darva
tīrs
3m12
2m43
jā
nē
nē
nē
nē
nē
jā
jā
nē
jā
nē
nē
nē
nē
nē
nē
jā
8,5
gzip
9m37
3m19
jā
Rdiff dublējums
16m26
17m17
jā
jā
jā
jā
jā
nē
jā
nē
jā
nē
jā
nē
jā
jā
jā
nē
jā
11
Fotoattēla momentuzņēmums
4m19
4m28
jā
jā
jā
jā
nē
nē
jā
nē
jā
nē
jā
nē
nē
jā
jā
nē
jā
12,5
Atrauga
11m9
7m2
jā
nē
jā
jā
jā
jā
jā
nē
jā
jā
nē
nē
jā
nē
jā
nē
jā
10,5
Divkosība
nav šifrēšanas
16m48
10m58
jā
jā
nē
jā
nē
jā
jā
nē
nē
jā
nē
jā
jā
nē
jā
nē
jā
11
Gpg
17m27
15m3
Dublikāts
nav šifrēšanas
20m28
13m45
nē
jā
nē
nē
nē
jā
jā
nē
nē
jā
nē
jā
jā
jā
jā
jā
jā
11
aES
29m41
21m40
Gpg
26m19
16m30
zbackup
nav šifrēšanas
40m3
11m8
jā
jā
nē
nē
nē
jā
jā
jā
nē
jā
nē
jā
jā
jā
nē
nē
nē
10
aES
42m0
14m1
aes+lzo
18m9
6m19
BorgBackup
nav šifrēšanas
4m7
2m45
jā
jā
jā
jā
jā
jā
jā
jā
jā
jā
nē
jā
jā
jā
jā
nē
jā
16
aES
4m58
3m23
blake2
4m39
3m19
Atpūta
5m38
4m28
jā
jā
jā
jā
nē
jā
jā
jā
jā
jā
nē
jā
nē
jā
nē
jā
jā
15,5
urBackup
8m21
8m19
jā
jā
jā
nē
jā
nē
jā
nē
jā
jā
nē
jā
jā
jā
jā
nē
jā
12
Amanda
9m3
2m49
jā
nē
nē
jā
jā
jā
jā
nē
jā
jā
jā
jā
jā
nē
jā
jā
jā
13
BackupPC
rsync
12m22
7m42
jā
nē
jā
jā
jā
jā
jā
nē
jā
nē
nē
jā
jā
nē
jā
nē
jā
10,5
darva
12m34
12m15
Tabulas leģenda:
- Zaļš, darbības laiks mazāks par piecām minūtēm vai atbilde “Jā” (izņemot aili “Nepieciešams klienta serveris?”), 1 punkts
- Dzeltens, darbības laiks piecas līdz desmit minūtes, 0.5 punkti
- Sarkans, darba laiks ir vairāk nekā desmit minūtes vai atbilde ir “Nē” (izņemot aili “Vai jums ir nepieciešams klienta serveris?”), 0 punkti
Saskaņā ar augstāk esošo tabulu vienkāršākais, ātrākais un tajā pašā laikā ērtākais un jaudīgākais dublēšanas rīks ir BorgBackup. Restičs ieņēma otro vietu, pārējie aplūkotie kandidāti tika izvietoti aptuveni vienādi ar viena vai divu punktu starpību beigās.
Es pateicos visiem, kas izlasīja sēriju līdz galam, aicinu pārrunāt variantus un piedāvāt savus, ja tādi ir. Diskusijas gaitā tabula var tikt paplašināta.
Sērijas rezultāts būs pēdējais raksts, kurā tiks mēģināts izstrādāt ideālu, ātru un pārvaldāmu dublēšanas rīku, kas ļauj pēc iespējas īsākā laikā izvietot atpakaļ kopiju un tajā pašā laikā ērti un vienkārši konfigurēt un uzturēt.
Paziņojums
Dublēšana 6. daļa: Dublēšanas rīku salīdzināšana
Rezerves kopija 7. daļa: Secinājumi
Avots: www.habr.com
