Denne artikel vil sammenligne værktøjer til sikkerhedskopiering, men først skal du finde ud af, hvor hurtigt og godt de klarer at gendanne data fra sikkerhedskopier.
For at lette sammenligningen vil vi overveje at gendanne fra en fuld sikkerhedskopi, især da alle kandidater understøtter denne funktionsmåde. For nemheds skyld er tallene allerede beregnet som gennemsnit (det aritmetiske gennemsnit af flere kørsler). Resultaterne vil blive opsummeret i en tabel, som også vil indeholde oplysninger om mulighederne: tilstedeværelsen af en webgrænseflade, nem opsætning og betjening, evnen til at automatisere, tilstedeværelsen af forskellige yderligere funktioner (for eksempel kontrol af dataintegritet) , etc. Graferne viser belastningen på serveren, hvor dataene skal bruges (ikke serveren til lagring af sikkerhedskopier).
Datagendannelse
rsync og tar vil blive brugt som referencepunkt siden simple scripts til at lave sikkerhedskopier.
rsync klarede testdatasættet på 4 minutter og 28 sekunder, viser
sådan en belastning
Gendannelsesprocessen ramte en begrænsning af diskundersystemet på backup-lagerserveren (savtand-grafer). Du kan også tydeligt se indlæsningen af en kerne uden problemer (lav iowait og softirq - ingen problemer med henholdsvis disken og netværket). Da de to andre programmer, nemlig rdiff-backup og rsnapshot, er baseret på rsync og også tilbyder almindelig rsync som et gendannelsesværktøj, vil de have omtrent samme indlæsningsprofil og backup-gendannelsestid.
Tar fik det gjort lidt hurtigere
2 minutter og 43 sekunder:
Den samlede systembelastning var i gennemsnit højere med 20% på grund af den øgede softirq - de overheadomkostninger under driften af netværksundersystemet steg.
Hvis arkivet komprimeres yderligere, øges genoprettelsestiden til 3 minutter og 19 sekunder.
med en sådan belastning på hovedserveren (udpakning på siden af hovedserveren):
Dekompressionsprocessen optager begge processorkerner, fordi der er to processer, der kører. Generelt er dette det forventede resultat. Der blev også opnået et sammenligneligt resultat (3 minutter og 20 sekunder), når man kørte gzip på serversiden med backups; belastningsprofilen på hovedserveren lignede meget at køre tar uden gzip-kompressoren (se forrige graf).
В rdiff-backup du kan synkronisere den sidste sikkerhedskopi, du lavede ved hjælp af almindelig rsync (resultaterne vil være ens), men ældre sikkerhedskopier skal stadig gendannes ved hjælp af rdiff-backup-programmet, som fuldførte gendannelsen på 17 minutter og 17 sekunder, viser
denne belastning:
Måske var det meningen, i det mindste at begrænse forfatternes hastighed . Processen med at gendanne en sikkerhedskopi i sig selv tager lidt mindre end halvdelen af en kerne, med forholdsmæssigt sammenlignelig ydeevne (dvs. 2-5 gange langsommere) over disk og netværk med rsync.
Rsnapshot Til gendannelse foreslår det at bruge almindelig rsync, så resultaterne vil være ens. Generelt er det sådan, det blev.
Bøvse Jeg fuldførte opgaven med at gendanne en sikkerhedskopi på 7 minutter og 2 sekunder med
med denne belastning:
Det fungerede ret hurtigt, og i det mindste er det meget mere praktisk end ren rsync: du behøver ikke at huske nogen flag, en enkel og intuitiv cli-grænseflade, indbygget understøttelse af flere kopier - selvom det er to gange langsommere. Hvis du har brug for at gendanne data fra den sidste sikkerhedskopi, du lavede, kan du bruge rsync, med nogle få forbehold.
Programmet viste omtrent samme hastighed og belastning BackupPC når du aktiverer rsync-overførselstilstand, implementerer sikkerhedskopien til
7 minutter og 42 sekunder:
Men i dataoverførselstilstand klarede BackupPC tjære langsommere: på 12 minutter og 15 sekunder var processorbelastningen generelt lavere
halvanden gang:
Duplicity uden kryptering viste lidt bedre resultater, og genoprettede en sikkerhedskopi på 10 minutter og 58 sekunder. Hvis du aktiverer kryptering ved hjælp af gpg, øges gendannelsestiden til 15 minutter og 3 sekunder. Når du opretter et lager til lagring af kopier, kan du også angive den arkivstørrelse, der skal bruges ved opdeling af den indgående datastrøm. Generelt er der på konventionelle harddiske, også på grund af den enkelt-trådede driftstilstand, ikke den store forskel. Det kan forekomme i forskellige blokstørrelser, når der bruges hybridlagring. Belastningen på hovedserveren under gendannelse var som følger:
ingen kryptering
med kryptering
Duplikere viste en sammenlignelig genopretningshastighed og fuldførte den på 13 minutter og 45 sekunder. Det tog omkring yderligere 5 minutter at kontrollere rigtigheden af de gendannede data (i alt omkring 19 minutter). Belastningen var
ret høj:
Når aes-kryptering var aktiveret internt, var gendannelsestiden 21 minutter og 40 sekunder, med CPU-udnyttelse på sit maksimum (begge kerner!) under gendannelse; Ved kontrol af data var kun én tråd aktiv, der optog én processorkerne. Kontrol af data efter gendannelse tog de samme 5 minutter (næsten 27 minutter i alt).
Outcome
duplicati var lidt hurtigere med gendannelse ved brug af det eksterne gpg-program til kryptering, men generelt er forskellene fra den tidligere tilstand minimale. Driftstiden var 16 minutter og 30 sekunder, med databekræftelse på 6 minutter. Belastningen var
sådan:
AMANDA, ved hjælp af tjære, gennemførte det på 2 minutter og 49 sekunder, hvilket i princippet er meget tæt på almindelig tjære. Belastning på systemet i princippet
det samme:
Ved gendannelse af en sikkerhedskopi vha zbackup følgende resultater blev opnået:
kryptering, lzma-komprimering
Spilletid 11 minutter og 8 sekunder
AES-kryptering, lzma-komprimering
Driftstid 14 minutter
AES-kryptering, lzo-komprimering
Spilletid 6 minutter, 19 sekunder
Samlet set ikke dårligt. Det hele afhænger af processorens hastighed på backupserveren, hvilket tydeligt kan ses af programmets køretid med forskellige kompressorer. På backup-serversiden blev en almindelig tar lanceret, så hvis du sammenligner den med den, er gendannelsen 3 gange langsommere. Det kan være værd at tjekke driften i multi-threaded mode, med mere end to tråde.
BorgBackup i ukrypteret tilstand var det lidt langsommere end tjære, på 2 minutter og 45 sekunder, men i modsætning til tjære, blev det muligt at deduplikere depotet. Belastningen viste sig at være
det følgende:
Hvis du aktiverer blake-baseret kryptering, er backupgendannelseshastigheden lidt langsommere. Restitutionstid i denne tilstand er 3 minutter og 19 sekunder, og belastningen er væk
sådan her:
AES-kryptering er lidt langsommere, genoprettelsestiden er 3 minutter 23 sekunder, belastningen er især
har ikke ændret sig:
Da Borg kan arbejde i multi-threaded mode, er processorbelastningen maksimal, og når yderligere funktioner aktiveres, øges driftstiden simpelthen. Tilsyneladende er det værd at udforske multithreading på samme måde som zbackup.
Restic klarede opsvinget lidt langsommere, driftstiden var 4 minutter 28 sekunder. Ladningen så ud
som dette:
Tilsyneladende fungerer gendannelsesprocessen i flere tråde, men effektiviteten er ikke så høj som BorgBackups, men tidsmæssigt sammenlignelig med almindelig rsync.
Med urBackup Det var muligt at gendanne dataene på 8 minutter og 19 sekunder, belastningen var
sådan:
Belastningen er stadig ikke særlig høj, endda lavere end tjærens. Nogle steder er der sprængninger, men ikke mere end belastningen af en kerne.
Udvælgelse og begrundelse af kriterier for sammenligning
Som det fremgår af en af de foregående artikler, skal backupsystemet opfylde følgende kriterier:
- Brugervenlighed
- Alsidighed
- Stabilitet
- hurtighed
Det er værd at overveje hvert punkt separat mere detaljeret.
Nem betjening
Det er bedst, når der er én knap "Gør alt godt", men hvis du vender tilbage til rigtige programmer, vil den mest bekvemme ting være et velkendt og standarddriftsprincip.
De fleste brugere vil højst sandsynligt have det bedre, hvis de ikke skal huske en masse nøgler til cli, konfigurere en masse forskellige, ofte obskure muligheder via web eller tui, eller konfigurere notifikationer om mislykket betjening. Dette inkluderer også muligheden for nemt at "passe" en backup-løsning ind i den eksisterende infrastruktur, samt automatisering af backup-processen. Der er også mulighed for installation ved hjælp af en pakkehåndtering, eller i en eller to kommandoer som "download og udpak". curl ссылка | sudo bash - en kompleks metode, da du skal tjekke, hvad der ankommer via linket.
For eksempel, af de overvejede kandidater, er en simpel løsning burp, rdiff-backup og restic, som har mnemoniske nøgler til forskellige driftstilstande. Lidt mere komplekse er borg og dobbelthed. Den sværeste var AMANDA. Resten ligger et sted i midten med hensyn til brugervenlighed. Under alle omstændigheder, hvis du har brug for mere end 30 sekunder til at læse brugervejledningen, eller du skal gå til Google eller en anden søgemaskine og også rulle gennem et langt ark med hjælp, er beslutningen svær, på den ene eller den anden måde.
Nogle af de overvejede kandidater er i stand til automatisk at sende en besked via e-mailjabber, mens andre er afhængige af konfigurerede alarmer i systemet. Desuden har komplekse løsninger oftest ikke helt åbenlyse alarmindstillinger. Under alle omstændigheder, hvis sikkerhedskopieringsprogrammet producerer en returkode, der ikke er nul, som vil blive korrekt forstået af systemtjenesten for periodiske opgaver (en besked sendes til systemadministratoren eller direkte til overvågning) - er situationen enkel. Men hvis backup-systemet, som ikke kører på en backup-server, ikke kan konfigureres, er den indlysende måde at sige om problemet på, at kompleksiteten allerede er for stor. Under alle omstændigheder er det en dårlig praksis at udstede advarsler og andre meddelelser kun til webgrænsefladen eller til loggen, da de oftest vil blive ignoreret.
Hvad angår automatisering, kan et simpelt program læse miljøvariabler, der indstiller dens driftstilstand, eller det har en udviklet cli, der fuldstændigt kan duplikere adfærden, når man arbejder gennem en webgrænseflade, for eksempel. Dette omfatter også mulighed for kontinuerlig drift, tilgængelighed af udvidelsesmuligheder mv.
Alsidighed
Til dels i overensstemmelse med det foregående underafsnit vedrørende automatisering, burde det ikke være et særligt problem at "passe" backup-processen ind i den eksisterende infrastruktur.
Det er værd at bemærke, at brugen af ikke-standardporte (godt, bortset fra webgrænsefladen) til arbejde, implementering af kryptering på en ikke-standard måde, udveksling af data ved hjælp af en ikke-standard protokol er tegn på en ikke-standardiseret protokol. -universel løsning. For det meste har alle kandidater dem på den ene eller anden måde af den indlysende grund: Enkelhed og alsidighed hænger normalt ikke sammen. Som en undtagelse - bøvs, der er andre.
Som et tegn - evnen til at arbejde ved hjælp af almindelig ssh.
Arbejdshastighed
Det mest kontroversielle og kontroversielle punkt. På den ene side lancerede vi processen, den fungerede så hurtigt som muligt og forstyrrede ikke hovedopgaverne. På den anden side er der en stigning i trafik og processorbelastning under backupperioden. Det er også værd at bemærke, at de hurtigste programmer til at lave kopier normalt er de dårligste med hensyn til funktioner, der er vigtige for brugerne. Igen: hvis for at få en uheldig tekstfil på flere titus bytes i størrelse med en adgangskode, og på grund af det hele tjenesten koster (ja, ja, jeg forstår, at backup-processen oftest ikke er skyld her), og du skal genlæse sekventielt alle filerne i depotet eller udvide hele arkivet - backup-systemet er aldrig hurtigt. Et andet punkt, der ofte bliver en anstødssten, er hastigheden af at implementere en sikkerhedskopi fra et arkiv. Der er en klar fordel her for dem, der blot kan kopiere eller flytte filer til den ønskede placering uden megen manipulation (f.eks. rsync), men som oftest skal problemet løses på en organisatorisk måde, empirisk: ved at måle backup-gendannelsestiden og åbent informere brugerne om dette.
Stabilitet
Det skal forstås sådan: på den ene side skal det være muligt at installere sikkerhedskopien tilbage på en hvilken som helst måde, på den anden side skal den være modstandsdygtig over for forskellige problemer: netværksafbrydelse, diskfejl, sletning af en del af depot.
Sammenligning af sikkerhedskopieringsværktøjer
Tidspunkt for oprettelse af kopi
Kopier genoprettelsestiden
Nem installation
Nem opsætning
Enkel brug
Simpel automatisering
Har du brug for en klientserver?
Kontrol af depotets integritet
Differentielle kopier
Arbejder via rør
Alsidighed
Uafhængighed
Repository gennemsigtighed
kryptering
kompression
Deduplikation
Webgrænseflade
Fylder til skyen
Windows support
mark
rsync
4m15s
4m28s
ja
ingen
ingen
ingen
ja
ingen
ingen
ja
ingen
ja
ja
ingen
ingen
ingen
ingen
ingen
ja
6
Tar
ren
3m12s
2m43s
ja
ingen
ingen
ingen
ingen
ingen
ja
ja
ingen
ja
ingen
ingen
ingen
ingen
ingen
ingen
ja
8,5
gzip
9m37s
3m19s
ja
Rdiff-backup
16m26s
17m17s
ja
ja
ja
ja
ja
ingen
ja
ingen
ja
ingen
ja
ingen
ja
ja
ja
ingen
ja
11
Rsnapshot
4m19s
4m28s
ja
ja
ja
ja
ingen
ingen
ja
ingen
ja
ingen
ja
ingen
ingen
ja
ja
ingen
ja
12,5
Bøvse
11m9s
7m2s
ja
ingen
ja
ja
ja
ja
ja
ingen
ja
ja
ingen
ingen
ja
ingen
ja
ingen
ja
10,5
Duplicity
ingen kryptering
16m48s
10m58s
ja
ja
ingen
ja
ingen
ja
ja
ingen
ingen
ja
ingen
ja
ja
ingen
ja
ingen
ja
11
gpg
17m27s
15m3s
Duplikere
ingen kryptering
20m28s
13m45s
ingen
ja
ingen
ingen
ingen
ja
ja
ingen
ingen
ja
ingen
ja
ja
ja
ja
ja
ja
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
ingen kryptering
40m3s
11m8s
ja
ja
ingen
ingen
ingen
ja
ja
ja
ingen
ja
ingen
ja
ja
ja
ingen
ingen
ingen
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
ingen kryptering
4m7s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ingen
ja
ja
ja
ja
ingen
ja
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
ja
ja
ja
ja
ingen
ja
ja
ja
ja
ja
ingen
ja
ingen
ja
ingen
ja
ja
15,5
urBackup
8m21s
8m19s
ja
ja
ja
ingen
ja
ingen
ja
ingen
ja
ja
ingen
ja
ja
ja
ja
ingen
ja
12
Amanda
9m3s
2m49s
ja
ingen
ingen
ja
ja
ja
ja
ingen
ja
ja
ja
ja
ja
ingen
ja
ja
ja
13
BackupPC
rsync
12m22s
7m42s
ja
ingen
ja
ja
ja
ja
ja
ingen
ja
ingen
ingen
ja
ja
ingen
ja
ingen
ja
10,5
tjære
12m34s
12m15s
Tabelforklaring:
- Grøn, driftstid mindre end fem minutter, eller svar "Ja" (bortset fra kolonnen "Har du brug for en klientserver?"), 1 point
- Gul, driftstid fem til ti minutter, 0.5 point
- Rød, arbejdstiden er mere end ti minutter, eller svaret er "Nej" (bortset fra kolonnen "Har du brug for en klientserver?"), 0 point
Ifølge tabellen ovenfor er det enkleste, hurtigste og samtidig bekvemme og kraftfulde backupværktøj BorgBackup. Restic indtog andenpladsen, resten af de overvejede kandidater blev placeret nogenlunde ligeligt med en spredning på et eller to point til sidst.
Jeg takker alle, der læser serien til slutningen, jeg inviterer dig til at diskutere mulighederne og tilbyde dine egne, hvis nogen. Efterhånden som diskussionen skrider frem, kan tabellen blive udvidet.
Resultatet af serien bliver den sidste artikel, hvor der vil blive forsøgt at udvikle et ideelt, hurtigt og overskueligt backupværktøj, der giver dig mulighed for at implementere en kopi tilbage på kortest mulig tid og samtidig være bekvemt og nemt. at konfigurere og vedligeholde.
annoncering
Sikkerhedskopiering Del 6: Sammenligning af sikkerhedskopieringsværktøjer
Backup Del 7: Konklusioner
Kilde: www.habr.com