Ĉi tiu artikolo konsideros rezervan programaron, kiu, rompante la datumfluon en apartajn komponentojn (pecoj), formas deponejon.
Deponejoj povas esti plu kunpremitaj kaj ĉifritaj, kaj plej grave - dum ripetaj rezervaj procezoj - reuzitaj.
Rezerva kopio en tia deponejo estas nomita ĉeno de komponantoj ligitaj unu al la alia, ekzemple, bazita sur diversaj hash-funkcioj.
Estas pluraj similaj solvoj, mi koncentriĝos pri 3: zbackup, borgbackup kaj restic.
Atenditaj rezultoj
Ĉar ĉiuj kandidatoj postulas la kreadon de deponejo laŭ unu maniero aŭ alia, unu el la plej gravaj faktoroj estos taksi la grandecon de la deponejo. Ideale, ĝia grandeco devus esti ne pli ol 13 GB laŭ la akceptita metodaro, aŭ eĉ malpli - kondiĉigita de bona optimumigo.
Ankaŭ estas tre dezirinde povi krei rezervajn kopiojn de dosieroj rekte, sen uzi arkivilojn kiel tar, kaj ankaŭ labori kun ssh/sftp sen pliaj iloj kiel rsync kaj sshfs.
Konduto dum kreado de sekurkopioj:
- La grandeco de la deponejo estos egala al la grandeco de la ŝanĝoj, aŭ malpli.
- Peza CPU-ŝarĝo estas atendata kiam oni uzas kunpremadon kaj/aŭ ĉifradon, kaj sufiĉe alta reto kaj disko-ŝarĝo verŝajne se la arkivado kaj/aŭ ĉifrada procezo funkcias sur rezerva stokadservilo.
- Se la deponejo estas difektita, probable prokrasta eraro kaj kiam oni kreas novajn sekurkopiojn kaj kiam oni provas restarigi. Necesas plani pliajn mezurojn por certigi la integrecon de la deponejo aŭ uzi enkonstruitajn ilojn por kontroli ĝian integrecon.
Labori kun gudro estas prenita kiel referenca valoro, kiel montriĝis en unu el la antaŭaj artikoloj.
Testante zbackup
La ĝenerala mekanismo de zbackup estas, ke la programo trovas en la eniga datumfluo areoj enhavantaj la samajn datumojn, tiam laŭvole kunpremas kaj ĉifras ilin, savante ĉiun areon nur unufoje.
Deduplikado uzas 64-bitan ringan hash-funkcion kun glita fenestro por kontroli bito-post-bajtajn matĉojn kontraŭ ekzistantaj datumblokoj (simila al kiel rsync efektivigas ĝin).
Plurfadenaj lzma kaj lzo estas uzataj por kunpremado, kaj aes por ĉifrado. La plej novaj versioj havas la kapablon forigi malnovajn datumojn de la deponejo estonte.
La programo estas skribita en C++ kun minimumaj dependecoj. La aŭtoro ŝajne inspiriĝis de la Unikso-maniero, do la programo akceptas datumojn pri stdin dum kreado de sekurkopioj, produktante similan datumfluon sur stdout dum restarigo. Tiel, zbackup povas esti uzata kiel tre bona "konstrubriketo" kiam vi verkas viajn proprajn rezervajn solvojn. Ekzemple, la aŭtoro de la artikolo uzis ĉi tiun programon kiel la ĉefan rezervan ilon por hejmaj maŝinoj ekde proksimume 2014.
La datumfluo estos regula gudro krom se alie dirite.
Ni vidu, kiaj estas la rezultoj:
La laboro estis kontrolita en 2 opcioj:
- deponejo estas kreita kaj zbackup estas lanĉita sur la servilo kun la fontaj datumoj, tiam la enhavo de la deponejo estas transdonita al la rezerva stokadservilo.
- deponejo estas kreita sur la rezerva stokadservilo, zbackup estas lanĉita per ssh sur la rezerva stokadservilo, kaj datumoj estas senditaj al ĝi per pipo.
La rezultoj de la unua opcio estis jenaj: 43m11s - kiam oni uzas neĉifritan deponejon kaj la lzma kompresoron, 19m13s - kiam oni anstataŭigas la kompresoron per lzo.
La ŝarĝo sur la servilo kun la originaj datumoj estis kiel sekvas (ekzemplo kun lzma estas montrita; kun lzo estis proksimume la sama bildo, sed la parto de rsync estis proksimume kvarono de la tempo):
Estas klare, ke tia rezerva procezo taŭgas nur por relative maloftaj kaj malgrandaj ŝanĝoj. Ankaŭ estas tre konsilinde limigi zbackup al 1 fadeno, alie estos tre alta CPU-ŝarĝo, ĉar La programo tre bonas labori en pluraj fadenoj. La ŝarĝo sur la disko estis malgranda, kio ĝenerale ne estus rimarkebla kun moderna ssd-bazita disksubsistemo. Vi ankaŭ povas klare vidi la komencon de la procezo sinkronigi deponejajn datumojn al fora servilo; la rapideco de operacio estas komparebla al regula rsync kaj dependas de la agado de la disksubsistemo de la rezerva stokadservilo. La malavantaĝo de ĉi tiu aliro estas la stokado de loka deponejo kaj, kiel rezulto, duobligo de datumoj.
Pli interesa kaj aplikebla praktike estas la dua opcio, kurante zbackup rekte sur la rezerva stokadservilo.
Unue, ni testos la operacion sen uzi ĉifradon kun la lzma kompresoro:
Kura tempo de ĉiu provo:
Lanĉo 1
Lanĉo 2
Lanĉo 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Se vi ebligas ĉifradon per aes, la rezultoj estas sufiĉe proksimaj:
Funkcia tempo sur la samaj datumoj, kun ĉifrado:
Lanĉo 1
Lanĉo 2
Lanĉo 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Se ĉifrado estas kombinita kun kunpremado uzante lzo, ĝi aspektas jene:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
La grandeco de la rezulta deponejo estis relative la sama ĉe 13GB. Ĉi tio signifas, ke maldupliko funkcias ĝuste. Ankaŭ, sur jam kunpremitaj datumoj, uzi lzo donas rimarkindan efikon; laŭ totala funkciada tempo, zbackup proksimiĝas al duobleco/dupliko, sed postrestas post tiuj bazitaj sur librsync je 2-5 fojojn.
La avantaĝoj estas evidentaj - ŝparado de diskospaco sur la rezerva stokadservilo. Koncerne al deponejaj kontrolaj iloj, la aŭtoro de zbackup ne provizas ilin; oni rekomendas uzi mistoleran diskon aŭ nuban provizanton.
Ĝenerale, tre bona impreso, malgraŭ tio, ke la projekto restas senmova de ĉirkaŭ 3 jaroj (la lasta peto pri funkcioj estis antaŭ ĉirkaŭ unu jaro, sed sen respondo).
Testante borgbackup
Borgbackup estas forko de subtegmento, alia sistemo simila al zbackup. Skribita en python, ĝi havas liston de kapabloj similaj al zbackup, sed aldone povas:
- Muntu sekurkopiojn per fuzeo
- Kontrolu la enhavon de deponejo
- Laboru en kliento-servila reĝimo
- Uzu diversajn kompresorojn por datumoj, kaj ankaŭ heŭristikan determinon de la dosiertipo dum kunpremado de ĝi.
- 2 ĉifradaj opcioj, aes kaj blake
- Enkonstruita ilo por
agadokontroloj
borgbackup benchmark crud ssh://backup_server/repo/path loka_dir
La rezultoj estis kiel sekvas:
CZ-BIG 96.51 MB/s (10 100.00 MB tute nulaj dosieroj: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB tute nulaj dosieroj: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB tute nulaj dosieroj: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB tute nulaj dosieroj: 2.85s)
CR-GRANDA 34.30 MB/s (10 100.00 MB hazardaj dosieroj: 29.15s)
RR-GRANDA 60.69 MB/s (10 100.00 MB hazardaj dosieroj: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB hazardaj dosieroj: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB hazardaj dosieroj: 13.77s)
CZ-MEDIA 108.59 MB/s (1000 1.00 MB tute nulaj dosieroj: 9.21s)
RZ-MEDIA 76.16 MB/s (1000 1.00 MB tute nulaj dosieroj: 13.13s)
UZ-MEDIA 331.27 MB/s (1000 1.00 MB tute nulaj dosieroj: 3.02s)
DZ-MEDIA 387.36 MB/s (1000 1.00 MB tute nulaj dosieroj: 2.58s)
CR-MEDIA 37.80 MB/s (1000 1.00 MB hazardaj dosieroj: 26.45s)
RR-MEDIA 68.90 MB/s (1000 1.00 MB hazardaj dosieroj: 14.51s)
UR-MEDIA 347.24 MB/s (1000 1.00 MB hazardaj dosieroj: 2.88s)
DR-MEDIA 48.80 MB/s (1000 1.00 MB hazardaj dosieroj: 20.49s)
CZ-Malgranda 11.72 MB/s (10000 10.00 kB tute-nulaj dosieroj: 8.53s)
RZ-Malgranda 32.57 MB/s (10000 10.00 kB tute-nulaj dosieroj: 3.07s)
UZ-Malgranda 19.37 MB/s (10000 10.00 kB tute-nulaj dosieroj: 5.16s)
DZ-Malgranda 33.71 MB/s (10000 10.00 kB tute-nulaj dosieroj: 2.97s)
CR-Malgranda 6.85 MB/s (10000 10.00 kB hazardaj dosieroj: 14.60s)
RR-Malgranda 31.27 MB/s (10000 10.00 kB hazardaj dosieroj: 3.20s)
UR-Malgranda 12.28 MB/s (10000 10.00 kB hazardaj dosieroj: 8.14s)
DR-Malgranda 18.78 MB/s (10000 10.00 kB hazardaj dosieroj: 5.32s)
Dum testado, kunprema heŭristiko estos uzata por determini la dosiertipo (aŭtomata kunpremado), kaj la rezultoj estos jenaj:
Unue, ni kontrolu kiel ĝi funkcias sen ĉifrado:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Se vi ebligas deponejan rajtigon (aŭtentikigitan reĝimon), la rezultoj estos proksimaj:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Kiam aes-ĉifrado estis aktivigita, la rezultoj ne multe plimalboniĝis:
Lanĉo 1
Lanĉo 2
Lanĉo 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Kaj se vi ŝanĝas aes al blake, la situacio tute plibonigos:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Kiel en la kazo de zbackup, la deponejo estis 13GB kaj eĉ iomete malpli, kio estas ĝenerale atendata. Mi estis tre kontenta pri la rultempo; ĝi estas komparebla al solvoj bazitaj sur librsync, provizante multe pli larĝajn kapablojn. Mi ankaŭ ĝojis pri la kapablo agordi diversajn parametrojn per medio-variabloj, kio donas tre gravan avantaĝon kiam oni uzas borgbackup en aŭtomata reĝimo. Mi ankaŭ ĝojis pri la ŝarĝo dum sekurkopio: se juĝante laŭ la procesoroŝarĝo, borgbackup funkcias en 1 fadeno.
Ne estis apartaj malavantaĝoj dum ĝi uzis.
ripoza testado
Malgraŭ tio, ke restaĵo estas sufiĉe nova solvo (la unuaj 2 kandidatoj estis konataj jam en 2013 kaj pli), ĝi havas sufiĉe bonajn trajtojn. Skribita en Go.
Kompare kun zbackup, ĝi krome donas:
- Kontrolante la integrecon de la deponejo (inkluzive de kontrolo en partoj).
- Grandega listo de subtenataj protokoloj kaj provizantoj por stoki sekurkopiojn, kaj ankaŭ subtenon por rclone - rsync por nubaj solvoj.
- Komparante 2 sekurkopiojn unu kun la alia.
- Munti la deponejon per fuzeo.
Ĝenerale, la listo de funkcioj estas sufiĉe proksima al borgbackup, en kelkaj lokoj pli, en aliaj malpli. Unu el la trajtoj estas, ke ne ekzistas maniero malŝalti ĉifradon, kaj tial rezervaj kopioj ĉiam estos ĉifritaj. Ni vidu praktike, kio povas esti elpremita el ĉi tiu programaro:
La rezultoj estis kiel sekvas:
Laboraj horoj:
Lanĉo 1
Lanĉo 2
Lanĉo 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
La rezultaj rezultoj ankaŭ estas kompareblaj al rsync-bazitaj solvoj kaj, ĝenerale, tre proksimaj al borgbackup, sed la CPU-ŝarĝo estas pli alta (multoblaj fadenoj kuras) kaj segildento.
Plej verŝajne, la programo estas limigita de la agado de la disksubsistemo sur la datuma stokado-servilo, kiel jam okazis kun rsync. La grandeco de deponejo estis 13GB, same kiel zbackup aŭ borgbackup, ne estis evidentaj malavantaĝoj dum uzado de ĉi tiu solvo.
Результаты
Fakte ĉiuj kandidatoj atingis similajn rezultojn, sed je malsamaj prezoj. Borgbackup funkciis plej bone, restic estis iom pli malrapida, zbackup verŝajne ne indas komenci uzi,
kaj se ĝi jam estas uzata, provu ŝanĝi ĝin al borgbackup aŭ resttic.
trovoj
La plej promesplena solvo ŝajnas esti maltrankvila, ĉar... estas li, kiu havas la plej bonan rilatumon de kapabloj al operacia rapideco, sed ni ne rapidu al ĝeneralaj konkludoj nuntempe.
Borgbackup esence ne estas pli malbona, sed zbackup verŝajne estas pli bone anstataŭigita. Vere, zbackup ankoraŭ povas esti uzata por certigi, ke la regulo 3-2-1 funkcias. Ekzemple, krom (lib)rsync-bazitaj rezerva instalaĵoj.
Anonco
Rezerva Parto 5: Testado de bacula kaj veeam sekurkopio por Linukso
Rezerva Parto 6: Komparante Rezervaj Iloj
Rezerva Parto 7: Konkludoj
Afiŝita de: Paŭlo Demkoviĉ
fonto: www.habr.com