Den här artikeln kommer att överväga säkerhetskopieringsprogram som, genom att dela upp dataströmmen i separata komponenter (bitar), bildar ett arkiv.
Förvarskomponenter kan ytterligare komprimeras och krypteras, och viktigast av allt - under upprepade säkerhetskopieringsprocesser - återanvändas.
En säkerhetskopia i ett sådant arkiv är en namngiven kedja av komponenter kopplade till varandra, till exempel baserat på olika hashfunktioner.
Det finns flera liknande lösningar, jag ska fokusera på 3: zbackup, borgbackup och restic.
Förväntade resultat
Eftersom alla sökande kräver att ett förvar skapas på ett eller annat sätt kommer en av de viktigaste faktorerna att vara att uppskatta förvarets storlek. Helst bör dess storlek inte vara mer än 13 GB enligt den accepterade metoden, eller ännu mindre - med förbehåll för god optimering.
Det är också mycket önskvärt att kunna skapa säkerhetskopior av filer direkt, utan att använda arkiverare som tar, samt arbeta med ssh/sftp utan ytterligare verktyg som rsync och sshfs.
Beteende när du skapar säkerhetskopior:
- Storleken på förvaret kommer att vara lika med storleken på ändringarna, eller mindre.
- Tung CPU-belastning förväntas vid användning av komprimering och/eller kryptering, och ganska hög nätverks- och diskbelastning är sannolikt om arkiverings- och/eller krypteringsprocessen körs på en backuplagringsserver.
- Om förvaret är skadat är ett fördröjt fel troligt både när du skapar nya säkerhetskopior och när du försöker återställa. Det är nödvändigt att planera ytterligare åtgärder för att säkerställa förvarets integritet eller använda inbyggda verktyg för att kontrollera dess integritet.
Att arbeta med tjära tas som referensvärde, vilket framgick av en av de tidigare artiklarna.
Testar zbackup
Den allmänna mekanismen för zbackup är att programmet i indataströmmen hittar områden som innehåller samma data, sedan valfritt komprimerar och krypterar dem, och sparar varje område endast en gång.
Deduplicering använder en 64-bitars ringhash-funktion med ett glidande fönster för att kontrollera byte-för-byte-matchningar mot befintliga datablock (liknande hur rsync implementerar det).
Flertrådiga lzma och lzo används för komprimering och aes för kryptering. De senaste versionerna har möjlighet att radera gamla data från förvaret i framtiden.
Programmet är skrivet i C++ med minimala beroenden. Författaren var tydligen inspirerad av unix-vägen, så programmet accepterar data på stdin när man skapar säkerhetskopior, vilket producerar en liknande dataström på stdout vid återställning. Således kan zbackup användas som en mycket bra "byggsten" när du skriver dina egna backuplösningar. Till exempel har artikelförfattaren använt detta program som det huvudsakliga säkerhetskopieringsverktyget för hemmaskiner sedan ungefär 2014.
Dataströmmen kommer att vara en vanlig tar om inget annat anges.
Låt oss se vad resultatet blir:
Arbetet kontrollerades i 2 alternativ:
- ett arkiv skapas och zbackup startas på servern med källdata, sedan överförs innehållet i arkivet till backuplagringsservern.
- ett arkiv skapas på backuplagringsservern, zbackup startas via ssh på backuplagringsservern och data skickas till den via pipe.
Resultatet av det första alternativet var följande: 43m11s - när man använder ett okrypterat förvar och lzma-kompressorn, 19m13s - när man ersätter kompressorn med lzo.
Belastningen på servern med originaldata var som följer (ett exempel med lzma visas; med lzo var det ungefär samma bild, men andelen rsync var ungefär en fjärdedel av tiden):
Det är tydligt att en sådan säkerhetskopieringsprocess endast är lämplig för relativt sällsynta och små förändringar. Det är också mycket tillrådligt att begränsa zbackup till 1 tråd, annars blir det en mycket hög CPU-belastning, eftersom Programmet är väldigt bra på att arbeta i flera trådar. Belastningen på disken var liten, vilket i allmänhet inte skulle märkas med ett modernt ssd-baserat diskundersystem. Du kan också tydligt se början på processen att synkronisera förvarsdata till en fjärrserver; drifthastigheten är jämförbar med vanlig rsync och beror på prestandan hos diskundersystemet på backuplagringsservern. Nackdelen med detta tillvägagångssätt är lagringen av ett lokalt arkiv och, som ett resultat, duplicering av data.
Mer intressant och användbar i praktiken är det andra alternativet, som kör zbackup direkt på backuplagringsservern.
Först kommer vi att testa operationen utan att använda kryptering med lzma-kompressorn:
Körtid för varje testkörning:
Lansering 1
Lansering 2
Lansering 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Om du aktiverar kryptering med aes är resultaten ganska nära:
Drifttid på samma data, med kryptering:
Lansering 1
Lansering 2
Lansering 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Om kryptering kombineras med komprimering med lzo ser det ut så här:
Timmar:
Lansering 1
Lansering 2
Lansering 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Storleken på det resulterande förvaret var relativt densamma vid 13 GB. Det betyder att deduplicering fungerar korrekt. På redan komprimerade data ger användningen av lzo en märkbar effekt; i termer av total drifttid kommer zbackup nära duplicity/duplicati, men släpar efter de som baseras på librsync med 2-5 gånger.
Fördelarna är uppenbara - sparar diskutrymme på backuplagringsservern. När det gäller verktyg för förvarskontroll tillhandahåller inte författaren av zbackup dem; det rekommenderas att använda en feltolerant diskarray eller molnleverantör.
Sammantaget ett mycket gott intryck, trots att projektet har stått stilla i cirka 3 år (den senaste funktionsförfrågan var för cirka ett år sedan, men utan svar).
Testar borgbackup
Borgbackup är en gaffel av vinden, ett annat system som liknar zbackup. Skrivet i python har den en lista över funktioner som liknar zbackup, men kan dessutom:
- Montera säkerhetskopior via säkring
- Kontrollera förvarets innehåll
- Arbeta i klient-server-läge
- Använd olika kompressorer för data, samt heuristisk bestämning av filtypen när du komprimerar den.
- 2 krypteringsalternativ, aes och blake
- Inbyggt verktyg för
prestationskontroller
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Resultaten blev följande:
CZ-BIG 96.51 MB/s (10 100.00 MB helt noll-filer: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB helt noll-filer: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB helt noll-filer: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB helt noll-filer: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB slumpmässiga filer: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB slumpmässiga filer: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB slumpmässiga filer: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB slumpmässiga filer: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB helt noll-filer: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB helt noll-filer: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB helt noll-filer: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB helt noll-filer: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB slumpmässiga filer: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB slumpmässiga filer: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB slumpmässiga filer: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB slumpmässiga filer: 20.49s)
CZ-SMALL 11.72 MB/s (10000 XNUMX 10.00 kB helt noll-filer: 8.53s)
RZ-SMALL 32.57 MB/s (10000 XNUMX 10.00 kB helt noll-filer: 3.07s)
UZ-SMALL 19.37 MB/s (10000 XNUMX 10.00 kB helt noll-filer: 5.16s)
DZ-SMALL 33.71 MB/s (10000 XNUMX 10.00 kB helt noll-filer: 2.97s)
CR-SMALL 6.85 MB/s (10000 XNUMX 10.00 kB slumpmässiga filer: 14.60s)
RR-LITEN 31.27 MB/s (10000 XNUMX 10.00 kB slumpmässiga filer: 3.20s)
UR-SMALL 12.28 MB/s (10000 XNUMX 10.00 kB slumpmässiga filer: 8.14s)
DR-SMALL 18.78 MB/s (10000 XNUMX 10.00 kB slumpmässiga filer: 5.32s)
Vid testning kommer komprimeringsheuristik att användas för att bestämma filtypen (automatisk komprimering), och resultaten blir som följer:
Låt oss först kolla hur det fungerar utan kryptering:
Timmar:
Lansering 1
Lansering 2
Lansering 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Om du aktiverar arkivauktorisering (autentiserat läge), kommer resultaten att vara nära:
Timmar:
Lansering 1
Lansering 2
Lansering 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
När aes-kryptering aktiverades försämrades inte resultaten mycket:
Lansering 1
Lansering 2
Lansering 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Och om du byter aes till blake kommer situationen att förbättras helt:
Timmar:
Lansering 1
Lansering 2
Lansering 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Liksom i fallet med zbackup var förvarets storlek 13 GB och till och med lite mindre, vilket generellt förväntas. Jag var mycket nöjd med körtiden, den är jämförbar med lösningar baserade på librsync, vilket ger mycket bredare möjligheter. Jag var också nöjd med möjligheten att ställa in olika parametrar genom miljövariabler, vilket ger en mycket stor fördel när man använder borgbackup i automatiskt läge. Jag var också nöjd med belastningen under säkerhetskopieringen: av processorbelastningen att döma fungerar borgbackup i 1 tråd.
Det fanns inga särskilda nackdelar vid användningen.
restisk testning
Trots att restic är en ganska ny lösning (de första 2 kandidaterna var kända redan 2013 och äldre), har den ganska bra egenskaper. Skrivet i Go.
Jämfört med zbackup ger det dessutom:
- Kontroll av förvarets integritet (inklusive incheckning av delar).
- En enorm lista över protokoll och leverantörer som stöds för lagring av säkerhetskopior, samt stöd för rclone - rsync för molnlösningar.
- Jämför två säkerhetskopior med varandra.
- Montering av förvaret via säkring.
I allmänhet ligger listan över funktioner ganska nära borgbackup, på vissa ställen mer, på andra mindre. En av funktionerna är att det inte finns något sätt att inaktivera kryptering, och därför kommer säkerhetskopior alltid att krypteras. Låt oss se i praktiken vad som kan pressas ut ur denna programvara:
Resultaten blev följande:
Timmar:
Lansering 1
Lansering 2
Lansering 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Prestandaresultaten är också jämförbara med rsync-baserade lösningar och i allmänhet mycket nära borgbackup, men CPU-belastningen är högre (flera trådar körs) och sågtand.
Troligtvis är programmet begränsat av prestandan hos diskundersystemet på datalagringsservern, vilket redan var fallet med rsync. Lagringsstorleken var 13 GB, precis som zbackup eller borgbackup, det fanns inga uppenbara nackdelar med att använda denna lösning.
Resultat
Faktum är att alla kandidater uppnådde liknande resultat, men till olika priser. Borgbackup presterade bäst av allt, restic var lite långsammare, zbackup är nog inte värt att börja använda,
och om den redan används, försök att ändra den till borgbackup eller restic.
Resultat
Den mest lovande lösningen verkar vara restisk, eftersom... det är han som har det bästa förhållandet mellan kapacitet och driftshastighet, men låt oss inte skynda oss till allmänna slutsatser för nu.
Borgbackup är i princip inte sämre, men zbackup är nog bättre ersatt. Det är sant att zbackup fortfarande kan användas för att säkerställa att 3-2-1-regeln fungerar. Till exempel, förutom (lib)rsync-baserade säkerhetskopieringsmöjligheter.
Meddelande
Backup del 5: Testar bacula och veeam backup för linux
Säkerhetskopiering Del 6: Jämföra säkerhetskopieringsverktyg
Backup Del 7: Slutsatser
Postat av: Pavel Demkovich
Källa: will.com