Ĉi tiu artikolo komparos rezervajn ilojn, sed unue vi devus ekscii kiom rapide kaj bone ili traktas restarigi datumojn de sekurkopioj.
Por facileco de komparo, ni konsideros restarigi de plena sekurkopio, precipe ĉar ĉiuj kandidatoj subtenas ĉi tiun operacion. Por simpleco, la nombroj jam estas averaĝigitaj (la aritmetika meznombro de pluraj kuroj). La rezultoj estos resumitaj en tabelo, kiu ankaŭ enhavos informojn pri la kapabloj: la ĉeesto de retinterfaco, facileco de agordo kaj funkciado, la kapablo aŭtomatigi, la ĉeesto de diversaj pliaj funkcioj (ekzemple, kontrolado de integreco de datumoj) , ktp. La grafikaĵoj montros la ŝarĝon sur la servilo, kie la datumoj estos uzataj (ne la servilo por konservi rezervajn kopiojn).
Reakiro de datumoj
rsync kaj tar estos uzataj kiel referencpunkto ekde simplaj skriptoj por fari sekurkopiojn.
Rakonto traktis la testajn datumojn en 4 minutoj kaj 28 sekundoj, montrante
tia ŝarĝo
La reakiro trafis limigon de la disksubsistemo de la rezerva stokadservilo (sgildentaj grafikaĵoj). Vi ankaŭ povas klare vidi la ŝarĝon de unu kerno sen problemoj (malalta iowait kaj softirq - neniuj problemoj kun la disko kaj reto, respektive). Ĉar la aliaj du programoj, nome rdiff-backup kaj rsnapshot, estas bazitaj sur rsync kaj ankaŭ ofertas regulan rsync kiel reakira ilo, ili havos proksimume la saman ŝarĝan profilon kaj rezervan reakiran tempon.
Tar faris ĝin iom pli rapide
2 minutoj kaj 43 sekundoj:
La totala sistema ŝarĝo estis pli alta averaĝe je 20% pro la pliigita softirq - la superkostoj dum la funkciado de la reto subsistemo pliiĝis.
Se la arkivo estas pli kunpremita, la reakiro tempo pliiĝas al 3 minutoj 19 sekundoj.
kun tia ŝarĝo sur la ĉefa servilo (malpakado flanke de la ĉefa servilo):
La malkunpremprocezo okupas ambaŭ procesorajn kernojn ĉar ekzistas du procezoj kurantaj. Ĝenerale, ĉi tio estas la atendata rezulto. Ankaŭ, komparebla rezulto (3 minutoj kaj 20 sekundoj) estis akirita dum rulado de gzip sur la servilflanko kun sekurkopioj; la ŝarĝprofilo sur la ĉefservilo estis tre simila al rulado de gudro sen la gzip-kompresoro (vidu antaŭan grafeon).
В rdiff-rezervo vi povas sinkronigi la lastan sekurkopion, kiun vi faris per regula rsync (la rezultoj estos similaj), sed pli malnovaj sekurkopioj ankoraŭ devas esti restarigitaj per la programo rdiff-backup, kiu kompletigis la restarigon en 17 minutoj kaj 17 sekundoj, montrante
ĉi tiu ŝarĝo:
Eble tio celis, almenaŭ limigi la rapidecon de la aŭtoroj . La procezo de restarigo de rezerva kopio mem prenas iom malpli ol duonon de unu kerno, kun proporcie komparebla agado (t.e. 2-5 fojojn pli malrapida) tra disko kaj reto kun rsync.
Rsnapshot Por reakiro, ĝi sugestas uzi regulan rsync, do ĝiaj rezultoj estos similaj. Ĝenerale, jen kiel ĝi rezultis.
Rukto Mi plenumis la taskon restarigi sekurkopion en 7 minutoj kaj 2 sekundoj kun
kun ĉi tiu ŝarĝo:
Ĝi funkciis sufiĉe rapide, kaj almenaŭ estas multe pli oportuna ol pura rsync: vi ne bezonas memori ajnajn flagojn, simplan kaj intuician kli-interfacon, enkonstruitan subtenon por pluraj kopioj - kvankam ĝi estas duoble pli malrapida. Se vi bezonas restarigi datumojn de la lasta sekurkopio, kiun vi faris, vi povas uzi rsync, kun kelkaj avertoj.
La programo montris proksimume la saman rapidecon kaj ŝarĝon Rezerva komputilo kiam vi ebligas rsync-transigan reĝimon, deplojante la sekurkopion por
7 minutoj kaj 42 sekundoj:
Sed en transiga reĝimo de datumoj, BackupPC traktis gudron pli malrapide: en 12 minutoj kaj 15 sekundoj, la procesoro-ŝarĝo estis ĝenerale pli malalta.
unufoje kaj duono:
Duplikato sen ĉifrado montris iomete pli bonajn rezultojn, restarigante sekurkopion en 10 minutoj kaj 58 sekundoj. Se vi aktivigas ĉifradon per gpg, la reakiro tempo pliiĝas al 15 minutoj kaj 3 sekundoj. Ankaŭ, kiam vi kreas deponejon por stoki kopiojn, vi povas specifi la arkivan grandecon, kiu estos uzata dum disigo de la envenanta datumfluo. Ĝenerale, ĉe konvenciaj malmolaj diskoj, ankaŭ pro la unufadena operacia reĝimo, ne estas multe da diferenco. Ĝi povas aperi ĉe malsamaj blokgrandecoj kiam hibrida stokado estas uzata. La ŝarĝo sur la ĉefa servilo dum reakiro estis jena:
neniu ĉifrado
kun ĉifrado
Duplikato montris kompareblan reakiron, kompletigante ĝin en 13 minutoj kaj 45 sekundoj. Necesis ĉirkaŭ pliaj 5 minutoj por kontroli la ĝustecon de la reakiritaj datumoj (entute ĉirkaŭ 19 minutoj). La ŝarĝo estis
sufiĉe alta:
Kiam aes-ĉifrado estis ebligita interne, la reakiro tempo estis 21 minutoj 40 sekundoj, kun CPU-uzado ĉe ĝia maksimumo (ambaŭ kernoj!) dum reakiro; Dum kontrolado de datumoj, nur unu fadeno estis aktiva, okupante unu procesoran kernon. Kontroli la datumojn post reakiro daŭris la samajn 5 minutojn (preskaŭ 27 minutojn entute).
rezulto
duplicati estis iom pli rapida kun reakiro kiam oni uzis la eksteran gpg-programon por ĉifrado, sed ĝenerale la diferencoj de la antaŭa reĝimo estas minimumaj. La funkciada tempo estis 16 minutoj 30 sekundoj, kun datenkonfirmo en 6 minutoj. La ŝarĝo estis
tia:
AMANDA, uzante gudron, kompletigis ĝin en 2 minutoj 49 sekundoj, kiu, principe, estas tre proksima al regula gudro. Ŝarĝu sur la sistemo principe
la sama:
Dum restarigo de sekurkopio uzante zbackup la sekvaj rezultoj estis akiritaj:
ĉifrado, lzma kunpremado
Kura tempo 11 minutoj kaj 8 sekundoj
AES-ĉifrado, lzma kunpremado
Funkcia tempo 14 minutoj
AES-ĉifrado, lzo-kunpremado
Rultempo 6 minutoj, 19 sekundoj
Ĝenerale, ne malbone. Ĉio dependas de la rapideco de la procesoro sur la rezerva servilo, kiu povas esti klare vidita de la rultempo de la programo kun malsamaj kompresoroj. Sur la rezerva servilflanko, regula gudro estis lanĉita, do se vi komparas ĝin kun ĝi, la reakiro estas 3 fojojn pli malrapida. Eble indas kontroli la funkciadon en multfadena reĝimo, kun pli ol du fadenoj.
BorgBackup en neĉifrita reĝimo ĝi estis iom pli malrapida ol gudro, en 2 minutoj 45 sekundoj, tamen, male al gudro, eblis dedupliki la deponejon. La ŝarĝo montriĝis
jenaj:
Se vi ebligas blake-bazitan ĉifradon, la rezerva reakiro rapideco estas iomete pli malrapida. Reakira tempo en ĉi tiu reĝimo estas 3 minutoj 19 sekundoj, kaj la ŝarĝo malaperis
kiel tio:
AES-ĉifrado estas iomete pli malrapida, reakiro tempo estas 3 minutoj 23 sekundoj, la ŝarĝo estas precipe
ne ŝanĝiĝis:
Ĉar Borg povas funkcii en multfadena reĝimo, la procesoro-ŝarĝo estas maksimuma, kaj kiam pliaj funkcioj estas aktivigitaj, la funkciada tempo simple pliiĝas. Ŝajne, indas esplori multfadenadon simile al zbackup.
Restu traktis la reakiron iom pli malrapide, la funkciada tempo estis 4 minutoj 28 sekundoj. La ŝarĝo aspektis
kiel tia:
Ŝajne la reakiro funkcias en pluraj fadenoj, sed la efikeco ne estas tiel alta kiel tiu de BorgBackup, sed komparebla en tempo al regula rsync.
Kun la helpo de urBackup Eblis restarigi la datumojn en 8 minutoj kaj 19 sekundoj, la ŝarĝo estis
tia:
La ŝarĝo ankoraŭ ne estas tre alta, eĉ pli malalta ol tiu de gudro. En kelkaj lokoj estas eksplodoj, sed ne pli ol la ŝarĝo de unu kerno.
Elekto kaj pravigo de kriterioj por komparo
Kiel dirite en unu el la antaŭaj artikoloj, la rezerva sistemo devas plenumi la jenajn kriteriojn:
- Facileco de uzo
- Versatilidad
- Stabileco
- Rapido
Indas konsideri ĉiun punkton aparte pli detale.
Facileco de operacio
Plej bone estas kiam estas unu butono "Faru ĉion bone", sed se vi revenos al veraj programoj, la plej oportuna afero estos iu konata kaj norma funkcia principo.
Plej multaj uzantoj plej verŝajne estos pli bone se ili ne devos memori amason da ŝlosiloj por cli, agordi amason da malsamaj, ofte malklaraj opcioj per retejo aŭ tui, aŭ agordi sciigojn pri malsukcesa operacio. Ĉi tio ankaŭ inkluzivas la kapablon facile "ĝustigi" rezervan solvon en la ekzistantan infrastrukturon, kaj ankaŭ aŭtomatigon de la rezerva procezo. Ankaŭ ekzistas la ebleco instali uzante pakaĵadministrilon, aŭ en unu aŭ du komandoj kiel "elŝuti kaj malpakigi". curl ссылка | sudo bash - kompleksa metodo, ĉar vi devas kontroli kio alvenas per la ligilo.
Ekzemple, el la kandidatoj konsiderataj, simpla solvo estas burp, rdiff-backup kaj rest, kiuj havas mnemonikajn klavojn por malsamaj operaciumoj. Iomete pli kompleksaj estas borg kaj dupleco. La plej malfacila estis AMANDA. La ceteraj estas ie en la mezo laŭ facileco de uzado. Ĉiukaze, se vi bezonas pli ol 30 sekundojn por legi la uzantmanlibron, aŭ vi bezonas iri al Guglo aŭ alia serĉilo, kaj ankaŭ rulumi tra longa folio de helpo, la decido estas malfacila, unumaniere aŭ alie.
Iuj el la konsiderataj kandidatoj kapablas aŭtomate sendi mesaĝon per retpoŝta mesaĝo, dum aliaj dependas de agorditaj atentigoj en la sistemo. Plie, plej ofte kompleksaj solvoj ne havas tute evidentajn atentajn agordojn. Ĉiukaze, se la rezerva programo produktas ne-nulan revenkodon, kiu estos ĝuste komprenata de la sistema servo por periodaj taskoj (mesaĝo estos sendita al la sistemadministranto aŭ rekte al monitorado) - la situacio estas simpla. Sed se la rezerva sistemo, kiu ne funkcias sur rezerva servilo, ne povas esti agordita, la evidenta maniero diri pri la problemo estas, ke la komplekseco jam estas troa. Ĉiukaze, elsendi avertojn kaj aliajn mesaĝojn nur al la retinterfaco aŭ al la protokolo estas malbona praktiko, ĉar plej ofte ili estos ignoritaj.
Koncerne aŭtomatigon, simpla programo povas legi mediajn variablojn, kiuj fiksas sian operacian reĝimon, aŭ ĝi havas evoluintan kli, kiu povas tute duobligi la konduton kiam oni laboras per interreta interfaco, ekzemple. Ĉi tio ankaŭ inkluzivas la eblecon de kontinua operacio, la haveblecon de ekspansioŝancoj, ktp.
Versatilidad
Parte eĥante la antaŭan subfakon pri aŭtomatigo, ne devus esti speciala problemo "ĝustigi" la rezervan procezon en la ekzistantan infrastrukturon.
Indas rimarki, ke la uzo de ne-normaj havenoj (nu, krom la interreta interfaco) por laboro, la efektivigo de ĉifrado en ne-norma maniero, la interŝanĝo de datumoj per ne-norma protokolo estas signoj de ne-norma protokolo. -universala solvo. Plejparte, ĉiuj kandidatoj havas ilin unumaniere aŭ alian pro la evidenta kialo: simpleco kaj ĉiuflankeco kutime ne iras kune. Kiel escepto - rukto, estas aliaj.
Kiel signo - la kapablo labori uzante regulan ssh.
Laborrapideco
La plej polemika kaj polemika punkto. Unuflanke, ni lanĉis la procezon, ĝi funkciis kiel eble plej rapide kaj ne malhelpis la ĉefajn taskojn. Aliflanke, estas pliiĝo en trafiko kaj procesoro-ŝarĝo dum la rezerva periodo. Ankaŭ indas noti, ke la plej rapidaj programoj por fari kopiojn kutime estas la plej malbonaj laŭ funkcioj gravaj por uzantoj. Denove: se por ricevi unu malfeliĉan tekstdosieron de pluraj dekoj da bajtoj kun pasvorto, kaj pro tio la tuta servo kostas (jes, jes, mi komprenas, ke la rezerva procezo plej ofte ne kulpas ĉi tie), kaj vi devas relegi sinsekve ĉiujn dosierojn en la deponejo aŭ pligrandigi la tutan arkivon - la rezerva sistemo neniam estas rapida. Alia punkto, kiu ofte fariĝas stumblo, estas la rapideco de deploji sekurkopion de arkivo. Estas klara avantaĝo ĉi tie por tiuj, kiuj povas simple kopii aŭ movi dosierojn al la dezirata loko sen multe da manipulado (rsync, ekzemple), sed plej ofte la problemo devas esti solvita en organiza maniero, empirie: per mezurado de la rezerva reakiro. kaj malkaŝe informante uzantojn pri tio.
Stabileco
Oni komprenu tiamaniere: unuflanke, devas esti iel ajn disfaldi la rezervan kopion reen, aliflanke, ĝi devas esti rezistema al diversaj problemoj: interrompo de reto, malfunkcio de disko, forigo de parto de la deponejo.
Komparo de rezerva iloj
Kopiu kreotempo
Kopiu reakiro tempo
Facila instalado
La simpla aranĝo
Simpla uzo
Simpla aŭtomatigo
Ĉu vi bezonas klientservilon?
Kontrolante la integrecon de la deponejo
Diferencaj kopioj
Laborante per tubo
Versatilidad
Sendependeco
Deponejo travidebleco
Ĉifrado
Kunpremo
Dedupliko
Reta interfaco
Plenigante al la nubo
Vindoza subteno
Poentaro
Rakonto
4m15s
4m28s
jes
neniu
neniu
neniu
jes
neniu
neniu
jes
neniu
jes
jes
neniu
neniu
neniu
neniu
neniu
jes
6
Tar
pura
3m12s
2m43s
jes
neniu
neniu
neniu
neniu
neniu
jes
jes
neniu
jes
neniu
neniu
neniu
neniu
neniu
neniu
jes
8,5
gzip
9m37s
3m19s
jes
Rdiff-rezervo
16m26s
17m17s
jes
jes
jes
jes
jes
neniu
jes
neniu
jes
neniu
jes
neniu
jes
jes
jes
neniu
jes
11
Rsnapshot
4m19s
4m28s
jes
jes
jes
jes
neniu
neniu
jes
neniu
jes
neniu
jes
neniu
neniu
jes
jes
neniu
jes
12,5
Rukto
11m9s
7m2s
jes
neniu
jes
jes
jes
jes
jes
neniu
jes
jes
neniu
neniu
jes
neniu
jes
neniu
jes
10,5
Duplikato
neniu ĉifrado
16m48s
10m58s
jes
jes
neniu
jes
neniu
jes
jes
neniu
neniu
jes
neniu
jes
jes
neniu
jes
neniu
jes
11
gpg
17m27s
15m3s
Duplikato
neniu ĉifrado
20m28s
13m45s
neniu
jes
neniu
neniu
neniu
jes
jes
neniu
neniu
jes
neniu
jes
jes
jes
jes
jes
jes
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
neniu ĉifrado
40m3s
11m8s
jes
jes
neniu
neniu
neniu
jes
jes
jes
neniu
jes
neniu
jes
jes
jes
neniu
neniu
neniu
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
neniu ĉifrado
4m7s
2m45s
jes
jes
jes
jes
jes
jes
jes
jes
jes
jes
neniu
jes
jes
jes
jes
neniu
jes
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restu
5m38s
4m28s
jes
jes
jes
jes
neniu
jes
jes
jes
jes
jes
neniu
jes
neniu
jes
neniu
jes
jes
15,5
urBackup
8m21s
8m19s
jes
jes
jes
neniu
jes
neniu
jes
neniu
jes
jes
neniu
jes
jes
jes
jes
neniu
jes
12
amanda
9m3s
2m49s
jes
neniu
neniu
jes
jes
jes
jes
neniu
jes
jes
jes
jes
jes
neniu
jes
jes
jes
13
Rezerva komputilo
rsync
12m22s
7m42s
jes
neniu
jes
jes
jes
jes
jes
neniu
jes
neniu
neniu
jes
jes
neniu
jes
neniu
jes
10,5
gudro
12m34s
12m15s
Legendo de la tabelo:
- Verda, funkciada tempo malpli ol kvin minutoj, aŭ respondu "Jes" (krom la kolumno "Bezonas klientservilon?"), 1 poento
- Flava, mastruma tempo kvin ĝis dek minutoj, 0.5 poentoj
- Ruĝa, la labortempo estas pli ol dek minutoj, aŭ la respondo estas "Ne" (krom la kolumno "Ĉu vi bezonas klientservilon?"), 0 poentoj
Laŭ la supra tabelo, la plej simpla, plej rapida, kaj samtempe oportuna kaj potenca rezerva ilo estas BorgBackup. Restic okupis la duan lokon, la ceteraj konsiderataj kandidatoj estis poziciigitaj proksimume egale kun disvastiĝo de unu aŭ du poentoj ĉe la fino.
Mi dankas ĉiujn, kiuj legis la serion ĝis la fino, mi invitas vin diskuti la eblojn kaj proponi viajn proprajn, se ekzistas. Dum la diskuto progresas, la tablo povas esti vastigita.
La rezulto de la serio estos la fina artikolo, en kiu estos provo evoluigi idealan, rapidan kaj regeblan rezervan ilon, kiu ebligas al vi disfaldi kopion reen en la plej mallonga ebla tempo kaj samtempe esti oportuna kaj facila. agordi kaj konservi.
Anonco
Rezerva Parto 6: Komparante Rezervaj Iloj
Rezerva Parto 7: Konkludoj
fonto: www.habr.com