Denne note diskuterer sikkerhedskopieringsværktøjer, der udfører sikkerhedskopiering ved at oprette arkiver på en backupserver.
Blandt dem der opfylder kravene er duplicity (som har en fin grænseflade i form af deja dup) og duplicati.
Et andet meget bemærkelsesværdigt backupværktøj er dar, men da det har en meget omfattende liste af muligheder - testmetoden dækker knap 10% af, hvad det er i stand til - tester vi det ikke som en del af den nuværende cyklus.
Forventede resultater
Da begge kandidater opretter arkiver på den ene eller anden måde, kan almindelig tjære bruges som vejledning.
Derudover vil vi evaluere, hvor godt datalagring på lagerserveren er optimeret ved at oprette sikkerhedskopier, der kun indeholder forskellen mellem en fuld kopi og den aktuelle tilstand af filerne, eller mellem de tidligere og nuværende arkiver (inkrementelle, dekrementelle osv.) .
Adfærd ved oprettelse af sikkerhedskopier:
- Et relativt lille antal filer på backup-lagerserveren (sammenlignelig med antallet af sikkerhedskopier eller størrelsen af data i GB), men deres størrelse er ret stor (ti til hundreder af megabyte).
- Lagerstørrelsen vil kun inkludere ændringer - ingen dubletter vil blive gemt, så lagerstørrelsen vil være mindre end med rsync-baseret software.
- Forvent stor CPU-belastning, når du bruger komprimering og/eller kryptering, og sandsynligvis ret høj netværks- og diskbelastning, hvis arkiverings- og/eller krypteringsprocessen kører på en backup-lagerserver.
Lad os køre følgende kommando som referenceværdi:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Udførelsesresultaterne var som følger:
Udførelsestid 3m12s. Det kan ses, at hastigheden er begrænset af diskundersystemet på backup-lagerserveren, som i eksemplet med . Kun lidt hurtigere, fordi... optagelsen går til én fil.
Lad os også køre den samme mulighed for at evaluere komprimering, men aktivere komprimering på backupserversiden:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Resultaterne er:
Udførelsestid 10m11s. Flaskehalsen er højst sandsynligt enkeltstrømskompressoren i den modtagende ende.
Den samme kommando, men med komprimering overført til serveren med de originale data for at teste hypotesen om, at flaskehalsen er en enkelt-trådet kompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Det blev sådan her:
Udførelsestiden var 9m37s. Belastningen på den ene kerne ved kompressoren er tydeligt synlig, pga Netværksoverførselshastigheden og belastningen på kildediskens undersystem er ens.
For at evaluere kryptering kan du bruge openssl eller gpg ved at forbinde en ekstra kommando openssl eller gpg i rør. Til reference vil der være en kommando som denne:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Resultaterne kom således ud:
Eksekveringstiden viste sig at være 10m30s, da 2 processer kørte på modtagersiden - flaskehalsen er igen en enkelt-gevind kompressor, plus små kryptering overhead.
UPS: Efter anmodning fra bliznezz tilføjer jeg tests med pigz. Hvis du kun bruger kompressoren, ville det tage 6m30s, hvis du også tilføjer kryptering, ville det være omkring 7m. Dykket i den nederste graf er en ikke-tømt diskcache:
Duplikattest
Duplicity er en python-software til backup ved at skabe krypterede arkiver i tjæreformat.
Til inkrementelle arkiver bruges librsync, så du kan forvente den adfærd, der er beskrevet i .
Sikkerhedskopier kan krypteres og signeres ved hjælp af gnupg, hvilket er vigtigt, når du bruger forskellige udbydere til lagring af sikkerhedskopier (s3, backblaze, gdrive osv.)
Lad os se, hvad resultaterne er:
Dette er de resultater, vi fik, når vi kørte uden kryptering
spoiler
Kørselstid for hver testkørsel:
Lancering 1
Lancering 2
Lancering 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Og her er resultaterne, når gnupg-kryptering er aktiveret, med en nøglestørrelse på 2048 bit:
Driftstid på de samme data, med kryptering:
Lancering 1
Lancering 2
Lancering 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blokstørrelsen blev angivet - 512 megabyte, hvilket er tydeligt synligt i graferne; Processorbelastningen forblev faktisk på 50%, hvilket betyder, at programmet ikke bruger mere end én processorkerne.
Princippet for programmets drift er også ret tydeligt synligt: de tog et stykke data, komprimerede det og sendte det til en backup-lagringsserver, som kan være ret langsom.
En anden funktion er den forudsigelige køretid for programmet, som kun afhænger af størrelsen af de ændrede data.
Aktivering af kryptering øgede ikke programmets køretid markant, men det øgede processorbelastningen med omkring 10 %, hvilket kan være en ganske fin bonus.
Desværre var dette program ikke i stand til korrekt at detektere situationen med omdøbningen af biblioteket, og den resulterende lagerstørrelse viste sig at være lig med størrelsen af ændringerne (dvs. alle 18 GB), men evnen til at bruge en server, der ikke er tillid til til sikkerhedskopiering klart dækker over denne adfærd.
Duplikattest
Denne software er skrevet i C# og kører ved hjælp af et sæt biblioteker fra Mono. Der er en GUI såvel som en CLI-version.
En omtrentlig liste over hovedfunktionerne ligner dobbelthed, inklusive forskellige udbydere af backuplager, men i modsætning til dobbelthed er de fleste funktioner tilgængelige uden tredjepartsværktøjer. Om dette er et plus eller et minus afhænger af det konkrete tilfælde, men for begyndere er det højst sandsynligt nemmere at have en liste over alle funktionerne foran sig på én gang i stedet for at skulle installere yderligere pakker til python, som det er. sagen med dobbelthed.
En anden lille nuance - programmet skriver aktivt en lokal sqlite-database på vegne af den bruger, der starter sikkerhedskopieringen, så du skal desuden sikre dig, at den nødvendige database er korrekt angivet, hver gang processen startes ved hjælp af cli. Når du arbejder gennem GUI eller WEBGUI, vil detaljer blive skjult for brugeren.
Lad os se, hvilke indikatorer denne løsning kan producere:
Hvis du slår kryptering fra (og WEBGUI anbefaler ikke at gøre dette), er resultaterne som følger:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Med kryptering aktiveret, ved hjælp af aes, ser det sådan ud:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Og hvis du bruger det eksterne program gnupg, kommer følgende resultater ud:
Lancering 1
Lancering 2
Lancering 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Som du kan se, kan programmet fungere i flere tråde, men det gør det ikke til en mere produktiv løsning, og hvis du sammenligner krypteringsarbejdet, starter det et eksternt program
viste sig at være hurtigere end at bruge biblioteket fra Mono-sættet. Det kan skyldes, at det eksterne program er mere optimeret.
En anden fin ting var, at størrelsen af depotet tager præcis lige så meget som de faktiske ændrede data, dvs. duplicati opdagede et omdøbning af mappen og håndterede denne situation korrekt. Dette kan ses, når du kører den anden test.
Samlet set ret positive indtryk af programmet, herunder at være ret venlig over for nybegyndere.
Fund
Begge kandidater arbejdede ret langsomt, men generelt set er der fremskridt sammenlignet med almindelig tjære, i det mindste med duplicati. Prisen for sådanne fremskridt er også klar - en mærkbar byrde
processor. Generelt er der ingen særlige afvigelser i at forudsige resultaterne.
Fund
Hvis du ikke har brug for at skynde dig nogen steder, og også har en ekstra processor, vil enhver af de overvejede løsninger klare, under alle omstændigheder er der gjort en del arbejde, som ikke bør gentages ved at skrive wrapper scripts oven på tjære . Tilstedeværelsen af kryptering er en meget nødvendig egenskab, hvis serveren til lagring af sikkerhedskopier ikke kan stoles fuldt ud.
Sammenlignet med løsningsbaserede - ydeevnen kan være flere gange dårligere, på trods af at tjære i sin rene form virkede 20-30% hurtigere end rsync.
Der er besparelser på størrelsen af depotet, men kun med duplicati.
annoncering
Backup Del 3: Gennemgå og test duplicity, duplicati, deja dup
Backup Del 4: Gennemgang og test af zbackup, restic, borgbackup
Backup Del 5: Test af bacula og veeam backup til linux
Sikkerhedskopiering Del 6: Sammenligning af sikkerhedskopieringsværktøjer
Backup Del 7: Konklusioner
Sendt af: Pavel Demkovich
Kilde: www.habr.com