ProHoster > Blogs > Administrācija > DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

Šajā rakstā tiks apskatīta rezerves programmatūra, kas, sadalot datu straumi atseviŔķos komponentos (gabalos), veido repozitoriju.

Repozitorija komponentus var vēl vairāk saspiest un Å”ifrēt, un pats galvenais - atkārtotu dublÄ“Å”anas procesu laikā - izmantot atkārtoti.

Rezerves kopija Ŕādā repozitorijā ir nosaukta komponentu ķēde, kas savienota viena ar otru, piemēram, pamatojoties uz dažādām jaucējfunkcijām.

Ir vairāki lÄ«dzÄ«gi risinājumi, es koncentrÄ“Å”os uz 3: zbackup, borgbackup un restic.

Gaidāmie rezultāti

Tā kā visiem pretendentiem vienā vai otrā veidā ir nepiecieÅ”ams izveidot repozitoriju, viens no svarÄ«gākajiem faktoriem bÅ«s repozitorija lieluma aplēse. Ideālā gadÄ«jumā tā lielumam jābÅ«t ne lielākam par 13 GB saskaņā ar pieņemto metodiku vai pat mazākam - ar labu optimizāciju.

Ä»oti vēlams ir arÄ« iespēja izveidot failu rezerves kopijas tieÅ”i, neizmantojot arhivētājus, piemēram, tar, kā arÄ« strādāt ar ssh/sftp bez papildu rÄ«kiem, piemēram, rsync un sshfs.

Rīcība, veidojot dublējumus:

  1. Repozitorija lielums būs vienāds ar izmaiņu lielumu vai mazāks.
  2. Lietojot saspieÅ”anu un/vai Å”ifrÄ“Å”anu, ir paredzama liela CPU slodze, un, ja arhivÄ“Å”anas un/vai Å”ifrÄ“Å”anas process darbojas rezerves krātuves serverÄ«, ir iespējama diezgan liela tÄ«kla un diska slodze.
  3. Ja repozitorijs ir bojāts, iespējama aizkavēta kļūda gan veidojot jaunus dublējumus, gan mēģinot atjaunot. Ir nepiecieÅ”ams plānot papildu pasākumus, lai nodroÅ”inātu repozitorija integritāti vai izmantot iebÅ«vētos rÄ«kus tās integritātes pārbaudei.

Darbs ar darvu tiek ņemts par atsauces vērtÄ«bu, kā parādÄ«ts vienā no iepriekŔējiem rakstiem.

Zbackup testēŔana

Vispārējais zbackup mehānisms ir tāds, ka programma ievades datu straumē atrod apgabalus, kuros ir tie paÅ”i dati, pēc tam tos pēc izvēles saspiež un Å”ifrē, katru apgabalu saglabājot tikai vienu reizi.

Dedublikācija izmanto 64 bitu gredzena jaucējfunkciju ar bÄ«dāmu logu, lai pārbaudÄ«tu, vai baits pa baitam atbilst esoÅ”ajiem datu blokiem (lÄ«dzÄ«gi tam, kā rsync to ievieÅ”).

SaspieÅ”anai tiek izmantoti daudzpavedienu lzma un lzo, bet Å”ifrÄ“Å”anai - aes. Jaunākajās versijās ir iespēja dzēst vecos datus no repozitorija nākotnē.
Programma ir uzrakstÄ«ta C++ valodā ar minimālām atkarÄ«bām. Autors acÄ«mredzot iedvesmojies no unix-way, tāpēc programma, veidojot dublējumus, pieņem datus par stdin, atjaunojot, veidojot lÄ«dzÄ«gu datu straumi stdout. Tādējādi zbackup var izmantot kā ļoti labu ā€œveidoÅ”anas blokuā€, rakstot savus rezerves risinājumus. Piemēram, raksta autors ir izmantojis Å”o programmu kā galveno mājas maŔīnu dublÄ“Å”anas rÄ«ku kopÅ” aptuveni 2014. gada.

Datu straume būs parasta darva, ja vien nav norādīts citādi.

Apskatīsim, kādi ir rezultāti:

