I den här artikeln kommer en jämförelse av backupverktyg att göras, men först är det värt att ta reda på hur snabbt och effektivt de kan återställa data från säkerhetskopior.
För enkelhets skull kommer återställning från en fullständig säkerhetskopia att övervägas, särskilt eftersom alla kandidater stöder detta arbetsläge. För att förenkla har siffrorna redan medelvärdesberäknats (arimetriskt medel av flera körningar). Resultaten kommer att sammanställas i en tabell, som också kommer att innehålla information om olika funktioner: tillgång till webbgränssnitt, enkelhet i konfiguration och användning, automatiseringskapabiliteter, samt olika extrafunktioner (till exempel dataintegritetskontroll) osv. Graferna kommer att visa serverns belastning, där data kommer att tillämpas (inte servern för lagring av säkerhetskopior).
Återställning av data
Som referens kommer rsync och tar att användas, eftersom de enklaste skripten för att ta säkerhetskopior.
Rsync klarade testdatamängden på 4 minuter och 28 sekunder, vilket visade
denna belastning.
Återställningsprocessen begränsades av disksystemets begränsningar på lagringsservern (taggiga grafer). Det syns tydligt att ett kärna har belastats utan större problem (låg iowait och softirq — inga problem med disk och nätverk respektive). Eftersom de två andra programmen, nämligen rdiff-backup och rsnapshot, är baserade på rsync och också erbjuder rsync som återställningsmedel, kommer de att ha en ungefär liknande belastningsprofil och återställningstid.
Tar klarade det något snabbare, på
2 minuter och 43 sekunder:
Den totala systembelastningen var i genomsnitt 20 % högre på grund av ökad softirq — overheaden i den nätverksbaserade subsystemet ökade.
Om arkivet dessutom komprimeras ökar återställningstiden till 3 minuter och 19 sekunder med
denna belastning på den primära servern (uppackning på den primära servern):
Uppackningsprocessen använder båda processor-kärnorna, eftersom två processer körs. Totalt sett är detta ett förväntat resultat. Ett jämförbart resultat (3 minuter och 20 sekunder) erhölls också vid körning av gzip på serversidan med säkerhetskopior; belastningsprofilen på huvudservern var ganska lik den vid körning av tar utan gzip-kompressorn (se tidigare diagram).
I rdiff-backup Den senaste gjorda säkerhetskopian kan synkroniseras med vanlig rsync (resultaten kommer att vara liknande), men äldre säkerhetskopior måste fortfarande återställas med hjälp av programmet rdiff-backup, som hanterade återställningen på 17 minuter och 17 sekunder, vilket visade
denna belastning:
Det kan ha varit avsikten, i alla fall för att begränsa hastigheten föreslår författarna . Själva processen för att återställa säkerhetskopian tar lite mindre än hälften av en kärna, med proportionellt jämförbar prestanda (d.v.s. 2-5 gånger långsammare) över disk och nätverk med rsync.
Rsnapshot rekommenderar att använda vanlig rsync för återställning, så resultaten kommer att vara liknande. Totalt sett visade det sig stämma.
Burp klarade uppgiften att återställa säkerhetskopian på 7 minuter och 2 sekunder med
denna belastning:
Det gick tillräckligt snabbt och, åtminstone, betydligt mer bekvämt än ren rsync: man behöver inte komma ihåg några flaggor, enkel och intuitiv cli-gränssnitt, inbyggt stöd för flera kopior - men det är ungefär dubbelt så långsamt. Om data ska återställas från den senaste gjorda säkerhetskopian - kan man använda rsync, med några få förbehåll.
Ungefär samma hastighet och belastning visade programmet BackupPC när rsync överföringsläget var aktiverat, och återställde säkerhetskopian på
7 minuter och 42 sekunder:
Men i tar överföringsläge fungerade BackupPC långsammare: på 12 minuter och 15 sekunder, medan processorbelastningen i det fallet var generellt lägre
med 1,5 gånger:
Duplicity utan kryptering visade något bättre resultat, genomförde återställningen av säkerhetskopian på 10 minuter och 58 sekunder. Om kryptering aktiveras med hjälp av gpg ökar återställningstiden till 15 minuter och 3 sekunder. Vid skapandet av ett repository för att lagra säkerhetskopior kan man också ange storleken på arkivet som ska användas vid uppdelningen av den inkommande datastreamen. Generellt sett, på vanliga hårddiskar, samt på grund av den enskilda trådmoden, är det ingen större skillnad. Det kan dock dyka upp variationer med olika blockstorlekar när hybridlagring används. Belastningen på huvudservern under återställningen var sådan:
utan kryptering
med kryptering
Duplicati visade jämförbar hastighet för återställning, genomförde det på 13 minuter och 45 sekunder. Ytterligare cirka 5 minuter tog det att kontrollera korrektheten av de återställda uppgifterna (totalt cirka 19 minuter). Belastningen under detta var
relativt hög:
När kryptering med aes aktiverades via interna medel, blev återställningstiden 21 minuter och 40 sekunder, och CPU-belastningen var maximal (båda kärnorna!) under återställningen; vid datakontrollen var endast en tråd aktiv, som använde en CPU-kärna. Kontroll av data efter återställning tog samma 5 minuter (totalt nästan 27 minuter).
Resultat
Något snabbare hanterade duplicati återställningen när en extern programvara gpg användes för kryptering, men överlag är skillnaderna från det föregående läget minimala. Arbetstiden var 16 minuter och 30 sekunder, med datakontroll på 6 minuter. Belastningen var
sådan:
AMANDA, som använder tar, klarade det på 2 minuter och 49 sekunder, vilket i princip är ganska nära vanlig tar. Belastningen på systemet är i stort sett
samma:
Vid återställning av säkerhetskopian med zbackup fick vi följande resultat:
kryptering, lzma-komprimering
Arbetstid 11 minuter och 8 sekunder
kryptering aes, lzma-komprimering
Arbetstid 14 minuter
kryptering aes, lzo-komprimering
Arbetstid 6 minuter, 19 sekunder
Överlag är det okej. Allt beror på hastigheten hos processorn på backupservern, vilket tydligt syns på programmets prestanda med olika kompressorer. På backupservern kördes en vanlig tar, så om man jämför med den – återställningen fungerar tre gånger långsammare. Det kan vara värt att kontrollera prestandan i flertrådat läge, med fler än två trådar.
BorgBackup i okrypterat läge klarade sig något långsammare än tar, på 2 minuter och 45 sekunder, men till skillnad från tar fanns möjligheten till deduplicering av repository. Belastningen blev
så här:
Om man aktiverar kryptering baserad på blake, sänks återställningshastigheten något. Återställningstiden i detta läge är 3 minuter och 19 sekunder, och belastningen blev
så här:
AES-kryptering fungerar något långsammare, återställningstiden är 3 minuter och 23 sekunder, belastningen förblev
oförändrad:
Eftersom Borg kan köras i flertrådat läge – är CPU-belastningen maximal, och vid aktivering av ytterligare funktioner ökar bara arbetstiden. Upplagt är tydligt att det kan vara värt att utforska flertrådad prestanda på liknande sätt som zbackup.
Restic klarade återställningen något långsammare, arbetstiden blev 4 minuter och 28 sekunder. Belastningen såg ut som
så här:
tydligt verkar återställningsprocessen arbeta i flera trådar, men effektiviteten är inte lika hög som BorgBackup, men tiden är jämförbar med vanlig rsync.
Med hjälp av UrBackup lyckades återställa data på 8 minuter och 19 sekunder, och belastningen var
sådan:
fortfarande synligt låg, till och med lägre än tar. Ibland toppar, men inte mer än belastningen på ett kärn.
Val och motivering av kriterier för jämförelse
Som nämnts i en av de tidigare artiklarna bör backupsystemet uppfylla följande kriterier:
- Enkelhet i arbetet
- Allsidighet
- Stabilitet
- Hastighet
Det är värt att titta närmare på varje punkt.
Användarvänlighet
Det bästa är när det finns en knapp "Gör allt rätt", men när man återvänder till verkliga program — skulle ett bekvämt och standardiserat arbetssätt vara mer gynnsamt.
De flesta användare kommer sannolikt att föredra att inte behöva komma ihåg en massa kommandoalternativ för CLI, ställa in olika, ofta svårbegripliga alternativ via webben eller TUI, samt att ställa in aviseringar om misslyckad drift. Här ingår också möjligheten att enkelt "integrera" en backup-lösning i den befintliga infrastrukturen samt automatisering av backup-processen. Dessutom bör det gå att installera via en paketförvaltare, eller med en eller två kommandon som "ladda ner och packa upp". curl länk | sudo bash — en komplicerad metod, eftersom man måste kontrollera vad som laddas ner från länken.
Till exempel, av de övervägda kandidaterna är ett enkelt alternativ burp, rdiff-backup och restic, som har mnemoniska nycklar för olika driftslägen. Lite mer komplicerat är borg och duplicity. Det mest komplicerade var AMANDA. De andra ligger någonstans mitt emellan när det gäller användarvänlighet. I vilket fall som helst, om det tar mer än 30 sekunder att läsa användarmanualen, eller om man måste googla eller använda en annan sökmotor, samt bläddra igenom en lång hjälparts — är lösningen komplicerad, hur som helst.
En del av de övervägda kandidaterna kan automatiskt skicka ett meddelande via e-mail jabber, medan andra förlitar sig på inställda aviseringar i systemet. Oftast har mer komplicerade lösningar inte helt uppenbara inställningar för aviseringar. I vilket fall som helst, om backup-programmet returnerar en icke-noll exit-kod, som korrekt tolkas av systemtjänsten för schemalagda uppgifter (det skickas ett meddelande till systemadministratören eller direkt till övervakningen) — är situationen enkel. Men om backup-systemet, som inte körs på backup-servern, inte kan utan konfiguration, tydligt meddela om ett problem — är komplexiteten redan överdriven. I vilket fall som helst är det dålig praxis att endast ge aviseringsmeddelanden och andra meddelanden i webgränssnittet och/eller loggen, eftersom de oftast kommer att ignoreras.
När det gäller automatisering — ett enkelt program kan läsa miljövariabler som anger dess driftsläge, eller ha en utvecklad CLI som kan duplicera beteendet fullt ut vid arbete genom webgränssnittet, till exempel. Här ingår också möjligheten för strömmad drift, tillgång till utvidgningsmöjligheter osv.
Allsidighet
Delvis relaterar till föregående avsnitt om automatisering, det borde inte vara något större problem att "integrera" backup-processen i den befintliga infrastrukturen.
Det bör noteras att användningen av icke-standardportar (utom webbgränssnittet) för drift, implementering av kryptering på icke-standardiserade sätt och utbyte av data via icke-standardprotokoll är kännetecken på en icke-universell lösning. Största delen av kandidaterna har dem på ett eller annat sätt av uppenbara skäl: enkelhet och universell användbarhet är vanligtvis oförenliga. Som undantag finns burp, det finns andra också.
Ett kännetecken är möjligheten att arbeta med vanlig ssh.
Arbetshastighet
Den mest kontroversiella och diskussionen punkten. Å ena sidan - startade processen, den fungerade maximalt snabbt och störde inte de huvudsakliga uppgifterna. Å andra sidan - en ökning av trafik och processorbelastning under backup-processen. Det bör också noteras att de snabbaste programmen för att skapa kopior vanligtvis är de mest begränsade när det kommer till funktioner som är viktiga för användarna. Återigen: om det för att få en enda stackars textfil på några tiotal byte med ett lösenord, och hela tjänsten står på spel (ja, jag förstår att backup-processen oftast inte är skyldig här), och det är nödvändigt att läsa sekventiellt alla filer i repositoryt eller återställa ett helt arkiv - backup-systemet är verkligen inte snabbt. En annan punkt som ofta blir en knäckfråga är hastigheten för att återställa en backup från ett arkiv. Här har de som kan kopiera eller flytta filer till rätt plats utan komplicerade manipulationer (rsync till exempel) tydligt en fördel, men oftast måste problemet lösas organisatoriskt, empiriskt: mäta återställningstiden för backup och öppet kommunicera detta till användarna.
Stabilitet
Det bör förstås så här: å ena sidan ska det finnas möjlighet att återställa en backup på något sätt, å andra sidan - motståndskraft mot olika problem: nätverksavbrott, diskfel, borttagning av delar av repositoryt.
Jämförelse av backup-verktyg
Tid för att skapa en kopia
Tid för att återställa en kopia
Enkel installation
Enkel konfiguration
Enkelt att använda
Enkel automatisering
Behövs klientserver?
Kontroll av repositoryts integritet
Differenskopior
Arbete via pipe
Allsidighet
Självständighet
Transparens i repositoryt
Kryptering
Kompression
Deduplicering
Webbgränssnitt
Ladda upp till molnet
Stöd för Windows
Poäng
Rsync
4m15s
4m28s
ja
nej
nej
nej
ja
nej
nej
ja
nej
ja
ja
nej
nej
nej
nej
nej
ja
6
Tar
ren
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
Tabellens legend:
- Grön, drifttid mindre än fem minuter, eller svar "Ja" (utom kolumnen "Behövs klientsserver?"), 1 poäng
- Gul, drifttid fem-tio minuter, 0.5 poäng
- Röd, drifttid mer än tio minuter, eller svar "Nej" (utom kolumnen "Behövs klientsserver?"), 0 poäng
Enligt den ovannämnda tabellen är det enklaste, snabbaste och samtidigt mest praktiska och kraftfulla verktyget för säkerhetskopiering BorgBackup. Restic kom på andra plats, medan de övriga granskade kandidaterna placerade sig ganska jämnt med en spridning på en-två poäng i slutet.
Tack till alla som läst cykeln till slut, jag föreslår att vi diskuterar alternativ och föreslå egna, om det finns några. Under diskussionen kan tabellen kompletteras.
Resultatet av cykeln kommer att bli en avslutande artikel där en strävan att formulera det perfekta, snabba och hanterbara verktyget för säkerhetskopiering görs, vilket möjliggör en snabb återställning av en kopia och samtidigt har bekvämlighet och enkelhet i inställning och underhåll.
Tillkännagivande
Backup, del 6: Jämförelse av backupverktyg
Backup, del 7: Slutsatser
Källa: habr.com
