I denna anteckning behandlas backupverktyg som utför backup genom att skapa arkiv på en backupserver.
Bland de som uppfyller kraven finns duplicity (som har ett trevligt gränssnitt i form av deja dup) och duplicati.
Ett annat mycket anmärkningsvärt backupverktyg är dar, men eftersom det har en ganska omfattande lista med alternativ — testmetodiken täcker knappt 10% av vad det kan göra — testar vi det inte inom ramen för denna cykel.
Förväntade resultat
Eftersom båda kandidaterna på ett eller annat sätt skapar arkiv kan vi använda det vanliga tar som riktmärke.
Vi kommer dessutom att bedöma hur väl datalagringen på backupservern optimeras genom att skapa säkerhetskopior som endast innehåller skillnaderna mellan en fullständig kopia och den nuvarande filstatusen eller mellan tidigare och nuvarande arkiv (inkrementella, dekrementella osv.).
Beteende vid skapande av säkerhetskopior:
- En relativt liten mängd filer på backupservern (jämfört med antalet säkerhetskopior eller datastorlek i GB), men tillräckligt stor storlek (tiotals-hundratals megabyte).
- Storleken på repot kommer att inkludera endast ändringar — dubbletter kommer inte att lagras, vilket gör att storleken på repot blir mindre än när programvaran körs baserat på rsync.
- En stor belastning på processorn förväntas vid användning av kompression och/eller kryptering, samt sannolikt också en ganska stor belastning på nätverket och lagersystemet, om processen för arkivering och/eller kryptering körs på backupservern.
Som referensvärde kör vi följande kommando:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Resultaten av körningen blev följande:
Körtiden var 3m12s. Det är tydligt att hastigheten har begränsats av lagersystemet på backupservern, som i exemplet med . Bara lite snabbare, eftersom skrivningen sker till en fil.
För att också utvärdera kompressionen kör vi samma variant, men vi aktiverar kompression på backupserverns sida:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Resultaten är som följer:
Körtiden var 10m11s. Troligtvis är flaskhalsen en entrådad kompressor på mottagarsidan.
Samma kommando, men med överföring av komprimering till servern med ursprungsdata för att testa hypotesen att flaskhalsen är entrådad kompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Det blev så här:
Körtiden blev 9m37s. Det är uppenbart att en kärna används av kompressorn, eftersom överföringshastigheten via nätverket och belastningen på diskundersystemet är liknande.
För att bedöma krypteringen kan openssl eller gpg användas, med en extra kommando openssl eller gpg i pipen. Här är en referenskommando:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Resultaten blev följande:
Körtiden blev 10m30s, eftersom 2 processer kördes på mottagarsidan — flaskhalsen är åter entrådad kompressor, plus små overheadkostnader för kryptering.
UPD: På begäran av bliznezz lägger jag till tester med pigz. Om endast kompressorn används blev det 6m30s, och om kryptering även läggs till — ungefär 7m. Fallet på den nedre grafen — osläppt diskcache:
Testning av duplicity
Duplicity är ett Python-program för backup genom att skapa krypterade arkiv i tar-format.
För inkrementella arkiv används librsync, så man kan förvänta sig beteende som beskrivs i .
Säkerhetskopior kan krypteras och signeras med hjälp av gnupg, vilket är viktigt vid användning av olika leverantörer för lagring av säkerhetskopior (s3, backblaze, gdrive etc.)
Låt oss se vilka resultat som kommer att bli:
Här är resultaten vid körning utan kryptering
spoiler
Körtiden för varje testkörning:
Körning 1
Körning 2
Körning 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Här är resultaten vid aktivering av kryptering med gnupg, med en nyckelstorlek på 2048 bitar:
Körtid med samma data, med kryptering:
Körning 1
Körning 2
Körning 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blockstorleken angavs till 512 megabyte, vilket tydligt syns i graferna; CPU-belastningen har faktiskt hållits på 50%, vilket innebär att programmet bara utnyttjar en processor kärna.
Principen för programmets arbete är också ganska tydlig: ta en bit data, komprimera den, skicka den till säkerhetskopieringsservern, som kan vara ganska långsam.
En annan funktion är den förutsägbara körtiden för programmet, som endast beror på storleken på de ändrade datana.
Aktiveringen av kryptering ökade inte programtiden särskilt mycket, men den ökade CPU-belastningen med cirka 10 %, vilket kan vara en ganska trevlig bonus.
Tyvärr kunde detta program inte korrekt upptäcka situationen med omstruktureringen av katalogen, vilket resulterade i att storleken på arkivet blev lika stor som ändringarna (dvs. hela 18 GB), men möjligheten att använda en icke-betrodd server för backup överväger definitivt detta beteende.
Testning av duplicati
Denna programvara är skriven i C# och körs med ett bibliotekssats från Mono. Den har både GUI och CLI-version.
Den ungefärliga listan över huvudfunktionerna är liknande duplicity, inklusive olika leverantörer för lagring av backups, men till skillnad från duplicity är de flesta funktioner tillgängliga utan externa verktyg. Om detta är en fördel eller nackdel beror på det specifika fallet, men för nybörjare är det troligen enklare att ha en lista över alla funktioner framför sig, istället för att installera Python-paket som i fallet med duplicity.
Ytterligare en liten detalj — programmet skriver aktivt till en lokal sqlite-databas under namnet på den användare som startar backupen, så det är viktigt att kontrollera att den rätta databasen anges vid varje körning av processen med CLI. När man arbetar via GUI eller WEBGUI kommer detaljerna att döljas från användaren.
Låt oss titta på vilka resultat denna lösning kan ge:
Om krypteringen stängs av (och WEBGUI rekommenderar inte att göra detta) ser resultaten ut så här:
Driftstid:
Körning 1
Körning 2
Körning 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Med kryptering aktiverad, använder aes, ser det ut så här:
Driftstid:
Körning 1
Körning 2
Körning 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Och om man använder det externa programmet gnupg, blir resultaten sådana:
Körning 1
Körning 2
Körning 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Som man kan se — programmet klarar av att köra i flera trådar, men blir inte mer produktivt, och om man jämför krypteringsarbetet — körningen av det externa programmet
visade sig vara snabbare än att använda biblioteket från Mono. Det kan bero på att det externa programmet är mer optimerat.
En trevlig detalj var också att storleken på lagret är exakt den mängd ändrade data som faktiskt har gjorts, dvs. duplicati upptäckte att katalogen hade bytt namn och hanterade situationen korrekt. Detta kan ses vid körningen av det andra testet.
Sammanfattningsvis är intrycken av programmet överlag ganska positiva, inklusive en tillräcklig vänlighet mot nybörjare.
Resultat
Båda kandidaterna arbetade ganska långsamt, men överlag, jämfört med vanlig tar, finns det framsteg, åtminstone för duplicati. Priset för denna förbättring är också tydligt – en märkbar belastning
på processorn. Överlag finns det inga särskilda avvikelser vid prognos av resultaten.
Slutsatser
Om man inte har bråttom och även har reservkapacitet på processorn – passar vilket av de övervägda lösningarna, åtminstone har det genomförts ett tillräckligt stort arbete som inte bör göras om genom att skriva wrapper-skript ovanpå tar. Närvaron av kryptering är en mycket viktig egenskap om servern för säkerhetskopior inte kan litas på helt.
När man jämför med lösningar baserade på – kan prestandan vara flera gånger sämre, trots att ren tar fungerade snabbare än rsync med 20-30%.
Det finns en besparing i lagrets storlek, men endast med duplicati.
Tillkännagivande
Säkerhetskopiering, del 3: Översikt och test av duplicity, duplicati, deja dup
Backup, del 4: Översikt och test av zbackup, restic, borgbackup
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