Darbs tika pārbaudīts 2 variantos:

  1. tiek izveidots repozitorijs un serverī ar avota datiem tiek palaists zbackup, pēc tam repozitorija saturs tiek pārsūtīts uz rezerves krātuves serveri.
  2. rezerves krātuves serverī tiek izveidota repozitorija, dublējuma krātuves serverī caur ssh tiek palaists zbackup, un dati uz to tiek nosūtīti pa cauruli.

Pirmā varianta rezultāti bija Ŕādi: 43m11s - izmantojot neÅ”ifrētu repozitoriju un lzma kompresoru, 19m13s - kompresoru nomainot pret lzo.

Servera slodze ar sākotnējiem datiem bija Ŕāda (parādās piemērs ar lzma; ar lzo bija aptuveni tāda pati bilde, bet rsync daļa bija aptuveni ceturtā daļa laika):

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

Skaidrs, ka Ŕāds dublÄ“Å”anas process ir piemērots tikai salÄ«dzinoÅ”i retām un nelielām izmaiņām. Ir arÄ« ļoti ieteicams ierobežot zbackup lÄ«dz 1 pavedienam, pretējā gadÄ«jumā bÅ«s ļoti liela CPU slodze, jo Programma ļoti labi var strādāt vairākos pavedienos. Noslogojums uz diska bija mazs, kas kopumā nebÅ«tu manāms ar modernu ssd bāzes disku apakÅ”sistēmu. Varat arÄ« skaidri redzēt repozitorija datu sinhronizÄ“Å”anas procesa sākumu ar attālo serveri; darbÄ«bas ātrums ir salÄ«dzināms ar parasto rsync un ir atkarÄ«gs no rezerves krātuves servera diska apakÅ”sistēmas veiktspējas. Å Ä«s pieejas trÅ«kums ir lokālas repozitorija glabāŔana un lÄ«dz ar to datu dublÄ“Å”anās.

Interesantāka un praksē pielietojamāka ir otrā iespēja, palaižot zbackup tieÅ”i rezerves krātuves serverÄ«.

Pirmkārt, mēs pārbaudÄ«sim darbÄ«bu, neizmantojot Å”ifrÄ“Å”anu ar lzma kompresoru:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

Katra testa brauciena ilgums:

Palaist 1
Palaist 2
Palaist 3

39m45
40m20
40m3

7m36
8m3
7m48

15m35
15m48
15m38

Ja iespējojat Å”ifrÄ“Å”anu, izmantojot Aes, rezultāti ir diezgan tuvu:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

Darbības laiks ar tiem paŔiem datiem, ar ŔifrēŔanu:

Palaist 1
Palaist 2
Palaist 3

43m40
44m12
44m3

8m3
8m15
8m12

15m0
15m40
15m25

Ja Å”ifrÄ“Å”ana tiek apvienota ar saspieÅ”anu, izmantojot lzo, tas izskatās Ŕādi:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

stundas:

Palaist 1
Palaist 2
Palaist 3

18m2
18m15
18m12

5m13
5m24
5m20

8m48
9m3
8m51

IegÅ«tās repozitorija lielums bija salÄ«dzinoÅ”i vienāds ar 13 GB. Tas nozÄ«mē, ka dublÄ“Å”ana darbojas pareizi. ArÄ« uz jau saspiestiem datiem lzo izmantoÅ”ana dod manāmu efektu, kopējā darbÄ«bas laika ziņā zbackup pietuvojas duplicity/dublicati, bet atpaliek no tiem, kuru pamatā ir librsync 2-5 reizes.

PriekÅ”rocÄ«bas ir acÄ«mredzamas ā€“ diska vietas ietaupÄ«Å”ana rezerves krātuves serverÄ«. Kas attiecas uz repozitoriju pārbaudes rÄ«kiem, tad zbackup autors tos nenodroÅ”ina, ieteicams izmantot kļūdu izturÄ«gu disku masÄ«vu vai mākoņa nodroÅ”inātāju.

Kopumā ļoti labs iespaids, neskatoties uz to, ka projekts stāv uz vietas kādus 3 gadus (pēdējais funkcijas pieprasījums bija apmēram pirms gada, bet bez atbildes).

Borgbackup pārbaude

