Dit artikel sil backup-ark fergelykje, mar earst moatte jo útfine hoe fluch en goed se omgean mei it herstellen fan gegevens fan backups.
Foar gemak fan ferliking, wy sille beskôgje it weromsette fan in folsleine reservekopy, foaral om't alle kandidaten stypje dizze modus fan wurking. Foar ienfâld, de nûmers binne al gemiddeld (it rekenkundige gemiddelde fan ferskate runs). De resultaten wurde gearfette yn in tabel, dy't ek ynformaasje sil befetsje oer de mooglikheden: de oanwêzigens fan in webynterface, gemak fan opset en operaasje, de mooglikheid om te automatisearjen, de oanwêzigens fan ferskate ekstra funksjes (bygelyks kontrolearjen fan gegevensintegriteit) , ensfh. De grafiken sille de lading sjen litte op 'e server wêr't de gegevens sille wurde brûkt (net de server foar it bewarjen fan reservekopyen).
Data weromhelje
rsync en tar wurde brûkt as referinsjepunt sûnt ienfâldige skripts foar it meitsjen fan reservekopyen.
rsync omgean mei de test gegevens set yn 4 minuten en 28 sekonden, showing
sa'n lêst
It herstelproses rekke in beheining fan it skiifsubsysteem fan 'e reservekopy-opslachtsjinner (sawtooth-grafiken). Jo kinne ek dúdlik sjen it laden fan ien kernel sûnder problemen (lege iowait en softirq - gjin problemen mei de skiif en netwurk, respektivelik). Sûnt de oare twa programma, nammentlik rdiff-backup en rsnapshot, binne basearre op rsync en ek biede reguliere rsync as in herstel ark, se sille hawwe likernôch itselde load profyl en reservekopy hersteltiid.
Tarre krige it wat flugger dien
2 minuten en 43 sekonden:
De totale systeembelêsting wie gemiddeld 20% heger troch de ferhege softirq - de overheadkosten tidens de wurking fan it netwurksubsysteem tanommen.
As it argyf fierder komprimearre wurdt, nimt de hersteltiid ta 3 minuten 19 sekonden.
mei sa'n lading op 'e haadtsjinner (útpakke oan' e kant fan 'e haadtsjinner):
It dekompresjeproses nimt beide prosessorkearnen op, om't d'r twa prosessen rinne. Yn 't algemien is dit it ferwachte resultaat. Ek waard in fergelykber resultaat (3 minuten en 20 sekonden) krigen by it útfieren fan gzip oan 'e serverkant mei backups; it loadprofyl op 'e haadtsjinner wie tige ferlykber mei it útfieren fan tar sûnder de gzip-kompressor (sjoch foarige grafyk).
В rdiff-backup jo kinne de lêste reservekopy dy't jo makke hawwe syngronisearje mei gewoane rsync (de resultaten sille ferlykber wêze), mar âldere reservekopyen moatte noch weromset wurde mei it rdiff-backupprogramma, dat de restauraasje yn 17 minuten en 17 sekonden foltôge, toant
dizze lading:
Miskien wie dit de bedoeling, alteast om de snelheid fan de auteurs te beheinen . It proses fan it werstellen fan in reservekopy sels nimt in bytsje minder as de helte fan ien kearn, mei proporsjoneel fergelykbere prestaasjes (dus 2-5 kear stadiger) oer skiif en netwurk mei rsync.
Rsnapshot Foar herstel suggerearret it gebrûk fan reguliere rsync, sadat de resultaten ferlykber binne. Yn it algemien, dit is hoe't it draaide út.
Burp Ik foltôge de taak fan in herstellen fan in reservekopy yn 7 minuten en 2 sekonden mei
mei dizze lading:
It wurke frij fluch, en is teminsten folle handiger dan pure rsync: jo hoege gjin flaggen te ûnthâlden, in ienfâldige en yntuïtive cli-ynterface, ynboude stipe foar meardere kopyen - hoewol it twa kear stadiger is. As jo gegevens moatte weromsette fan 'e lêste reservekopy dy't jo makke hawwe, kinne jo rsync brûke, mei in pear caveats.
It programma liet sawat deselde snelheid en lading sjen ReservekopyPC by it ynskeakeljen fan rsync oerdracht modus, ynsette de reservekopy foar
7 minuten en 42 sekonden:
Mar yn gegevensferfiermodus koe BackupPC stadiger mei tar omgean: yn 12 minuten en 15 sekonden wie de prosessorlading oer it algemien leger
oardel kear:
Dupliziteit sûnder fersifering toande wat bettere resultaten, weromsette in reservekopy yn 10 minuten en 58 sekonden. As jo fersifering aktivearje mei gpg, nimt de hersteltiid ta 15 minuten en 3 sekonden. Ek by it oanmeitsjen fan in repository foar it opslaan fan kopyen, kinne jo de argyfgrutte opjaan dy't brûkt wurdt by it splitsen fan de ynkommende gegevensstream. Yn it algemien, op konvinsjonele hurde skiven, ek fanwege de single-threaded bestjoeringssysteem modus, der is net folle ferskil. It kin ferskine op ferskillende blok maten as hybride opslach wurdt brûkt. De lading op 'e haadtsjinner by herstel wie as folget:
gjin fersifering
mei fersifering
Duplikaat liet in fergelykbere hersteltiid sjen, foltôge it yn 13 minuten en 45 sekonden. It duorre sa'n 5 minuten om de krektens fan 'e herstelde gegevens te kontrolearjen (yn totaal sawat 19 minuten). De lading wie
frij heech:
Doe't aes fersifering waard ynskeakele yntern, de hersteltiid wie 21 minuten 40 sekonden, mei CPU benutten op syn maksimum (beide kearnen!) Under herstel; By it kontrolearjen fan gegevens wie mar ien tried aktyf, dy't ien prosessorkearn besette. It kontrolearjen fan de gegevens nei herstel naam deselde 5 minuten (hast 27 minuten yn totaal).
resultaat
duplicati wie in bytsje flugger mei herstel by it brûken fan it eksterne gpg-programma foar fersifering, mar yn 't algemien binne de ferskillen fan' e foarige modus minimaal. De wurktiid wie 16 minuten 30 sekonden, mei gegevensferifikaasje yn 6 minuten. De lading wie
sa:
AMANDA, mei help fan tar, foltôge it yn 2 minuten 49 sekonden, dat, yn prinsipe, is hiel ticht by reguliere tar. Laad op it systeem yn prinsipe
itselde:
By it herstellen fan in reservekopy mei help fan zbackup de folgjende resultaten waarden krigen:
fersifering, lzma kompresje
Running tiid 11 minuten en 8 sekonden
AES-fersifering, lzma-kompresje
Bedriuwstiid 14 minuten
AES fersifering, lzo kompresje
Running tiid 6 minuten, 19 sekonden
Oer it algemien net min. It hinget allegear ôf fan 'e snelheid fan' e prosessor op 'e reservekopytsjinner, dy't dúdlik te sjen is fan' e rinnende tiid fan it programma mei ferskate compressors. Oan 'e kant fan' e reservekopyserver waard in gewoane tar lansearre, dus as jo it dêrmei fergelykje, is it herstel 3 kear stadiger. It kin de muoite wurdich wêze om de operaasje te kontrolearjen yn multi-threaded modus, mei mear dan twa triedden.
BorgBackup yn net-fersifere modus wie it in bytsje stadiger as tar, yn 2 minuten 45 sekonden, lykwols, yn tsjinstelling ta tar, waard it mooglik om de repository te deduplicate. De lading die bliken te wêzen
de folgjende:
As jo blake-basearre fersifering ynskeakelje, is de backup-herstelsnelheid wat stadiger. Hersteltiid yn dizze modus is 3 minuten 19 sekonden, en de lading is fuort
lykas dit:
AES-fersifering is wat stadiger, hersteltiid is 3 minuten 23 sekonden, de lading is benammen
is net feroare:
Sûnt Borg kin wurkje yn multi-threaded modus, de prosessor load is maksimum, en as ekstra funksjes wurde aktivearre, de operaasje tiid gewoan ferheget. Blykber is it de muoite wurdich om multithreading te ferkennen op in fergelykbere manier as zbackup.
Restyk omgean mei it herstel wat stadiger, de operaasje tiid wie 4 minuten 28 sekonden. De lading like
like this:
Blykber wurket it herstelproses yn ferskate triedden, mar de effisjinsje is net sa heech as dy fan BorgBackup, mar yn 'e tiid te fergelykjen mei reguliere rsync.
Mei help fan urBackup It wie mooglik om te herstellen de gegevens yn 8 minuten en 19 sekonden, de lading wie
sa:
De lading is noch net hiel heech, sels leger as dy fan teer. Op guon plakken binne der barsten, mar net mear as de lading fan ien kearn.
Seleksje en rjochtfeardiging fan kritearia foar ferliking
Lykas oanjûn yn ien fan 'e foarige artikels, moat it reservekopysysteem oan de folgjende kritearia foldwaan:
- Maklik te brûken
- Vielfalt
- Stabiliteit
- Faasje
It is it wurdich te beskôgjen elk punt apart yn mear detail.
Gemak fan operaasje
It is it bêste as d'r ien knop is "Alles goed dwaan", mar as jo weromgean nei echte programma's, sil it meast handige ding wat fertroud en standert bestjoeringsprinsipe wêze.
De measte brûkers sille nei alle gedachten better wêze as se net hoege te ûnthâlden in bosk kaaien foar cli, konfigurearje in boskje ferskillende, faak obskure opsjes fia web of tui, of set notifikaasjes oer net slagge operaasje. Dit omfettet ek de mooglikheid om in reservekopy-oplossing maklik te "passen" yn 'e besteande ynfrastruktuer, lykas automatisearring fan it backupproses. D'r is ek de mooglikheid fan ynstallaasje mei in pakketbehearder, of yn ien of twa kommando's lykas "downloade en útpakke". curl ссылка | sudo bash - in komplekse metoade, om't jo moatte kontrolearje wat komt fia de keppeling.
Bygelyks, fan 'e beskôge kandidaten, is in ienfâldige oplossing burp, rdiff-backup en restic, dy't mnemonyske toetsen hawwe foar ferskate bestjoeringsmodi. In bytsje komplekser binne borg en duplicity. It dreechste wie AMANDA. De rest binne earne yn 'e midden yn termen fan gemak fan gebrûk. Yn alle gefallen, as jo nedich hawwe mear as 30 sekonden om te lêzen de brûker hantlieding, of jo moatte gean nei Google of in oare sykmasine, en ek rôlje troch in lange blêd fan help, it beslút is dreech, ien of oare wize.
Guon fan 'e beskôge kandidaten kinne automatysk in berjocht stjoere fia e-mailjabber, wylst oaren fertrouwe op konfigureare warskôgings yn it systeem. Boppedat hawwe meast komplekse oplossingen net hielendal dúdlike warskôgingsynstellingen. Yn alle gefallen, as it reservekopyprogramma in net-nul-returnkoade produseart, dy't goed begrepen wurdt troch de systeemtsjinst foar periodike taken (in berjocht sil stjoerd wurde nei de systeembehearder of direkt nei tafersjoch) - de situaasje is ienfâldich. Mar as it reservekopysysteem, dat net op in reservekopytsjinner rint, kin net konfigureare wurde, is de foar de hân lizzende manier om te sizzen oer it probleem dat de kompleksiteit al te heech is. Yn alle gefallen is it útjaan fan warskôgings en oare berjochten allinich nei de webynterface of nei it log in minne praktyk, om't se meastentiids sille wurde negearre.
Wat automatisearring oanbelanget, kin in ienfâldich programma omjouwingsfariabelen lêze dy't har bestjoeringsmodus ynstelle, of it hat in ûntwikkele cli dy't it gedrach folslein duplikearje kin by it wurkjen fia in webynterface, bygelyks. Dit omfettet ek de mooglikheid fan trochgeande operaasje, de beskikberens fan útwreidingsmooglikheden, ensfh.
Vielfalt
Foar in part echoing de foarige subseksje oangeande automatisearring, it soe net in bepaald probleem te "passen" it reservekopy proses yn de besteande ynfrastruktuer.
It is de muoite wurdich op te merken dat it gebrûk fan net-standert havens (goed, útsein de webynterface) foar wurk, de ymplemintaasje fan fersifering op in net-standert manier, de útwikseling fan gegevens mei in net-standert protokol tekens binne fan in net-standert protokol - universele oplossing. Foar it grutste part hawwe alle kandidaten se op ien of oare manier foar de foar de hân lizzende reden: ienfâld en alsidichheid geane meastentiids net byinoar. As útsûndering - burp, der binne oaren.
As teken - de mooglikheid om te wurkjen mei gewoane ssh.
Wurk snelheid
De meast kontroversjele en kontroversjele punt. Oan 'e iene kant hawwe wy it proses lansearre, it wurke sa rap mooglik en bemoeide de haadtaken net. Oan 'e oare kant is d'r in tanimming yn ferkear en prosessorlading tidens de reservekopyperioade. It is ek de muoite wurdich op te merken dat de rapste programma's foar it meitsjen fan kopyen meastentiids de earmste binne yn termen fan funksjes dy't wichtich binne foar brûkers. Nochris: as om ien ûngelokkich tekstbestân fan ferskate tsientallen bytes yn grutte te krijen mei in wachtwurd, en dêrtroch de hiele tsjinstkosten (ja, ja, ik begryp dat it backupproses hjir meastentiids net de skuld is), en jo moatte alle bestannen yn 'e repository sequentieel opnij lêze of it heule argyf útwreidzje - it backupsysteem is nea fluch. In oar punt dat faaks in stroffelstien wurdt is de snelheid fan it ynsetten fan in reservekopy út in argyf. D'r is hjir in dúdlik foardiel foar dyjingen dy't bestannen gewoan kopiearje of ferpleatse kinne nei de winske lokaasje sûnder folle manipulaasje (bygelyks rsync), mar meastentiids moat it probleem op in organisatoaryske manier oplost wurde, empirysk: troch it mjitten fan 'e reservekopy-hersteltiid en iepentlik ynformearje brûkers oer dit.
Stabiliteit
It moat sa begrepen wurde: oan 'e iene kant moat it mooglik wêze om de reservekopy op elke manier werom te setten, oan' e oare kant moat it resistint wêze foar ferskate problemen: netwurkûnderbrekking, skiiffalen, wiskjen fan in diel fan 'e repository.
Fergeliking fan backup ark
Kopiearje oanmeitsjen tiid
Kopiearje hersteltiid
Maklike ynstallaasje
Maklike opset
Ienfâldich gebrûk
Ienfâldige automatisearring
Binne jo in kliïnttsjinner nedich?
Kontrolearje de yntegriteit fan it repository
Differinsjaal kopyen
Wurkje fia pipe
Vielfalt
Selsstannigens
Transparânsje fan repository
Fersifering
Kompresje
Deduplikaasje
Web ynterface
Folje oan 'e wolk
Windows stipe
Skoare
rsync
4 m15s
4 m28s
ja
gjin
gjin
gjin
ja
gjin
gjin
ja
gjin
ja
ja
gjin
gjin
gjin
gjin
gjin
ja
6
Tarre
suver
3 m12s
2 m43s
ja
gjin
gjin
gjin
gjin
gjin
ja
ja
gjin
ja
gjin
gjin
gjin
gjin
gjin
gjin
ja
8,5
gzip
9 m37s
3 m19s
ja
Rdiff-backup
16 m26s
17 m17s
ja
ja
ja
ja
ja
gjin
ja
gjin
ja
gjin
ja
gjin
ja
ja
ja
gjin
ja
11
Rsnapshot
4 m19s
4 m28s
ja
ja
ja
ja
gjin
gjin
ja
gjin
ja
gjin
ja
gjin
gjin
ja
ja
gjin
ja
12,5
Burp
11 m9s
7 m2s
ja
gjin
ja
ja
ja
ja
ja
gjin
ja
ja
gjin
gjin
ja
gjin
ja
gjin
ja
10,5
Dupliziteit
gjin fersifering
16 m48s
10 m58s
ja
ja
gjin
ja
gjin
ja
ja
gjin
gjin
ja
gjin
ja
ja
gjin
ja
gjin
ja
11
gpg
17 m27s
15 m3s
Duplikaat
gjin fersifering
20 m28s
13 m45s
gjin
ja
gjin
gjin
gjin
ja
ja
gjin
gjin
ja
gjin
ja
ja
ja
ja
ja
ja
11
AES
29 m41s
21 m40s
gpg
26 m19s
16 m30s
zbackup
gjin fersifering
40 m3s
11 m8s
ja
ja
gjin
gjin
gjin
ja
ja
ja
gjin
ja
gjin
ja
ja
ja
gjin
gjin
gjin
10
AES
42 m0s
14 m1s
aes+lzo
18 m9s
6 m19s
BorgBackup
gjin fersifering
4 m7s
2 m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
gjin
ja
ja
ja
ja
gjin
ja
16
AES
4 m58s
3 m23s
blak 2
4 m39s
3 m19s
Restyk
5 m38s
4 m28s
ja
ja
ja
ja
gjin
ja
ja
ja
ja
ja
gjin
ja
gjin
ja
gjin
ja
ja
15,5
urBackup
8 m21s
8 m19s
ja
ja
ja
gjin
ja
gjin
ja
gjin
ja
ja
gjin
ja
ja
ja
ja
gjin
ja
12
amanda
9 m3s
2 m49s
ja
gjin
gjin
ja
ja
ja
ja
gjin
ja
ja
ja
ja
ja
gjin
ja
ja
ja
13
ReservekopyPC
rsync
12 m22s
7 m42s
ja
gjin
ja
ja
ja
ja
ja
gjin
ja
gjin
gjin
ja
ja
gjin
ja
gjin
ja
10,5
tar
12 m34s
12 m15s
Tabel leginda:
- Grien, wurktiid minder dan fiif minuten, of antwurdzje "Ja" (útsein de kolom "In kliïnttsjinner nedich?"), 1 punt
- Giel, wurktiid fiif oant tsien minuten, 0.5 punten
- Red, de wurktiid is mear as tsien minuten, of it antwurd is "Nee" (útsein foar de kolom "Binne jo in kliïnttsjinner nedich?"), 0 punten
Neffens de tabel hjirboppe, de ienfâldichste, fluchste, en tagelyk handige en krêftige reservekopy ark is BorgBackup. Restic naam it twadde plak, de rest fan de beskôge kandidaten waarden pleatst likernôch gelyk mei in sprieding fan ien of twa punten oan 'e ein.
Ik tankje elkenien dy't de searje oant it ein lêze, ik noegje jo út om de opsjes te besprekken en jo eigen, as ien, oan te bieden. As de diskusje foarútgiet, kin de tabel útwreide wurde.
It resultaat fan 'e searje sil it lêste artikel wêze, wêryn't in besykjen sil wêze om in ideaal, fluch en behearsber reservekopy-ark te ûntwikkeljen wêrmei jo in kopy yn 'e koartst mooglike tiid kinne ynsette en tagelyk handich en maklik wêze te konfigurearjen en te ûnderhâlden.
Meidieling
Reservekopy Diel 6: Fergeliking fan reservekopy-ark
Reservekopy Part 7: Konklúzjes
Boarne: www.habr.com