{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, del 6: J\u00e4mf\u00f6relse av backupverktyg","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nI den h\u00e4r artikeln kommer en j\u00e4mf\u00f6relse av backupverktyg att g\u00f6ras, men f\u00f6rst \u00e4r det v\u00e4rt att ta reda p\u00e5 hur snabbt och effektivt de kan \u00e5terst\u00e4lla data fr\u00e5n s\u00e4kerhetskopior.
\nF\u00f6r enkelhets skull kommer \u00e5terst\u00e4llning fr\u00e5n en fullst\u00e4ndig s\u00e4kerhetskopia att \u00f6verv\u00e4gas, s\u00e4rskilt eftersom alla kandidater st\u00f6der detta arbetsl\u00e4ge. F\u00f6r att f\u00f6renkla har siffrorna redan medelv\u00e4rdesber\u00e4knats (arimetriskt medel av flera k\u00f6rningar). Resultaten kommer att sammanst\u00e4llas i en tabell, som ocks\u00e5 kommer att inneh\u00e5lla information om olika funktioner: tillg\u00e5ng till webbgr\u00e4nssnitt, enkelhet i konfiguration och anv\u00e4ndning, automatiseringskapabiliteter, samt olika extrafunktioner (till exempel dataintegritetskontroll) osv. Graferna kommer att visa serverns belastning, d\u00e4r data kommer att till\u00e4mpas (inte servern f\u00f6r lagring av s\u00e4kerhetskopior).
\n<\/a><\/noindex><\/p>\n

\u00c5terst\u00e4llning av data<\/h2>\n

\nSom referens kommer rsync och tar att anv\u00e4ndas, eftersom de vanligtvis utg\u00f6r grunden f\u00f6r<\/a><\/noindex> de enklaste skripten f\u00f6r att ta s\u00e4kerhetskopior.<\/p>\n

Rsync<\/i> klarade testdatam\u00e4ngden p\u00e5 4 minuter och 28 sekunder, vilket visade <\/p>\n

denna belastning.<\/b>\"Backup,
\n
\n\u00c5terst\u00e4llningsprocessen begr\u00e4nsades av disksystemets begr\u00e4nsningar p\u00e5 lagringsservern (taggiga grafer). Det syns tydligt att ett k\u00e4rna har belastats utan st\u00f6rre problem (l\u00e5g iowait och softirq \u2014 inga problem med disk och n\u00e4tverk respektive). Eftersom de tv\u00e5 andra programmen, n\u00e4mligen rdiff-backup och rsnapshot, \u00e4r baserade p\u00e5 rsync och ocks\u00e5 erbjuder rsync som \u00e5terst\u00e4llningsmedel, kommer de att ha en ungef\u00e4r liknande belastningsprofil och \u00e5terst\u00e4llningstid.<\/p>\n

Tar<\/i> klarade det n\u00e5got snabbare, p\u00e5 <\/p>\n

2 minuter och 43 sekunder:<\/b>\"Backup,
\n
\nDen totala systembelastningen var i genomsnitt 20 % h\u00f6gre p\u00e5 grund av \u00f6kad softirq \u2014 overheaden i den n\u00e4tverksbaserade subsystemet \u00f6kade.<\/p>\n

Om arkivet dessutom komprimeras \u00f6kar \u00e5terst\u00e4llningstiden till 3 minuter och 19 sekunder med
\ndenna belastning p\u00e5 den prim\u00e4ra servern (uppackning p\u00e5 den prim\u00e4ra servern):<\/b>\"Backup,
\n
\nUppackningsprocessen anv\u00e4nder b\u00e5da processor-k\u00e4rnorna, eftersom tv\u00e5 processer k\u00f6rs. Totalt sett \u00e4r detta ett f\u00f6rv\u00e4ntat resultat. Ett j\u00e4mf\u00f6rbart resultat (3 minuter och 20 sekunder) erh\u00f6lls ocks\u00e5 vid k\u00f6rning av gzip p\u00e5 serversidan med s\u00e4kerhetskopior; belastningsprofilen p\u00e5 huvudservern var ganska lik den vid k\u00f6rning av tar utan gzip-kompressorn (se tidigare diagram).<\/p>\n

I rdiff-backup<\/i> Den senaste gjorda s\u00e4kerhetskopian kan synkroniseras med vanlig rsync (resultaten kommer att vara liknande), men \u00e4ldre s\u00e4kerhetskopior m\u00e5ste fortfarande \u00e5terst\u00e4llas med hj\u00e4lp av programmet rdiff-backup, som hanterade \u00e5terst\u00e4llningen p\u00e5 17 minuter och 17 sekunder, vilket visade <\/p>\n

denna belastning:<\/b>\"Backup,
\n
\nDet kan ha varit avsikten, i alla fall f\u00f6r att begr\u00e4nsa hastigheten f\u00f6resl\u00e5r f\u00f6rfattarna en s\u00e5dan l\u00f6sning<\/a><\/noindex>. Sj\u00e4lva processen f\u00f6r att \u00e5terst\u00e4lla s\u00e4kerhetskopian tar lite mindre \u00e4n h\u00e4lften av en k\u00e4rna, med proportionellt j\u00e4mf\u00f6rbar prestanda (d.v.s. 2-5 g\u00e5nger l\u00e5ngsammare) \u00f6ver disk och n\u00e4tverk med rsync.<\/p>\n

Rsnapshot<\/i> rekommenderar att anv\u00e4nda vanlig rsync f\u00f6r \u00e5terst\u00e4llning, s\u00e5 resultaten kommer att vara liknande. Totalt sett visade det sig st\u00e4mma.<\/p>\n

Burp<\/i> klarade uppgiften att \u00e5terst\u00e4lla s\u00e4kerhetskopian p\u00e5 7 minuter och 2 sekunder med
\ndenna belastning:<\/b>\"Backup,
\n
\nDet gick tillr\u00e4ckligt snabbt och, \u00e5tminstone, betydligt mer bekv\u00e4mt \u00e4n ren rsync: man beh\u00f6ver inte komma ih\u00e5g n\u00e5gra flaggor, enkel och intuitiv cli-gr\u00e4nssnitt, inbyggt st\u00f6d f\u00f6r flera kopior - men det \u00e4r ungef\u00e4r dubbelt s\u00e5 l\u00e5ngsamt. Om data ska \u00e5terst\u00e4llas fr\u00e5n den senaste gjorda s\u00e4kerhetskopian - kan man anv\u00e4nda rsync, med n\u00e5gra f\u00e5 f\u00f6rbeh\u00e5ll.<\/p>\n

Ungef\u00e4r samma hastighet och belastning visade programmet BackupPC<\/i> n\u00e4r rsync \u00f6verf\u00f6ringsl\u00e4get var aktiverat, och \u00e5terst\u00e4llde s\u00e4kerhetskopian p\u00e5 <\/p>\n

7 minuter och 42 sekunder:<\/b>\"Backup,
\n
\nMen i tar \u00f6verf\u00f6ringsl\u00e4ge fungerade BackupPC l\u00e5ngsammare: p\u00e5 12 minuter och 15 sekunder, medan processorbelastningen i det fallet var generellt l\u00e4gre <\/p>\n

med 1,5 g\u00e5nger:<\/b>\"Backup,
\n
\nDuplicity<\/i> utan kryptering visade n\u00e5got b\u00e4ttre resultat, genomf\u00f6rde \u00e5terst\u00e4llningen av s\u00e4kerhetskopian p\u00e5 10 minuter och 58 sekunder. Om kryptering aktiveras med hj\u00e4lp av gpg \u00f6kar \u00e5terst\u00e4llningstiden till 15 minuter och 3 sekunder. Vid skapandet av ett repository f\u00f6r att lagra s\u00e4kerhetskopior kan man ocks\u00e5 ange storleken p\u00e5 arkivet som ska anv\u00e4ndas vid uppdelningen av den inkommande datastreamen. Generellt sett, p\u00e5 vanliga h\u00e5rddiskar, samt p\u00e5 grund av den enskilda tr\u00e5dmoden, \u00e4r det ingen st\u00f6rre skillnad. Det kan dock dyka upp variationer med olika blockstorlekar n\u00e4r hybridlagring anv\u00e4nds. Belastningen p\u00e5 huvudservern under \u00e5terst\u00e4llningen var s\u00e5dan:<\/p>\n

utan kryptering<\/b>\"Backup,
\n
\nmed kryptering<\/b>\"Backup,
\n
\nDuplicati<\/i> visade j\u00e4mf\u00f6rbar hastighet f\u00f6r \u00e5terst\u00e4llning, genomf\u00f6rde det p\u00e5 13 minuter och 45 sekunder. Ytterligare cirka 5 minuter tog det att kontrollera korrektheten av de \u00e5terst\u00e4llda uppgifterna (totalt cirka 19 minuter). Belastningen under detta var <\/p>\n

relativt h\u00f6g:<\/b>\"Backup,
\n
\nN\u00e4r kryptering med aes aktiverades via interna medel, blev \u00e5terst\u00e4llningstiden 21 minuter och 40 sekunder, och CPU-belastningen var maximal (b\u00e5da k\u00e4rnorna!) under \u00e5terst\u00e4llningen; vid datakontrollen var endast en tr\u00e5d aktiv, som anv\u00e4nde en CPU-k\u00e4rna. Kontroll av data efter \u00e5terst\u00e4llning tog samma 5 minuter (totalt n\u00e4stan 27 minuter).<\/p>\n

Resultat<\/b>\"Backup,
\n
\nN\u00e5got snabbare hanterade duplicati \u00e5terst\u00e4llningen n\u00e4r en extern programvara gpg anv\u00e4ndes f\u00f6r kryptering, men \u00f6verlag \u00e4r skillnaderna fr\u00e5n det f\u00f6reg\u00e5ende l\u00e4get minimala. Arbetstiden var 16 minuter och 30 sekunder, med datakontroll p\u00e5 6 minuter. Belastningen var <\/p>\n

s\u00e5dan:<\/b>\"Backup,
\n
\nAMANDA<\/i>, som anv\u00e4nder tar, klarade det p\u00e5 2 minuter och 49 sekunder, vilket i princip \u00e4r ganska n\u00e4ra vanlig tar. Belastningen p\u00e5 systemet \u00e4r i stort sett <\/p>\n

samma:<\/b>\"Backup,
\n
\nVid \u00e5terst\u00e4llning av s\u00e4kerhetskopian med zbackup<\/i> fick vi f\u00f6ljande resultat:<\/p>\n

kryptering, lzma-komprimering<\/b>\"Backup,
\n
\nArbetstid 11 minuter och 8 sekunder<\/p>\n

kryptering aes, lzma-komprimering<\/b>\"Backup,
\n
\nArbetstid 14 minuter<\/p>\n

kryptering aes, lzo-komprimering<\/b>\"Backup,
\n
\nArbetstid 6 minuter, 19 sekunder<\/p>\n

\u00d6verlag \u00e4r det okej. Allt beror p\u00e5 hastigheten hos processorn p\u00e5 backupservern, vilket tydligt syns p\u00e5 programmets prestanda med olika kompressorer. P\u00e5 backupservern k\u00f6rdes en vanlig tar, s\u00e5 om man j\u00e4mf\u00f6r med den \u2013 \u00e5terst\u00e4llningen fungerar tre g\u00e5nger l\u00e5ngsammare. Det kan vara v\u00e4rt att kontrollera prestandan i flertr\u00e5dat l\u00e4ge, med fler \u00e4n tv\u00e5 tr\u00e5dar.<\/p>\n

BorgBackup<\/i> i okrypterat l\u00e4ge klarade sig n\u00e5got l\u00e5ngsammare \u00e4n tar, p\u00e5 2 minuter och 45 sekunder, men till skillnad fr\u00e5n tar fanns m\u00f6jligheten till deduplicering av repository. Belastningen blev <\/p>\n

s\u00e5 h\u00e4r:<\/b>\"Backup,
\n
\nOm man aktiverar kryptering baserad p\u00e5 blake, s\u00e4nks \u00e5terst\u00e4llningshastigheten n\u00e5got. \u00c5terst\u00e4llningstiden i detta l\u00e4ge \u00e4r 3 minuter och 19 sekunder, och belastningen blev <\/p>\n

s\u00e5 h\u00e4r:<\/b>\"Backup,
\n
\nAES-kryptering fungerar n\u00e5got l\u00e5ngsammare, \u00e5terst\u00e4llningstiden \u00e4r 3 minuter och 23 sekunder, belastningen f\u00f6rblev <\/p>\n

of\u00f6r\u00e4ndrad:<\/b>\"Backup,
\n
\nEftersom Borg kan k\u00f6ras i flertr\u00e5dat l\u00e4ge \u2013 \u00e4r CPU-belastningen maximal, och vid aktivering av ytterligare funktioner \u00f6kar bara arbetstiden. Upplagt \u00e4r tydligt att det kan vara v\u00e4rt att utforska flertr\u00e5dad prestanda p\u00e5 liknande s\u00e4tt som zbackup.<\/p>\n

Restic<\/i> klarade \u00e5terst\u00e4llningen n\u00e5got l\u00e5ngsammare, arbetstiden blev 4 minuter och 28 sekunder. Belastningen s\u00e5g ut som <\/p>\n

s\u00e5 h\u00e4r:<\/b>\"Backup,
\n
\ntydligt verkar \u00e5terst\u00e4llningsprocessen arbeta i flera tr\u00e5dar, men effektiviteten \u00e4r inte lika h\u00f6g som BorgBackup, men tiden \u00e4r j\u00e4mf\u00f6rbar med vanlig rsync.<\/p>\n

Med hj\u00e4lp av UrBackup<\/i> lyckades \u00e5terst\u00e4lla data p\u00e5 8 minuter och 19 sekunder, och belastningen var <\/p>\n

s\u00e5dan:<\/b>\"Backup,
\n
\nfortfarande synligt l\u00e5g, till och med l\u00e4gre \u00e4n tar. Ibland toppar, men inte mer \u00e4n belastningen p\u00e5 ett k\u00e4rn.<\/p>\n

Val och motivering av kriterier f\u00f6r j\u00e4mf\u00f6relse<\/h2>\n

\nSom n\u00e4mnts i en av de tidigare artiklarna b\u00f6r backupsystemet uppfylla f\u00f6ljande kriterier:<\/p>\n