Denne artikkelen vil sammenligne sikkerhetskopieringsverktøy, men først bør du finne ut hvor raskt og godt de takler å gjenopprette data fra sikkerhetskopier.
For enkel sammenligning vil vi vurdere å gjenopprette fra en fullstendig sikkerhetskopi, spesielt siden alle kandidater støtter denne driftsmodusen. For enkelhets skyld er tallene allerede beregnet (det aritmetiske gjennomsnittet av flere kjøringer). Resultatene vil bli oppsummert i en tabell, som også vil inneholde informasjon om mulighetene: tilstedeværelsen av et webgrensesnitt, enkel oppsett og betjening, evnen til å automatisere, tilstedeværelsen av ulike tilleggsfunksjoner (for eksempel sjekke dataintegritet) , etc. Grafene vil vise belastningen på serveren der dataene skal brukes (ikke serveren for lagring av sikkerhetskopier).
Datarekonstruksjon
rsync og tar vil bli brukt som referansepunkt siden enkle skript for å lage sikkerhetskopier.
rsync taklet testdatasettet på 4 minutter og 28 sekunder, viser
en slik belastning
Gjenopprettingsprosessen traff en begrensning av diskundersystemet til backuplagringsserveren (sagtanngrafer). Du kan også tydelig se lasting av én kjerne uten problemer (lav iowait og softirq - ingen problemer med henholdsvis disken og nettverket). Siden de to andre programmene, nemlig rdiff-backup og rsnapshot, er basert på rsync og også tilbyr vanlig rsync som gjenopprettingsverktøy, vil de ha omtrent samme lasteprofil og gjenopprettingstid for backup.
Tjære fikk det gjort litt raskere
2 minutter og 43 sekunder:
Den totale systembelastningen var gjennomsnittlig høyere med 20 % på grunn av den økte softirq - overheadkostnadene under driften av nettverksdelsystemet økte.
Hvis arkivet komprimeres ytterligere, øker gjenopprettingstiden til 3 minutter 19 sekunder.
med en slik belastning på hovedserveren (utpakking på siden av hovedserveren):
Utpakkingsprosessen tar opp begge prosessorkjernene fordi det er to prosesser som kjører. Generelt er dette det forventede resultatet. Også et sammenlignbart resultat (3 minutter og 20 sekunder) ble oppnådd når du kjører gzip på serversiden med sikkerhetskopier; lasteprofilen på hovedserveren var veldig lik å kjøre tar uten gzip-kompressoren (se forrige graf).
В rdiff-sikkerhetskopi du kan synkronisere den siste sikkerhetskopien du tok med vanlig rsync (resultatene vil være like), men eldre sikkerhetskopier må fortsatt gjenopprettes ved å bruke rdiff-backup-programmet, som fullførte gjenopprettingen på 17 minutter og 17 sekunder, viser
denne lasten:
Kanskje var dette ment, i det minste for å begrense hastigheten til forfatterne . Selve prosessen med å gjenopprette en sikkerhetskopi tar litt mindre enn halvparten av én kjerne, med proporsjonalt sammenlignbar ytelse (dvs. 2-5 ganger tregere) over disk og nettverk med rsync.
Rsnapshot For gjenoppretting foreslår det å bruke vanlig rsync, så resultatene vil være like. Generelt ble det slik.
Å rape Jeg fullførte oppgaven med å gjenopprette en sikkerhetskopi på 7 minutter og 2 sekunder med
med denne lasten:
Det fungerte ganske raskt, og er i det minste mye mer praktisk enn ren rsync: du trenger ikke å huske noen flagg, et enkelt og intuitivt cli-grensesnitt, innebygd støtte for flere kopier - selv om det er to ganger tregere. Hvis du trenger å gjenopprette data fra den siste sikkerhetskopien du gjorde, kan du bruke rsync, med noen få forbehold.
Programmet viste omtrent samme hastighet og belastning BackupPC når du aktiverer rsync-overføringsmodus, distribuerer sikkerhetskopien for
7 minutter og 42 sekunder:
Men i dataoverføringsmodus taklet BackupPC tjære saktere: på 12 minutter og 15 sekunder var prosessorbelastningen generelt lavere
en og en halv gang:
Duplicity uten kryptering viste litt bedre resultater, og gjenopprettet en sikkerhetskopi på 10 minutter og 58 sekunder. Hvis du aktiverer kryptering ved hjelp av gpg, øker gjenopprettingstiden til 15 minutter og 3 sekunder. Når du oppretter et depot for lagring av kopier, kan du også spesifisere arkivstørrelsen som skal brukes ved splitting av den innkommende datastrømmen. Generelt, på konvensjonelle harddisker, også på grunn av den entrådede driftsmodusen, er det ikke mye forskjell. Det kan vises ved forskjellige blokkstørrelser når hybridlagring brukes. Belastningen på hovedserveren under gjenoppretting var som følger:
ingen kryptering
med kryptering
Duplicati viste en sammenlignbar utvinningsgrad, og fullførte den på 13 minutter og 45 sekunder. Det tok omtrent ytterligere 5 minutter å kontrollere riktigheten av de gjenopprettede dataene (totalt ca. 19 minutter). Lasten var
ganske høy:
Når aes-kryptering ble aktivert internt, var gjenopprettingstiden 21 minutter og 40 sekunder, med CPU-utnyttelse på sitt maksimale (begge kjerner!) under gjenoppretting; Når du sjekket data, var bare én tråd aktiv, som okkuperte én prosessorkjerne. Å sjekke dataene etter gjenoppretting tok de samme 5 minuttene (nesten 27 minutter totalt).
Resultat
duplicati var litt raskere med gjenoppretting ved bruk av det eksterne gpg-programmet for kryptering, men generelt er forskjellene fra forrige modus minimale. Driftstiden var 16 minutter 30 sekunder, med dataverifisering på 6 minutter. Lasten var
er som følger:
AMANDA, med tjære, fullførte det på 2 minutter og 49 sekunder, som i prinsippet er veldig nær vanlig tjære. Belastning på systemet i prinsippet
det samme:
Når du gjenoppretter en sikkerhetskopi ved hjelp av zbackup følgende resultater ble oppnådd:
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
Totalt sett ikke dårlig. Alt avhenger av hastigheten til prosessoren på backupserveren, som tydelig kan sees fra kjøretiden til programmet med forskjellige kompressorer. På backupserversiden ble det lansert en vanlig tar, så hvis du sammenligner den med den, er gjenopprettingen 3 ganger tregere. Det kan være verdt å sjekke operasjonen i flertrådsmodus, med mer enn to tråder.
BorgBackup i ukryptert modus var det litt tregere enn tjære, på 2 minutter og 45 sekunder, men i motsetning til tjære, ble det mulig å deduplisere depotet. Lasten viste seg å være
følgende:
Hvis du aktiverer blake-basert kryptering, er sikkerhetskopieringshastigheten litt lavere. Gjenopprettingstid i denne modusen er 3 minutter og 19 sekunder, og belastningen er borte
som dette:
AES-kryptering er litt tregere, gjenopprettingstiden er 3 minutter 23 sekunder, belastningen er spesielt
har ikke endret seg:
Siden Borg kan fungere i flertrådsmodus, er prosessorbelastningen maksimal, og når tilleggsfunksjoner aktiveres, øker driftstiden ganske enkelt. Tilsynelatende er det verdt å utforske multithreading på en lignende måte som zbackup.
Restic taklet restitusjonen litt saktere, driftstiden var 4 minutter 28 sekunder. Lasten så ut som
som følger:
Tilsynelatende fungerer gjenopprettingsprosessen i flere tråder, men effektiviteten er ikke like høy som BorgBackup, men kan sammenlignes i tid med vanlig rsync.
Med urBackup Det var mulig å gjenopprette dataene på 8 minutter og 19 sekunder, belastningen var
er som følger:
Belastningen er fortsatt ikke særlig høy, enda lavere enn tjære. Noen steder er det sprengninger, men ikke mer enn belastningen av en kjerne.
Utvalg og begrunnelse av kriterier for sammenligning
Som det fremgår av en av de foregående artiklene, må sikkerhetskopieringssystemet oppfylle følgende kriterier:
- Brukervennlighet
- allsidighet
- stabilitet
- Hurtighet
Det er verdt å vurdere hvert punkt separat i mer detalj.
Enkel betjening
Det er best når det er én knapp "Gjør alt bra", men hvis du går tilbake til ekte programmer, vil det mest praktiske være et kjent og standard driftsprinsipp.
De fleste brukere vil mest sannsynlig ha det bedre hvis de ikke trenger å huske en haug med nøkler for cli, konfigurere en haug med forskjellige, ofte obskure alternativer via web eller tui, eller sette opp varsler om mislykket drift. Dette inkluderer også muligheten til enkelt å "passe" en backup-løsning inn i den eksisterende infrastrukturen, samt automatisering av backup-prosessen. Det er også mulighet for installasjon ved hjelp av en pakkebehandling, eller i en eller to kommandoer som "last ned og pakke ut". curl ссылка | sudo bash - en kompleks metode, siden du må sjekke hva som kommer via lenken.
For eksempel, av de vurderte kandidatene, er en enkel løsning burp, rdiff-backup og restic, som har mnemoniske nøkler for forskjellige driftsmoduser. Litt mer komplekse er borg og dobbelthet. Den vanskeligste var AMANDA. Resten ligger et sted i midten når det gjelder brukervennlighet. I alle fall, hvis du trenger mer enn 30 sekunder på å lese brukermanualen, eller du må gå til Google eller en annen søkemotor, og også bla gjennom et langt ark med hjelp, er avgjørelsen vanskelig, på en eller annen måte.
Noen av kandidatene som vurderes kan automatisk sende en melding via e-postjabber, mens andre er avhengige av konfigurerte varsler i systemet. Dessuten har oftest komplekse løsninger ikke helt åpenbare varslingsinnstillinger. I alle fall, hvis sikkerhetskopieringsprogrammet produserer en returkode som ikke er null, som vil bli korrekt forstått av systemtjenesten for periodiske oppgaver (en melding vil bli sendt til systemadministratoren eller direkte til overvåking) - er situasjonen enkel. Men hvis backup-systemet, som ikke kjører på en backup-server, ikke kan konfigureres, er den åpenbare måten å si om problemet på at kompleksiteten allerede er overdreven. I alle fall er det en dårlig praksis å gi advarsler og andre meldinger kun til nettgrensesnittet eller til loggen, siden de oftest vil bli ignorert.
Når det gjelder automatisering, kan et enkelt program lese miljøvariabler som setter dens driftsmodus, eller det har en utviklet cli som kan fullstendig duplisere atferden når du arbeider gjennom et nettgrensesnitt, for eksempel. Dette inkluderer også mulighet for kontinuerlig drift, tilgjengelighet av utvidelsesmuligheter mv.
allsidighet
Som delvis gjenspeiler forrige underseksjon angående automatisering, burde det ikke være et spesielt problem å "passe" sikkerhetskopieringsprosessen inn i den eksisterende infrastrukturen.
Det er verdt å merke seg at bruken av ikke-standardiserte porter (vel, bortsett fra nettgrensesnittet) for arbeid, implementering av kryptering på en ikke-standard måte, utveksling av data ved hjelp av en ikke-standard protokoll er tegn på en ikke-standard protokoll. -universell løsning. For det meste har alle kandidater dem på en eller annen måte av den åpenbare grunnen: Enkelhet og allsidighet går vanligvis ikke sammen. Som et unntak - burp, det er andre.
Som et tegn - evnen til å jobbe med vanlig ssh.
Arbeidshastighet
Det mest kontroversielle og kontroversielle punktet. På den ene siden startet vi prosessen, den fungerte så raskt som mulig og forstyrret ikke hovedoppgavene. På den annen side er det en økning i trafikk og prosessorbelastning under sikkerhetskopieringsperioden. Det er også verdt å merke seg at de raskeste programmene for å lage kopier vanligvis er de dårligste når det gjelder funksjoner som er viktige for brukerne. Igjen: hvis for å få en uheldig tekstfil på flere titalls byte i størrelse med et passord, og på grunn av det hele tjenesten koster (ja, ja, jeg forstår at sikkerhetskopieringsprosessen oftest ikke har skylden her), og du må lese sekvensielt alle filene i depotet eller utvide hele arkivet - sikkerhetskopieringssystemet er aldri raskt. Et annet punkt som ofte blir en snublestein er hastigheten på å distribuere en sikkerhetskopi fra et arkiv. Det er en klar fordel her for de som ganske enkelt kan kopiere eller flytte filer til ønsket plassering uten mye manipulasjon (rsync, for eksempel), men som oftest må problemet løses på en organisatorisk måte, empirisk: ved å måle gjenopprettingstiden for backup og åpent informere brukere om dette.
stabilitet
Det skal forstås slik: på den ene siden må det være mulig å distribuere sikkerhetskopien tilbake på en hvilken som helst måte, på den annen side må den være motstandsdyktig mot ulike problemer: nettverksavbrudd, diskfeil, sletting av deler av oppbevaringssted.
Sammenligning av sikkerhetskopieringsverktøy
Tidspunkt for oppretting av kopier
Kopier gjenopprettingstiden
Enkel installasjon
Enkelt oppsett
Enkel bruk
Enkel automatisering
Trenger du en klientserver?
Kontrollerer integriteten til depotet
Differensielle kopier
Arbeider via rør
allsidighet
Uavhengighet
Repository åpenhet
Kryptering
Kompresjon
Deduplisering
Webgrensesnitt
Fyller til skyen
Støtte Windows
mark
rsync
4m15s
4m28s
ja
ikke
ikke
ikke
ja
ikke
ikke
ja
ikke
ja
ja
ikke
ikke
ikke
ikke
ikke
ja
6
Tjære
ren
3m12s
2m43s
ja
ikke
ikke
ikke
ikke
ikke
ja
ja
ikke
ja
ikke
ikke
ikke
ikke
ikke
ikke
ja
8,5
gzip
9m37s
3m19s
ja
Rdiff-backup
16m26s
17m17s
ja
ja
ja
ja
ja
ikke
ja
ikke
ja
ikke
ja
ikke
ja
ja
ja
ikke
ja
11
Rsnapshot
4m19s
4m28s
ja
ja
ja
ja
ikke
ikke
ja
ikke
ja
ikke
ja
ikke
ikke
ja
ja
ikke
ja
12,5
Å rape
11m9s
7m2s
ja
ikke
ja
ja
ja
ja
ja
ikke
ja
ja
ikke
ikke
ja
ikke
ja
ikke
ja
10,5
Duplicity
ingen kryptering
16m48s
10m58s
ja
ja
ikke
ja
ikke
ja
ja
ikke
ikke
ja
ikke
ja
ja
ikke
ja
ikke
ja
11
gpg
17m27s
15m3s
Duplicati
ingen kryptering
20m28s
13m45s
ikke
ja
ikke
ikke
ikke
ja
ja
ikke
ikke
ja
ikke
ja
ja
ja
ja
ja
ja
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
zbackup
ingen kryptering
40m3s
11m8s
ja
ja
ikke
ikke
ikke
ja
ja
ja
ikke
ja
ikke
ja
ja
ja
ikke
ikke
ikke
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
ingen kryptering
4m7s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ikke
ja
ja
ja
ja
ikke
ja
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
ja
ja
ja
ja
ikke
ja
ja
ja
ja
ja
ikke
ja
ikke
ja
ikke
ja
ja
15,5
urBackup
8m21s
8m19s
ja
ja
ja
ikke
ja
ikke
ja
ikke
ja
ja
ikke
ja
ja
ja
ja
ikke
ja
12
Amanda
9m3s
2m49s
ja
ikke
ikke
ja
ja
ja
ja
ikke
ja
ja
ja
ja
ja
ikke
ja
ja
ja
13
BackupPC
rsync
12m22s
7m42s
ja
ikke
ja
ja
ja
ja
ja
ikke
ja
ikke
ikke
ja
ja
ikke
ja
ikke
ja
10,5
tjære
12m34s
12m15s
Tabellforklaring:
- Grønn, driftstid mindre enn fem minutter, eller svar "Ja" (bortsett fra kolonnen "Trenger du en klientserver?"), 1 poeng
- Gul, driftstid fem til ti minutter, 0.5 poeng
- Rød, arbeidstiden er mer enn ti minutter, eller svaret er "Nei" (bortsett fra kolonnen "Trenger du en klientserver?"), 0 poeng
I følge tabellen ovenfor er det enkleste, raskeste og samtidig praktiske og kraftige sikkerhetskopieringsverktøyet BorgBackup. Restic tok andreplassen, resten av de vurderte kandidatene ble plassert omtrent likt med en spredning på ett eller to poeng på slutten.
Jeg takker alle som har lest serien til slutten, jeg inviterer deg til å diskutere alternativene og tilby dine egne, hvis noen. Etter hvert som diskusjonen skrider frem, kan tabellen utvides.
Resultatet av serien vil være den siste artikkelen, der det vil være et forsøk på å utvikle et ideelt, raskt og håndterbart sikkerhetskopieringsverktøy som lar deg distribuere en kopi tilbake på kortest mulig tid og samtidig være praktisk og enkelt å konfigurere og vedlikeholde.
Kunngjøring
Sikkerhetskopiering del 6: Sammenligning av sikkerhetskopieringsverktøy
Backup Del 7: Konklusjoner
Kilde: www.habr.com