Borgbackup ir bēniņu dakÅ”a, cita sistēma, kas lÄ«dzÄ«ga zbackup. RakstÄ«ts python, tajā ir zbackup lÄ«dzÄ«gu iespēju saraksts, taču papildus var:

  • Uzstādiet rezerves kopijas, izmantojot droÅ”inātāju
  • Pārbaudiet repozitorija saturu
  • Darbs klienta-servera režīmā
  • Datiem izmantojiet dažādus kompresorus, kā arÄ« faila tipa heiristisku noteikÅ”anu, to saspiežot.
  • 2 Å”ifrÄ“Å”anas iespējas, aes un blake
  • IebÅ«vēts rÄ«ks priekÅ”

veiktspējas pārbaudes

borgbackup etalons crud ssh://backup_server/repo/path local_dir

Rezultāti bija Ŕādi:

C-Z-BIG 96.51 MB/s (10 100.00 MB nulles faili: 10.36 s)
R-Z-BIG 57.22 MB/s (10 100.00 MB nulles faili: 17.48 s)
U-Z-BIG 253.63 MB/s (10 100.00 MB nulles faili: 3.94 s)
D-Z-BIG 351.06 MB/s (10 100.00 MB nulles faili: 2.85 s)
C-R-BIG 34.30 MB/s (10 100.00 MB nejauÅ”i faili: 29.15 s)
R-R-BIG 60.69 MB/s (10 100.00 MB nejauÅ”i faili: 16.48 s)
U-R-BIG 311.06 MB/s (10 100.00 MB nejauÅ”i faili: 3.21 s)
D-R-BIG 72.63 MB/s (10 100.00 MB nejauÅ”i faili: 13.77 s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB nulles faili: 9.21 s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB nulles faili: 13.13 s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB nulles faili: 3.02 s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB nulles faili: 2.58 s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB nejauÅ”i faili: 26.45 s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB nejauÅ”i faili: 14.51 s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB nejauÅ”i faili: 2.88 s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB nejauÅ”i faili: 20.49 s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB nulles faili: 8.53 s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB nulles faili: 3.07 s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB nulles faili: 5.16 s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB nulles faili: 2.97 s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB nejauÅ”i faili: 14.60 s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB nejauÅ”i faili: 3.20 s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB nejauÅ”i faili: 8.14 s)
D-R-SMALL 18.78 MB/s (10000 XNUMX 10.00 kB nejauÅ”i faili: 5.32 s)

Pārbaudes laikā faila veida noteikŔanai tiks izmantota saspieŔanas heiristika (automātiskā saspieŔana), un rezultāti būs Ŕādi:

Vispirms pārbaudÄ«sim, kā tas darbojas bez Å”ifrÄ“Å”anas:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

stundas:

Palaist 1
Palaist 2
Palaist 3

4m6
4m10
4m5

56s
58s
54s

1m26
1m34
1m30

Ja iespējosit repozitorija autorizāciju (autentificēts režīms), rezultāti būs tuvu:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

stundas:

Palaist 1
Palaist 2
Palaist 3

4m11
4m20
4m12

1m0
1m3
1m2

1m30
1m34
1m31

Kad tika aktivizēta AES Å”ifrÄ“Å”ana, rezultāti Ä«paÅ”i nepasliktinājās:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

Palaist 1
Palaist 2
Palaist 3

4m55
5m2
4m58

1m0
1m2
1m0

1m49
1m50
1m50

Un, ja jūs nomainīsit aes uz Blake, situācija pilnībā uzlabosies:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

stundas:

Palaist 1
Palaist 2
Palaist 3

4m33
4m43
4m40

59s
1m0
1m0

1m38
1m43
1m40

Tāpat kā zbackup gadÄ«jumā, repozitorija lielums bija 13 GB un pat nedaudz mazāks, kas parasti tiek gaidÄ«ts. Es biju ļoti apmierināts ar darbÄ«bas laiku, tas ir salÄ«dzināms ar risinājumiem, kuru pamatā ir librsync, nodroÅ”inot daudz plaŔākas iespējas. Mani iepriecināja arÄ« iespēja iestatÄ«t dažādus parametrus caur vides mainÄ«gajiem, kas dod ļoti nopietnas priekÅ”rocÄ«bas, izmantojot borgbackup automātiskajā režīmā. Mani iepriecināja arÄ« noslodze dublÄ“Å”anas laikā: spriežot pēc procesora slodzes, borgbackup darbojas 1 pavedienā.

