I denne artikel vil der blive foretaget en sammenligning af backupværktøjer, men først er det værd at finde ud af, hvordan de hurtigt og effektivt håndterer gendannelse af data fra backups.
For at gøre sammenligningen enklere vil gendannelse fra en fuld backup blive behandlet, da alle kandidater understøtter denne arbejdsmetode. Tallene er taget som gennemsnit (aritmetisk gennemsnit af flere kørselser). Resultaterne vil blive præsenteret i en tabel, som også vil give information om funktionerne: tilgængelighed af webgrænseflade, enkelhed i opsætning og betjening, evne til automatisering, samt forskellige ekstra funktioner (for eksempel dataintegritetskontrol) osv. Grafikkerne vil vise belastningen på serveren, hvor dataene vil blive anvendt (ikke serveren til opbevaring af backups).
Datagendannelse
Som referencepunkt vil rsync og tar blive brugt, da de simpleste scripts til oprettelse af backups.
Rsync klarede den testede datasæt på 4 minutter og 28 sekunder og viste
denne belastning
Gendannelsesprocessen løb ind i begrænsningen af diskunderen på backupserveren (tandformede grafer). Derudover er det tydeligt at se belastningen på et enkelt kerne uden særlige problemer (lav iowait og softirq — ingen problemer med disk og netværk). Da de to andre programmer, nemlig rdiff-backup og rsnapshot, er baseret på rsync og også tilbyder almindelig rsync som gendannelsesværktøj, vil de have en nogenlunde samme belastningsprofil og gendannelsestid for backup.
Tar klarede det lidt hurtigere, på
2 minutter og 43 sekunder:
Den samlede systembelastning var i gennemsnit 20% højere på grund af den øgede softirq — overhead ved netværksunderen er steget.
Hvis arkivet komprimeres yderligere, stiger gendannelsestiden til 3 minutter og 19 sekunder med
denne belastning på hovedserveren (udpakning på hovedserverens side):
Udvindingsprocessen bruger begge processorkerner, da den kører to processer. Samlet set er det et forventet resultat. Et sammenligneligt resultat (3 minutter og 20 sekunder) blev opnået ved at køre gzip på serversiden med backup, belastningsprofilen på hovedserveren var meget lig den fra at køre tar uden gzip-kompressoren (se tidligere graf).
I rdiff-backup man kan synkronisere den seneste oprettede backup med almindelig rsync (resultaterne vil være ens), men ældre backuper skal stadig gendannes ved hjælp af rdiff-backup-programmet, som klarede gendannelsen på 17 minutter og 17 sekunder og viste
en belastning som denne:
Det kan have været hensigten, i hvert fald for at begrænse hastigheden, foreslår forfatterne . 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ærk med rsync.
Rsnapshot til gendannelse anbefaler at bruge almindelig rsync, så resultaterne vil være ens. Generelt er det også det, der skete.
Burp klarede gendannelsesopgaven på 7 minutter og 2 sekunder med
denne belastning:
Det gik hurtigt nok, og det er i det mindste meget mere bekvemt end ren rsync: man behøver ikke at huske nogen flag, en enkel og intuitiv kommandolinjegrænseflade, indbygget support til flere kopier - dog er det cirka dobbelt så langsomt. Hvis dataene skal gendannes fra den seneste udførte backup, kan man bruge rsync med nogle få forbehold.
Programmet BackupPC viste omtrent samme hastighed og belastning ved aktivering af rsync-overførselsmodus, idet den gendannede backup på
7 minutter og 42 sekunder:
Men i tar-dataoverførselsmodus klarede BackupPC det langsommere: på 12 minutter og 15 sekunder, mens belastningen på CPU'en generelt var lavere.
med det halve:
Duplicity uden kryptering viste lidt bedre resultater og klarede gendannelsen af sikkerhedskopien på 10 minutter og 58 sekunder. Når kryptering aktiveres med gpg, stiger gendannelsestiden til 15 minutter og 3 sekunder. Ved oprettelse af et depot til opbevaring af sikkerhedskopier kan man også angive størrelsen på arkivet, der skal bruges til at opdele strømmen af indkommende data. Generelt er der ikke den store forskel på almindelige harddiske, også i forhold til den enkelttrådsbetjening, som der var. Forskellen kan måske opstå ved forskellige blokstørrelser, når der bruges hybride lagringsenheder. Belastningen på hovedserveren under gendannelsen var sådan:
uden kryptering
med kryptering
Duplicati viste en sammenlignelig gendannelseshastighed og klarede det på 13 minutter og 45 sekunder. Ca. 5 minutter mere brugte på at kontrollere korrektheden af de gendannede data (i alt omkring 19 minutter). Belastningen var
ganske høj:
Da krypteringen aes blev aktiveret med interne midler, var gendannelsestiden 21 minutter og 40 sekunder, og belastningen på processoren var maksimal (begge kerner!) under gendannelsen; ved kontrollen af data var kun én tråd aktiv, der brugte én processor kerne. Kontrollen af data efter gendannelsen tog de samme 5 minutter (i alt næsten 27 minutter).
Resultat
Duplettene 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å 6 minutter. Belastningen var
sådan:
AMANDA, som bruger tar, klarede det på 2 minutter og 49 sekunder, hvilket i princippet er meget tæt på almindelig tar. Belastningen på systemet er i princippet
den samme:
Ved gendannelse af sikkerhedskopi med zbackup fik følgende resultater:
kryptering, komprimering lzma
Arbejdstid 11 minutter og 8 sekunder
kryptering aes, komprimering lzma
Arbejdstid 14 minutter
kryptering aes, komprimering lzo
Arbejdstid 6 minutter, 19 sekunder
Generelt set er det ikke dårligt. Alt afhænger af hastigheden på CPU'en i backup-serveren, hvilket tydeligt ses på programmets køretid med forskellige kompressorer. På backup-serveren blev der kørt en almindelig tar, så hvis man sammenligner med den, er gendannelsen tre gange langsommere. Måske bør man tjekke ydeevnen i multi-trådede tilstande med mere end to tråde.
BorgBackup I ikke-krypteret tilstand klarede den sig lidt langsommere end tar, med en tid på 2 minutter og 45 sekunder, men i modsætning til tar blev der givet mulighed for deduplikation af depotet. Belastningen blev
følgende:
Hvis man aktiverer kryptering baseret på blake, reduceres gendannelseshastigheden en smule. Gendannelsestiden i denne tilstand er 3 minutter og 19 sekunder, og belastningen blev
sådan:
AES-kryptering fungerer en smule langsommere, gendannelsestiden er 3 minutter og 23 sekunder, og belastningen er
ikke ændret:
Da Borg kan arbejde i multi-trådede tilstande, er CPU-belastningen maksimal, og ved aktivering af yderligere funktioner stiger blot køretiden. Det ser ud til, at det ville være værd at undersøge multi-trådet performance ligesom zbackup.
Restic klarede gendannelsen lidt langsommere, med en køretid på 4 minutter og 28 sekunder. Belastningen så
sådan ud:
Det ser ud til, at gendannelsesprocessen kører med flere tråde, men effektiviteten er ikke så høj som BorgBackup, men tidmæssigt sammenlignelig med almindelig rsync.
Ved hjælp af UrBackup fåede man gendannet data på 8 minutter og 19 sekunder, og belastningen var
sådan:
Som før tydeligt ses, er belastningen stadig ikke særlig høj, endda lavere end hos tar. Der er enkelte spidser, men ikke mere belastning end en kerne.
Valg og begrundelse af kriterier til sammenligning
Som nævnt i en af de tidligere artikler, bør backup-systemet opfylde følgende kriterier:
- Nemmere arbejde
- Universelt
- Stabilitet
- Hurtighed
Det er værd at overveje hvert punkt individuelt mere detaljeret.
Brugervenlighed
Det bedste er, når der er en enkelt knap "Gør alt godt", men hvis vi ser tilbage på de faktiske programmer, vil det være nemmest med en vis velkendt og standard arbejdsmetode.
De fleste brugere vil sandsynligvis have lettere ved ikke at skulle huske en masse nøgler til CLI, konfigurere en række forskellige, ofte forvirrende indstillinger via web eller TUI, samt indstille alarmer for mislykkede opgaver. Dette inkluderer også muligheden for nemt at integrere en backupløsning i den eksisterende infrastruktur, samt automatisering af backupprocessen. Herunder muligheden for installation via en pakkehandler, eller med en til to kommandoer af typen "download og udpakk". curl link | sudo bash — en kompleks metode, da man skal tjekke, hvad der kommer fra linket.
For eksempel er blandt de betragtede kandidater simple løsninger som burp, rdiff-backup og restic, som har nemme at huske nøgler for forskellige driftsmåder. Lidt mere komplekse er borg og duplicity. Den mest komplekse var AMANDA. De øvrige er i brugsvenlighed et sted midt imellem. Under alle omstændigheder, hvis det tager mere end 30 sekunder at læse brugervejledningen, eller man skal søge på Google eller en anden søgemaskine samt gennemgå lange hjælpetekster — så er løsningen kompleks, på en eller anden måde.
Nogle af de betragtede kandidater kan automatisk sende en besked via e-mail eller jabber, mens andre er afhængige af konfigurerede meddelelser i systemet. Ofte har komplekse løsninger ikke helt åbenlyse indstillinger for alarmer. Under alle omstændigheder, hvis backup-programmet returnerer en ikke-nul exitkode, som systemtjenesten for planlagte opgaver korrekt kan forstå (det sender en besked til systemadministratoren eller direkte til overvågningen) — så er situationen ligetil. Men hvis backup-systemet, der ikke kører på backupserveren, ikke kan uden konfiguration, åbenlyst kommunikere om problemet — så er kompleksiteten overflødig. Under alle omstændigheder er det en dårlig praksis, at give advarsler og andre meddelelser kun i webinterfacet eller loggen, da de ofte vil blive ignoreret.
Hvad angår automatiseringen — et enkelt program kan læse miljøvariabler, der angiver dets driftsmåde, eller det har et veludviklet CLI, der fuldstændigt kan duplikere adfærden ved at arbejde gennem webinterfacet, for eksempel. Dette inkluderer også muligheden for streamingoperationer, tilstedeværelsen af udvidelsesmuligheder osv.
Universelt
Delvistoret overlap med det forrige afsnit vedrørende automatisering, bør det ikke være noget problem at "integrere" backup-processen i den eksisterende infrastruktur.
Det skal bemærkes, at brugen af ikke-standardporte (bortset fra webgrænsefladen) til arbejde, implementeringen af kryptering på ikke-standard måde, og dataudveksling via ikke-standardprotokoller — er tegn på en ikke-universel løsning. For det meste har alle kandidater dem på den ene eller den anden måde af åbenlyse grunde: enkelhed og universalitet er normalt ikke forenelige. Som undtagelse — burp, der findes også andre.
Som et tegn — muligheden for at arbejde ved at bruge almindelig ssh.
Hastigheden af arbejdet
Det mest kontroversielle og diskutable punkt. På den ene side — processe blev startet, den arbejdede så hurtigt som muligt og forstyrrede ikke de primære opgaver. På den anden side — et bump i trafik og CPU-belastning under backup. Det skal også bemærkes, at de hurtigste programmer til at tage kopier ofte er de fattigste i funktioner, der er vigtige for brugerne. Igen: hvis det er nødvendigt at hente en enkelt ulykkelig tekstfil på nogle få dusin bytes med et password, og hele tjenesten står på spil (ja, jeg forstår, at backup-processen sjældent er skyld i dette), og man skal læse alle filer i repositoriet sekventielt eller udrulle et helt arkiv — så er backup-systemet på ingen måde hurtigt. En anden punkt, der ofte bliver en hindring — hastigheden ved at gendanne backup fra arkivet. Her har dem, der blot kan kopiere eller flytte filer til det rette sted uden særlig manipulation (f.eks. rsync), en klar fordel, men oftest skal problemet løses organisatorisk og empirisk: måle tiden til gendannelse af backup og åbent informere brugerne om dette.
Stabilitet
Det skal forstås sådan: på den ene side skal det være muligt at gendanne en backup på enhver måde, på den anden side — modstandsdygtighed over for forskellige problemer: netværksafbrydelse, diskfejl, sletning af dele af depotet.
Sammenligning af backupværktøjer
Tid til oprettelse af kopi
Tid til gendannelse af kopi
Nem installation
Enkel opsætning
Enkel brug
Simpel automatisering
Er en klient-server nødvendig?
Repository integritetskontrol
Differentialkopier
Arbejder via pipe
Universelt
Selvstændighed
Repository transparens
Kryptering
Komprimering
Deduplicering
Web-interface
Upload til skyen
Windows-support
Point
Rsync
4m15s
4m28s
ja
nej
nej
nej
ja
nej
nej
ja
nej
ja
ja
nej
nej
nej
nej
nej
ja
6
Tar
pure
3m12s
2m43s
ja
nej
nej
nej
nej
nej
ja
ja
nej
ja
nej
nej
nej
nej
nej
nej
ja
8,5
gzip
9m37s
3m19s
ja
Rdiff-backup
16m26s
17m17s
ja
ja
ja
ja
ja
nej
ja
nej
ja
nej
ja
nej
ja
ja
ja
nej
ja
11
Rsnapshot
4m19s
4m28s
ja
ja
ja
ja
nej
nej
ja
nej
ja
nej
ja
nej
nej
ja
ja
nej
ja
12,5
Burp
11m9s
7m2s
ja
nej
ja
ja
ja
ja
ja
nej
ja
ja
nej
nej
ja
nej
ja
nej
ja
10,5
Duplicity
ingen kryptering
16m48s
10m58s
ja
ja
nej
ja
nej
ja
ja
nej
nej
ja
nej
ja
ja
nej
ja
nej
ja
11
gpg
17m27s
15m3s
Duplicati
ingen kryptering
20m28s
13m45s
nej
ja
nej
nej
nej
ja
ja
nej
nej
ja
nej
ja
ja
ja
ja
ja
ja
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
ingen kryptering
40m3s
11m8s
ja
ja
nej
nej
nej
ja
ja
ja
nej
ja
nej
ja
ja
ja
nej
nej
nej
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
ingen kryptering
4m7s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nej
ja
ja
ja
ja
nej
ja
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
ja
ja
ja
ja
nej
ja
ja
ja
ja
ja
nej
ja
nej
ja
nej
ja
ja
15,5
UrBackup
8m21s
8m19s
ja
ja
ja
nej
ja
nej
ja
nej
ja
ja
nej
ja
ja
ja
ja
nej
ja
12
Amanda
9m3s
2m49s
ja
nej
nej
ja
ja
ja
ja
nej
ja
ja
ja
ja
ja
nej
ja
ja
ja
13
BackupPC
rsync
12m22s
7m42s
ja
nej
ja
ja
ja
ja
ja
nej
ja
nej
nej
ja
ja
nej
ja
nej
ja
10,5
tar
12m34s
12m15s
Tabellegende:
- Grøn, oppetid under fem minutter, eller svar 'Ja' (undtagen for kolonnen 'Er klient-server nødvendig?'), 1 point
- Gul, oppetid fem-ti minutter, 0.5 point
- Rød, oppetid over ti minutter, eller svar 'Nej' (undtagen for kolonnen 'Er klient-server nødvendig?'), 0 point
I henhold til den ovenfor nævnte tabel er BorgBackup det mest simple, hurtige og samtidig brugervenlige og kraftfulde værktøj til backup. Andenpladsen blev taget af Restic, de øvrige overvejede kandidater lå omtrent ens med en spredning på en-to point i slutningen.
Jeg takker alle, der har læst cyklussen til ende, og jeg foreslår at diskutere muligheder, tilbyde egne, hvis der er nogen. Efterhånden som diskussionen skrider frem, kan tabellen blive suppleret.
Resultatet af cyklussen vil være en afsluttende artikel, hvor der vil blive forsøgt at udarbejde det ideelle, hurtige og håndterbare middel til backup, der muliggør hurtig gendannelse af en kopi og samtidig tilbyder brugervenlighed og enkel opsætning og vedligeholdelse.
Annonce
Sikkerhedskopiering, del 6: Sammenligning af sikkerhedskopieringsværktøjer
Backup, del 7: Konklusioner
Kilde: habr.com
