I denna artikel kommer programvaror för säkerhetskopiering att behandlas, vilka genom att dela upp datastreamen i separata komponenter (chunks), formar ett repository.
Repositorykomponenter kan dessutom komprimeras och krypteras, och viktigast av allt – vid upprepade säkerhetskopieringsprocesser – återanvändas.
En säkerhetskopia i ett sådant repository är en namngiven kedja av relaterade komponenter, till exempel baserat på olika hash-funktioner.
Det finns flera liknande lösningar, jag kommer att fokusera på 3: zbackup, borgbackup och restic.
Förväntade resultat
Eftersom alla kandidater mer eller mindre kräver skapande av ett repository, kommer en av de viktigaste faktorerna att vara bedömning av repositoryts storlek. I idealfallet bör dess storlek inte överstiga 13 GB enligt den vedertagna metoden, ja, eller till och med mindre – under förutsättning av god optimering.
Det är också starkt önskvärt att ha möjlighet att skapa säkerhetskopior av filer direkt, utan att använda arkiveringsverktyg som tar, samt att arbeta med ssh/sftp utan ytterligare verktyg som rsync och sshfs.
Beteende vid skapande av säkerhetskopior:
- Repositoryts storlek kommer att motsvara storleken på förändringarna, eller vara mindre.
- Stora processorbelastningar förväntas vid användning av komprimering och/eller kryptering, och en ganska stor belastning på nätverket och disksubsystemet kan också förekomma, om arkiverings- och/eller krypteringsprocessen körs på backupservern.
- Om repositoryt skadas – finns det risk för fördröjd fel vid både skapande av nya säkerhetskopior och vid försök till återställning. Ytterligare åtgärder för att säkerställa repositoryts integritet bör planeras eller så bör inbyggda verktyg för att kontrollera dess integritet användas.
Som referensvärde antas arbete med tar, som visats i en av tidigare artiklar.
Test av zbackup
Den allmänna arbetsmekanismen för zbackup är att programmet söker i datastreamen som matas in, efter områden som innehåller samma data, sedan komprimerar och krypterar det valfritt, och sparar varje område endast en gång.
För deduplicering används en 64-bitars ringhash-funktion med glidande fönster för byte-för-byte-kontroll av överensstämmelse med redan existerande datablokker (liknande hur det implementeras i rsync).
För komprimering används lzma och lzo i flertrådad utförande, och för kryptering används aes. I de senaste versionerna finns möjlighet att i framtiden ta bort gamla data från lagringsförrådet.
Programmet är skrivet i C++ med minimala beroenden. Författaren har uppenbarligen blivit inspirerad av unix-way, så programmet tar emot data via stdin när säkerhetskopior skapas och ger ett liknande datastream i stdout vid återställning. Därför kan zbackup användas som en ganska bra "byggsten" vid skrivandet av egna säkerhetskopieringslösningar. Till exempel, för författaren av artikeln har detta program varit det huvudsakliga verktyget för säkerhetskopiering för hemmamaskiner sedan ungefär 2014.
Som datastream kommer vanlig tar att användas, om inget annat anges.
Låt oss se vilka resultat som kommer att bli:
Prestandatestet utfördes i 2 varianter:
- ett lagringsförråd skapas och zbackup körs på servern med källdata, sedan överförs innehållet i lagringsförrådet till servern för säkerhetskopiering.
- ett lagringsförråd skapas på servern för säkerhetskopiering, zbackup körs via ssh på servern för säkerhetskopiering, som via ett pipe tar emot data.
Resultaten från den första varianten var följande: 43m11s — vid användning av det okrypterade lagringsförrådet och kompressorn lzma, 19m13s — vid byte av kompressorn till lzo.
Belastningen på servern med källdata var följande (exemplet med lzma visas, med lzo var bilden ungefär densamma, men andelen rsync var ungefär en fjärdedel av tiden):
Det är tydligt att en sådan säkerhetskopieringsprocess endast är lämplig vid relativt sällsynta och små förändringar. Det är också mycket önskvärt att begränsa zbackup till 1 tråd, annars blir belastningen på processorn mycket hög, eftersom programmet verkligen klarar av att arbeta i flera trådar. Diskbelastningen var liten, vilket i allmänhet inte kommer att märkas med moderna diskundersystem baserade på ssd. Det är också tydligt att starta synchroniseringsprocessen av lagringsförrådets data till den fjärrservern, hastigheten på arbetet är jämförbar med vanlig rsync och begränsas av prestandan hos diskundersystemet för säkerhetskopieringsservern. En nackdel med metoden är lagring av det lokala lagringsförrådet och, som en följd, - duplicering av data.
Det intressantare och mer praktiska alternativet är det andra alternativet med att köra zbackup direkt på servern som lagrar säkerhetskopior.
Först kommer vi att kontrollera funktionen utan att använda kryptering med kompressorn lzma:
Körtiden för varje testkörning:
Körning 1
Körning 2
Körning 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Om kryptering aktiveras med hjälp av aes, är resultaten tillräckligt nära:
Körtid med samma data, med kryptering:
Körning 1
Körning 2
Körning 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Om kryptering kombineras med komprimering på lzo, ser det ut så här:
Driftstid:
Körning 1
Körning 2
Körning 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
Storleken på det resulterande arkivet var relativt likartad och uppgick till 13 GB. Det betyder att deduplicering fungerar korrekt. Dessutom ger tillämpningen av lzo på redan komprimerade data en påtaglig effekt, och den totala körtiden för zbackup kommer nära duplicity/duplicati, men ligger efter de som är baserade på librsync med 2-5 gånger.
Fördelarna är uppenbara — besparing av diskutrymme på servern som lagrar säkerhetskopior. När det gäller verktyg för att kontrollera arkivet — är de inte försedda av författaren av zbackup, så det rekommenderas att använda ett redundanta diskarray eller en molnleverantör.
Överlag ett ganska bra intryck, trots att projektet stått stilla i ungefär 3 år (senaste funktionsförfrågan var för cirka ett år sedan, men utan svar).
Test av borgbackup
Borgbackup är en fork av attic, ett annat system som liknar zbackup. Skriven i python, har en liknande funktionslista som zbackup, men kan dessutom:
Montera säkerhetskopior via fuse
- Kontrollera innehållet i arkivet
- Arbeta i klient-server-läge
- Använda olika kompressorer för data samt heuristisk bestämning av filtyp vid komprimering.
- 2 alternativ för kryptering, aes och blake
- Inbyggt verktyg för
- prestandakontroll
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Resultaten blev sådana:
C-Z-BIG 96,51 MB/s (10
100,00 MB all-zero files: 10,36s) R-Z-BIG 57,22 MB/s (10
100,00 MB all-zero files: 17,48s) U-Z-BIG 253,63 MB/s (10
100,00 MB all-zero files: 3,94s) D-Z-BIG 351,06 MB/s (10
100,00 MB all-zero files: 2,85s) C-R-BIG 34,30 MB/s (10
100,00 MB random files: 29,15s) R-R-BIG 60,69 MB/s (10
100,00 MB random files: 16,48s) U-R-BIG 311,06 MB/s (10
100,00 MB random files: 3,21s) D-R-BIG 72,63 MB/s (10
100,00 MB random files: 13,77s) C-Z-MEDIUM 108,59 MB/s (1000
1,00 MB all-zero files: 9,21s) R-Z-MEDIUM 76,16 MB/s (1000
1,00 MB all-zero files: 13,13s) U-Z-MEDIUM 331,27 MB/s (1000
1,00 MB all-zero files: 3,02s) D-Z-MEDIUM 387,36 MB/s (1000
1,00 MB all-zero files: 2,58s) C-R-MEDIUM 37,80 MB/s (1000
1,00 MB random files: 26,45s) 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB slump-arker: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB slump-arker: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB slump-arker: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB alla-nollade filer: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB alla-nollade filer: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB alla-nollade filer: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB alla-nollade filer: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB slump-arker: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB slump-arker: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB slump-arker: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB slump-arker: 5.32s)
Under testningen kommer heuristik att användas för kompression med filtypdetektering (compression auto), och resultaten kommer att vara följande:
Först ska vi kontrollera hur det fungerar utan kryptering:
Driftstid:
Körning 1
Körning 2
Körning 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Om man aktiverar autentisering av förrådet (authenticated mode), blir resultaten liknande:
Driftstid:
Körning 1
Körning 2
Körning 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
När AES-kryptering aktiveras försämras resultaten inte mycket:
Körning 1
Körning 2
Körning 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Men om man byter AES mot Blake, blir situationen bli avsevärt bättre:
Driftstid:
Körning 1
Körning 2
Körning 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Som i fallet med zbackup var storleken på förrådet 13 GB eller till och med något mindre, vilket är förväntat. Arbetstiden var mycket tillfredsställande, den är jämförbar med lösningar baserade på librsync, vilket erbjuder mycket större möjligheter. Jag blev också glad över möjligheten att ställa in olika parametrar via miljövariabler, vilket ger en mycket stor fördel vid användning av borgbackup i automatiskt läge. Dessutom var belastningen vid säkerhetskopiering ganska låg: allt tyder på att borgbackup körs i en tråd.
Inga större nackdelar har upptäckts vid användning.
Test av Restic
Trots att Restic är en relativt ny lösning (de första två kandidaterna har varit kända sedan 2013 eller tidigare) har den ganska bra prestanda. Den är skriven i Go.
När man jämför med zbackup erbjuder den dessutom:
- Integritetskontroll av förrådet (inklusive delvis kontroll).
- En enorm lista över stödda protokoll och leverantörer för lagring av säkerhetskopior samt stöd för rclone – rsync för "molnlösningar".
- Jämförelse av två säkerhetskopior med varandra.
- Montering av förrådet via fuse.
Sammanfattningsvis är möjligheterna ganska liknande de hos borgbackup, ibland fler, ibland färre. En av de specifika aspekterna är avsaknaden av möjligheten att stänga av kryptering, vilket innebär att säkerhetskopior alltid kommer att vara krypterade. Låt oss se i praktiken vad vi kan få ut av denna programvara:
Resultaten blev följande:
Driftstid:
Körning 1
Körning 2
Körning 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Resultaten är också jämförbara med lösningar baserade på rsync och är överlag väldigt nära borgbackup, men CPU-belastningen är högre (flera trådar körs) och är sågklingeliknande.
Det är troligt att programmet begränsas av prestandan hos diskunderlaget på lagringsservern, precis som med rsync. Repositoryt var 13GB, likt zbackup eller borgbackup, och några uppenbara nackdelar med att använda denna lösning har inte upptäckts.
Resultat
Faktum är att alla kandidater hade liknande resultat, men till olika priser. Borgbackup presterade bäst, restic var något långsammare, medan zbackup sannolikt inte är värt att börja använda,
och om det redan används — pröva att byta till borgbackup eller restic.
Slutsatser
Det mest lovande alternativet ser ut att vara restic, eftersom det har den bästa balansen mellan funktioner och hastighet, men låt oss vänta med att dra allmänna slutsatser.
Borgbackup är i princip inte sämre, men zbackup bör sannolikt ersättas. Men för att säkerställa arbetet enligt 3-2-1-regeln kan zbackup fortfarande användas, till exempel som ett komplement till (lib)rsync-baserade säkerhetskopieringslösningar.
Tillkännagivande
Backup, del 5: Test av bacula och veeam backup för linux
Backup, del 6: Jämförelse av backupverktyg
Backup, del 7: Slutsatser
Författare av publiceringen: Pavel Demkovich
Källa: habr.com