Lietojot, nebija īpaŔu trūkumu.

restic testēŔana

Neskatoties uz to, ka restic ir diezgan jauns risinājums (pirmie 2 kandidāti bija zināmi jau 2013. gadā un vecāki), tam ir diezgan labas īpaŔības. Rakstīts Go.

Salīdzinot ar zbackup, tas papildus sniedz:

  • Repozitorija integritātes pārbaude (ieskaitot pārbaudi pa daļām).
  • MilzÄ«gs atbalstÄ«to protokolu un pakalpojumu sniedzēju saraksts dublējumu glabāŔanai, kā arÄ« atbalsts rclone - rsync mākoņrisinājumiem.
  • SalÄ«dzinot 2 dublējumus savā starpā.
  • Krātuves montāža, izmantojot droÅ”inātāju.

Kopumā funkciju saraksts ir diezgan tuvu borgbackup, vietām vairāk, citur mazāk. Viena no funkcijām ir tāda, ka nav iespējams atspējot Å”ifrÄ“Å”anu, un tāpēc rezerves kopijas vienmēr tiks Å”ifrētas. ApskatÄ«sim praksē, ko var izspiest no Ŕīs programmatÅ«ras:

Rezultāti bija Ŕādi:

DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana

stundas:

Palaist 1
Palaist 2
Palaist 3

5m25
5m50
5m38

35s
38s
36s

1m54
2m2
1m58

Veiktspējas rezultāti ir salīdzināmi arī ar risinājumiem, kuru pamatā ir rsync, un kopumā ļoti tuvu borgbackup, taču CPU slodze ir lielāka (darbojas vairāki pavedieni) un zāģa zobs.

Visticamāk, programmu ierobežo diska apakÅ”sistēmas veiktspēja datu uzglabāŔanas serverÄ«, kā tas jau bija rsync gadÄ«jumā. Repozitorija izmērs bija 13 GB, tāpat kā zbackup vai borgbackup, lietojot Å”o risinājumu, nebija acÄ«mredzamu trÅ«kumu.

rezultātus

Faktiski visi kandidāti sasniedza līdzīgus rezultātus, taču par dažādām cenām. Borgbackup darbojās vislabāk, restic bija nedaudz lēnāks, iespējams, zbackup nav vērts sākt lietot,
un, ja tas jau tiek izmantots, mēģiniet to mainīt uz borgbackup vai restic.

Atzinumi

VisdaudzsoloŔākais risinājums Ŕķiet atturÄ«gs, jo... tieÅ”i viņam ir vislabākā spēju attiecÄ«ba pret darbÄ«bas ātrumu, taču pagaidām nesteigsimies ar vispārÄ«giem secinājumiem.

Borgbackup bÅ«tÄ«bā nav sliktāks, taču zbackup, iespējams, ir labāk aizstāt. Tiesa, zbackup joprojām var izmantot, lai nodroÅ”inātu 3-2-1 noteikuma darbÄ«bu. Piemēram, papildus uz (lib)rsync balstÄ«tām dublÄ“Å”anas iespējām.

Paziņojums

DublÄ“Å”ana, 1. daļa: Kāpēc nepiecieÅ”ama dublÄ“Å”ana, metožu, tehnoloÄ£iju pārskats
DublÄ“Å”ana 2. daļa: Uz rsync balstÄ«tu dublÄ“Å”anas rÄ«ku pārskatÄ«Å”ana un testÄ“Å”ana
Dublējuma 3. daļa: Dublitātes pārbaude un pārbaude, dublikāti
DublÄ“Å”ana 4. daļa: zbackup, restic, borgbackup pārskatÄ«Å”ana un testÄ“Å”ana
DublÄ“Å”ana 5. daļa: bacula un veeam dublējuma testÄ“Å”ana operētājsistēmai Linux
DublÄ“Å”ana 6. daļa: DublÄ“Å”anas rÄ«ku salÄ«dzināŔana
Rezerves kopija 7. daļa: Secinājumi

Ievietoja: Pāvels Demkovičs

Avots: www.habr.com

Pievieno komentāru