{"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\/da\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Sikkerhedskopiering, del 6: Sammenligning af sikkerhedskopieringsv\u00e6rkt\u00f8jer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Sikkerhedskopiering,
\nI denne artikel vil der blive foretaget en sammenligning af backupv\u00e6rkt\u00f8jer, men f\u00f8rst er det v\u00e6rd at finde ud af, hvordan de hurtigt og effektivt h\u00e5ndterer gendannelse af data fra backups.
\nFor at g\u00f8re sammenligningen enklere vil gendannelse fra en fuld backup blive behandlet, da alle kandidater underst\u00f8tter denne arbejdsmetode. Tallene er taget som gennemsnit (aritmetisk gennemsnit af flere k\u00f8rselser). Resultaterne vil blive pr\u00e6senteret i en tabel, som ogs\u00e5 vil give information om funktionerne: tilg\u00e6ngelighed af webgr\u00e6nseflade, enkelhed i ops\u00e6tning og betjening, evne til automatisering, samt forskellige ekstra funktioner (for eksempel dataintegritetskontrol) osv. Grafikkerne vil vise belastningen p\u00e5 serveren, hvor dataene vil blive anvendt (ikke serveren til opbevaring af backups).
\n<\/a><\/noindex><\/p>\n

Datagendannelse<\/h2>\n

\nSom referencepunkt vil rsync og tar blive brugt, da de normalt er grundlaget for<\/a><\/noindex> de simpleste scripts til oprettelse af backups.<\/p>\n

Rsync<\/i> klarede den testede datas\u00e6t p\u00e5 4 minutter og 28 sekunder og viste <\/p>\n

denne belastning<\/b>\"Sikkerhedskopiering,
\n
\nGendannelsesprocessen l\u00f8b ind i begr\u00e6nsningen af diskunderen p\u00e5 backupserveren (tandformede grafer). Derudover er det tydeligt at se belastningen p\u00e5 et enkelt kerne uden s\u00e6rlige problemer (lav iowait og softirq \u2014 ingen problemer med disk og netv\u00e6rk). Da de to andre programmer, nemlig rdiff-backup og rsnapshot, er baseret p\u00e5 rsync og ogs\u00e5 tilbyder almindelig rsync som gendannelsesv\u00e6rkt\u00f8j, vil de have en nogenlunde samme belastningsprofil og gendannelsestid for backup.<\/p>\n

Tar<\/i> klarede det lidt hurtigere, p\u00e5 <\/p>\n

2 minutter og 43 sekunder:<\/b>\"Sikkerhedskopiering,
\n
\nDen samlede systembelastning var i gennemsnit 20% h\u00f8jere p\u00e5 grund af den \u00f8gede softirq \u2014 overhead ved netv\u00e6rksunderen er steget.<\/p>\n

Hvis arkivet komprimeres yderligere, stiger gendannelsestiden til 3 minutter og 19 sekunder med
\ndenne belastning p\u00e5 hovedserveren (udpakning p\u00e5 hovedserverens side):<\/b>\"Sikkerhedskopiering,
\n
\nUdvindingsprocessen bruger begge processorkerner, da den k\u00f8rer to processer. Samlet set er det et forventet resultat. Et sammenligneligt resultat (3 minutter og 20 sekunder) blev opn\u00e5et ved at k\u00f8re gzip p\u00e5 serversiden med backup, belastningsprofilen p\u00e5 hovedserveren var meget lig den fra at k\u00f8re tar uden gzip-kompressoren (se tidligere graf).<\/p>\n

I rdiff-backup<\/i> man kan synkronisere den seneste oprettede backup med almindelig rsync (resultaterne vil v\u00e6re ens), men \u00e6ldre backuper skal stadig gendannes ved hj\u00e6lp af rdiff-backup-programmet, som klarede gendannelsen p\u00e5 17 minutter og 17 sekunder og viste <\/p>\n

en belastning som denne:<\/b>\"Sikkerhedskopiering,
\n
\nDet kan have v\u00e6ret hensigten, i hvert fald for at begr\u00e6nse hastigheden, foresl\u00e5r forfatterne denne l\u00f8sning<\/a><\/noindex>. Selve gendannelsesprocessen for backup tager lidt mindre end halvdelen af en kerne, med proportionelt sammenlignelig ydeevne (dvs. 2-5 gange langsommere) over disk og netv\u00e6rk med rsync.<\/p>\n

Rsnapshot<\/i> til gendannelse anbefaler at bruge almindelig rsync, s\u00e5 resultaterne vil v\u00e6re ens. Generelt er det ogs\u00e5 det, der skete.<\/p>\n

Burp<\/i> klarede gendannelsesopgaven p\u00e5 7 minutter og 2 sekunder med
\ndenne belastning:<\/b>\"Sikkerhedskopiering,
\n
\nDet gik hurtigt nok, og det er i det mindste meget mere bekvemt end ren rsync: man beh\u00f8ver ikke at huske nogen flag, en enkel og intuitiv kommandolinjegr\u00e6nseflade, indbygget support til flere kopier - dog er det cirka dobbelt s\u00e5 langsomt. Hvis dataene skal gendannes fra den seneste udf\u00f8rte backup, kan man bruge rsync med nogle f\u00e5 forbehold.<\/p>\n

Programmet BackupPC<\/i> viste omtrent samme hastighed og belastning ved aktivering af rsync-overf\u00f8rselsmodus, idet den gendannede backup p\u00e5 <\/p>\n

7 minutter og 42 sekunder:<\/b>\"Sikkerhedskopiering,
\n
\nMen i tar-dataoverf\u00f8rselsmodus klarede BackupPC det langsommere: p\u00e5 12 minutter og 15 sekunder, mens belastningen p\u00e5 CPU'en generelt var lavere. <\/p>\n

med det halve:<\/b>\"Sikkerhedskopiering,
\n
\nDuplicity<\/i> uden kryptering viste lidt bedre resultater og klarede gendannelsen af sikkerhedskopien p\u00e5 10 minutter og 58 sekunder. N\u00e5r kryptering aktiveres med gpg, stiger gendannelsestiden til 15 minutter og 3 sekunder. Ved oprettelse af et depot til opbevaring af sikkerhedskopier kan man ogs\u00e5 angive st\u00f8rrelsen p\u00e5 arkivet, der skal bruges til at opdele str\u00f8mmen af indkommende data. Generelt er der ikke den store forskel p\u00e5 almindelige harddiske, ogs\u00e5 i forhold til den enkelttr\u00e5dsbetjening, som der var. Forskellen kan m\u00e5ske opst\u00e5 ved forskellige blokst\u00f8rrelser, n\u00e5r der bruges hybride lagringsenheder. Belastningen p\u00e5 hovedserveren under gendannelsen var s\u00e5dan:<\/p>\n

uden kryptering<\/b>\"Sikkerhedskopiering,
\n
\nmed kryptering<\/b>\"Sikkerhedskopiering,
\n
\nDuplicati<\/i> viste en sammenlignelig gendannelseshastighed og klarede det p\u00e5 13 minutter og 45 sekunder. Ca. 5 minutter mere brugte p\u00e5 at kontrollere korrektheden af de gendannede data (i alt omkring 19 minutter). Belastningen var <\/p>\n

ganske h\u00f8j:<\/b>\"Sikkerhedskopiering,
\n
\nDa krypteringen aes blev aktiveret med interne midler, var gendannelsestiden 21 minutter og 40 sekunder, og belastningen p\u00e5 processoren var maksimal (begge kerner!) under gendannelsen; ved kontrollen af data var kun \u00e9n tr\u00e5d aktiv, der brugte \u00e9n processor kerne. Kontrollen af data efter gendannelsen tog de samme 5 minutter (i alt n\u00e6sten 27 minutter).<\/p>\n

Resultat<\/b>\"Sikkerhedskopiering,
\n
\nDuplettene klarede gendannelsen lidt hurtigere ved at bruge det eksterne program gpg til kryptering, men generelt var forskellene fra den tidligere tilstand minimale. Arbejdstiden var 16 minutter og 30 sekunder, med en datakontrol p\u00e5 6 minutter. Belastningen var <\/p>\n

s\u00e5dan:<\/b>\"Sikkerhedskopiering,
\n
\nAMANDA<\/i>, som bruger tar, klarede det p\u00e5 2 minutter og 49 sekunder, hvilket i princippet er meget t\u00e6t p\u00e5 almindelig tar. Belastningen p\u00e5 systemet er i princippet <\/p>\n

den samme:<\/b>\"Sikkerhedskopiering,
\n
\nVed gendannelse af sikkerhedskopi med zbackup<\/i> fik f\u00f8lgende resultater:<\/p>\n

kryptering, komprimering lzma<\/b>\"Sikkerhedskopiering,
\n
\nArbejdstid 11 minutter og 8 sekunder<\/p>\n

kryptering aes, komprimering lzma<\/b>\"Sikkerhedskopiering,
\n
\nArbejdstid 14 minutter<\/p>\n

kryptering aes, komprimering lzo<\/b>\"Sikkerhedskopiering,
\n
\nArbejdstid 6 minutter, 19 sekunder<\/p>\n

Generelt set er det ikke d\u00e5rligt. Alt afh\u00e6nger af hastigheden p\u00e5 CPU'en i backup-serveren, hvilket tydeligt ses p\u00e5 programmets k\u00f8retid med forskellige kompressorer. P\u00e5 backup-serveren blev der k\u00f8rt en almindelig tar, s\u00e5 hvis man sammenligner med den, er gendannelsen tre gange langsommere. M\u00e5ske b\u00f8r man tjekke ydeevnen i multi-tr\u00e5dede tilstande med mere end to tr\u00e5de.<\/p>\n

BorgBackup<\/i> I ikke-krypteret tilstand klarede den sig lidt langsommere end tar, med en tid p\u00e5 2 minutter og 45 sekunder, men i mods\u00e6tning til tar blev der givet mulighed for deduplikation af depotet. Belastningen blev <\/p>\n

f\u00f8lgende:<\/b>\"Sikkerhedskopiering,
\n
\nHvis man aktiverer kryptering baseret p\u00e5 blake, reduceres gendannelseshastigheden en smule. Gendannelsestiden i denne tilstand er 3 minutter og 19 sekunder, og belastningen blev <\/p>\n

s\u00e5dan:<\/b>\"Sikkerhedskopiering,
\n
\nAES-kryptering fungerer en smule langsommere, gendannelsestiden er 3 minutter og 23 sekunder, og belastningen er <\/p>\n

ikke \u00e6ndret:<\/b>\"Sikkerhedskopiering,
\n
\nDa Borg kan arbejde i multi-tr\u00e5dede tilstande, er CPU-belastningen maksimal, og ved aktivering af yderligere funktioner stiger blot k\u00f8retiden. Det ser ud til, at det ville v\u00e6re v\u00e6rd at unders\u00f8ge multi-tr\u00e5det performance ligesom zbackup.<\/p>\n

Restic<\/i> klarede gendannelsen lidt langsommere, med en k\u00f8retid p\u00e5 4 minutter og 28 sekunder. Belastningen s\u00e5 <\/p>\n

s\u00e5dan ud:<\/b>\"Sikkerhedskopiering,
\n
\nDet ser ud til, at gendannelsesprocessen k\u00f8rer med flere tr\u00e5de, men effektiviteten er ikke s\u00e5 h\u00f8j som BorgBackup, men tidm\u00e6ssigt sammenlignelig med almindelig rsync.<\/p>\n

Ved hj\u00e6lp af UrBackup<\/i> f\u00e5ede man gendannet data p\u00e5 8 minutter og 19 sekunder, og belastningen var <\/p>\n

s\u00e5dan:<\/b>\"Sikkerhedskopiering,
\n
\nSom f\u00f8r tydeligt ses, er belastningen stadig ikke s\u00e6rlig h\u00f8j, endda lavere end hos tar. Der er enkelte spidser, men ikke mere belastning end en kerne.<\/p>\n

Valg og begrundelse af kriterier til sammenligning<\/h2>\n

\nSom n\u00e6vnt i en af de tidligere artikler, b\u00f8r backup-systemet opfylde f\u00f8lgende kriterier:<\/p>\n