Den här anteckningen diskuterar säkerhetskopieringsverktyg som gör säkerhetskopior genom att skapa arkiv på en backupserver.
Bland de som uppfyller kraven finns duplicity (som har ett snyggt gränssnitt i form av deja dup) och duplicati.
Ett annat mycket anmärkningsvärt verktyg för säkerhetskopiering är dar, men eftersom det har en mycket omfattande lista med alternativ - testmetoden täcker knappt 10% av vad den är kapabel till - testar vi det inte som en del av den nuvarande cykeln.
Förväntade resultat
Eftersom båda kandidaterna skapar arkiv på ett eller annat sätt kan vanlig tjära användas som vägledning.
Dessutom kommer vi att utvärdera hur väl datalagring på lagringsservern är optimerad genom att skapa säkerhetskopior som endast innehåller skillnaden mellan en fullständig kopia och det aktuella tillståndet för filerna, eller mellan de tidigare och nuvarande arkiven (inkrementella, dekrementella, etc.) .
Beteende när du skapar säkerhetskopior:
- Ett relativt litet antal filer på backuplagringsservern (jämförbart med antalet säkerhetskopior eller storleken på data i GB), men deras storlek är ganska stor (tiotals till hundratals megabyte).
- Förvarsstorleken kommer bara att inkludera ändringar - inga dubbletter kommer att lagras, så förvarets storlek kommer att vara mindre än med rsync-baserad programvara.
- Räkna med hög CPU-belastning när du använder komprimering och/eller kryptering, och sannolikt ganska hög nätverks- och diskbelastning om arkiverings- och/eller krypteringsprocessen körs på en backuplagringsserver.
Låt oss köra följande kommando som ett referensvärde:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Utföranderesultaten var följande:
Utförandetid 3m12s. Det kan ses att hastigheten begränsas av diskundersystemet för backuplagringsservern, som i exemplet med . Bara lite snabbare, för... inspelningen går till en fil.
För att utvärdera komprimering, låt oss köra samma alternativ, men aktivera komprimering på backupserversidan:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Resultaten är:
Utförandetid 10m11s. Med största sannolikhet är flaskhalsen enkelflödeskompressorn på den mottagande änden.
Samma kommando, men med komprimering överförd till servern med originaldata för att testa hypotesen att flaskhalsen är en entrådig kompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Det blev så här:
Utförandetiden var 9m37s. Belastningen på en kärna vid kompressorn är tydligt synlig, eftersom Nätverksöverföringshastigheten och belastningen på källdiskens undersystem är liknande.
För att utvärdera kryptering kan du använda openssl eller gpg genom att ansluta ett extra kommando openssl eller gpg i rör. Som referens kommer det att finnas ett kommando som detta:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Resultaten kom ut så här:
Exekveringstiden visade sig vara 10m30s, eftersom 2 processer kördes på den mottagande sidan - flaskhalsen är återigen en entrådig kompressor, plus små krypteringsoverhead.
UPD: På begäran av bliznezz lägger jag till tester med pigz. Om du bara använder kompressorn skulle det ta 6m30s, lägger du även till kryptering skulle det vara cirka 7m. Nedgången i den nedre grafen är en diskcache som inte har tömts:
Dubbletttestning
Duplicity är ett pythonprogram för säkerhetskopiering genom att skapa krypterade arkiv i tjärformat.
För inkrementella arkiv används librsync, så du kan förvänta dig beteendet som beskrivs i .
Säkerhetskopior kan krypteras och signeras med gnupg, vilket är viktigt när du använder olika leverantörer för att lagra säkerhetskopior (s3, backblaze, gdrive, etc.)
Låt oss se vad resultatet blir:
Det här är resultaten vi fick när vi körde utan kryptering
spoiler
Körtid för varje testkörning:
Lansering 1
Lansering 2
Lansering 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Och här är resultaten när gnupg-kryptering är aktiverad, med en nyckelstorlek på 2048 bitar:
Drifttid på samma data, med kryptering:
Lansering 1
Lansering 2
Lansering 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blockstorleken indikerades - 512 megabyte, vilket är tydligt synligt i graferna; Processorbelastningen låg faktiskt kvar på 50 %, vilket innebär att programmet inte använder mer än en processorkärna.
Principen för programmets funktion är också ganska tydligt: de tog en bit data, komprimerade den och skickade den till en backuplagringsserver, vilket kan vara ganska långsamt.
En annan funktion är den förutsägbara körtiden för programmet, som endast beror på storleken på de ändrade data.
Att aktivera kryptering ökade inte programmets körtid nämnvärt, men det ökade processorbelastningen med cirka 10 %, vilket kan vara en ganska trevlig bonus.
Tyvärr kunde det här programmet inte korrekt upptäcka situationen med katalogbytet, och den resulterande lagringsstorleken visade sig vara lika med storleken på ändringarna (dvs. alla 18 GB), men möjligheten att använda en opålitlig server för säkerhetskopiering tydligt täcker detta beteende.
Dubbletttestning
Denna programvara är skriven i C# och körs med en uppsättning bibliotek från Mono. Det finns ett GUI såväl som en CLI-version.
Den ungefärliga listan över huvudfunktionerna liknar duplicity, inklusive olika backuplagringsleverantörer, men till skillnad från duplicity är de flesta funktioner tillgängliga utan tredjepartsverktyg. Huruvida detta är ett plus eller ett minus beror på det specifika fallet, men för nybörjare är det troligtvis lättare att ha en lista över alla funktioner framför dem på en gång, snarare än att behöva installera ytterligare paket för python, som är fallet med dubbelhet.
En annan liten nyans - programmet skriver aktivt en lokal sqlite-databas på uppdrag av användaren som startar säkerhetskopieringen, så du måste dessutom se till att den nödvändiga databasen är korrekt specificerad varje gång processen startas med hjälp av cli. När du arbetar genom GUI eller WEBGUI kommer detaljer att döljas för användaren.
Låt oss se vilka indikatorer denna lösning kan ge:
Om du stänger av kryptering (och WEBGUI rekommenderar inte att du gör detta) blir resultatet följande:
Timmar:
Lansering 1
Lansering 2
Lansering 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Med kryptering aktiverad, med aes, ser det ut så här:
Timmar:
Lansering 1
Lansering 2
Lansering 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Och om du använder det externa programmet gnupg kommer följande resultat ut:
Lansering 1
Lansering 2
Lansering 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Som du kan se kan programmet fungera i flera trådar, men detta gör det inte till en mer produktiv lösning, och om du jämför krypteringsarbetet så startar det ett externt program
visade sig vara snabbare än att använda biblioteket från Mono-setet. Detta kan bero på att det externa programmet är mer optimerat.
En annan trevlig sak var det faktum att storleken på förvaret tar exakt lika mycket som den faktiska ändrade datan, d.v.s. duplicati upptäckte ett byte av katalog och hanterade denna situation korrekt. Detta kan ses när du kör det andra testet.
Sammantaget ganska positiva intryck av programmet, inklusive att vara ganska vänlig mot nybörjare.
Resultat
Båda kandidaterna arbetade ganska långsamt, men i allmänhet, jämfört med vanlig tjära, finns det framsteg, åtminstone med duplicati. Priset för sådana framsteg är också tydligt - en märkbar börda
processor. Generellt sett finns det inga speciella avvikelser när det gäller att förutsäga resultaten.
Resultat
Om du inte behöver rusa någonstans, och dessutom har en extra processor, kommer någon av de övervägda lösningarna att göra, i alla fall har ganska mycket arbete gjorts som inte bör upprepas genom att skriva omslagsskript ovanpå tar . Förekomsten av kryptering är en mycket nödvändig egenskap om servern för lagring av säkerhetskopior inte kan litas fullt ut.
Jämfört med lösningsbaserade - prestandan kan vara flera gånger sämre, trots att tar i sin rena form fungerade 20-30% snabbare än rsync.
Det finns besparingar på förvarets storlek, men bara med duplikat.
Meddelande
Säkerhetskopiering del 3: Granska och testa duplicity, duplicati, deja dup
Backup Del 4: Granskning och testning av zbackup, restic, borgbackup
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