I denne note vil vi se på sikkerhedskopieringsværktøjer, der udfører sikkerhedskopiering ved at oprette arkiver på en sikkerhedskopiserver.
Blandt dem, der opfylder kravene, er duplicity (som har et flot interface i form af deja dup) og duplicati.
Et andet bemærkelsesværdigt sikkerhedskopieringsværktøj er dar, men da det har en ret omfattende liste af muligheder, dækker testmetodologien næppe 10 % af, hvad det er i stand til — derfor tester vi det ikke i denne cyklus.
Forventede resultater
Da begge kandidater på en eller anden måde opretter arkiver, kan vi bruge almindelig tar som reference.
Derudover vil vi vurdere, hvor godt datalagring på sikkerhedskopiserveren optimeres ved at oprette sikkerhedskopier, der kun indeholder forskellen mellem det fulde billede og de nuværende filers tilstand, eller mellem tidligere og nuværende arkiver (inkrementelle, dekrementale osv.).
Adfærd ved sikkerhedskopiering:
- Et relativt lille antal filer på sikkerhedskopiserverens lager (sammenligneligt med antallet af sikkerhedskopier eller mængden af data i GB), men derimod en betydelig størrelse på disse (titiske, hundrede megabyte).
- Størrelsen på repository vil kun inkludere ændringer — duplikater vil ikke blive gemt, således at repository-størrelsen vil være mindre end ved brug af software baseret på rsync.
- Der forventes en stor belastning på processoren ved brug af komprimering og/eller kryptering, samt sandsynligvis en betydelig belastning på netværket og disksystemet, hvis arkiverings- og/eller krypteringsprocessen kører på sikkerhedskopiserver.
Som referenceværdi vil vi køre følgende kommando:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Resultaterne af kørslen blev som følgende:
Køretid 3m12s. Det er tydeligt, at hastigheden er begrænset af disksystemet på sikkerhedskopiserver, ligesom i eksemplet med . Bare lidt hurtigere, da skrivningen går til én fil.
Også for at vurdere komprimering vil vi køre den samme variant, men inkludere komprimering på siden af sikkerhedskopiseringsserveren:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Resultaterne er som følger:
Køretid 10m11s. Sandsynligvis er flaskehalsen den enkelttrådede kompressor på modtagersiden.
Det samme kommando, men med overførsel af kompression til serveren med de originale data for at teste hypotesen om, at flaskehalsen er en enkelttrådskompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Det viste sig at være:
Udførelsestiden var 9m37s. Det er tydeligt at se belastningen på én kerne fra kompressoren, da netværksoverførslen og belastningen på kilde-diskundersystemet — begge er ens.
For at vurdere kryptering kan du bruge openssl eller gpg, ved at tilføje kommandoen openssl eller gpg i pipen. Som reference vil den se sådan ud:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Resultaterne blev som følger:
Udførelsestiden blev 10m30s, da 2 processer blev startet på modtagerens side — flaskehalsen igen var den enkelttråds kompressor, plus små overheadomkostninger til kryptering.
OPD: På anmodning fra bliznezz tilføjer jeg testene med pigz. Hvis kun kompressoren anvendes — tog det 6m30s, hvis der også tilføjes kryptering — cirka 7m. Faldet i den nederste graf er den ikke-udledte diskcacher:
Testning af duplicity
Duplicity — software skrevet i python til sikkerhedskopiering ved at oprette krypterede arkiver i tar-format.
For inkrementelle arkiver anvendes librsync, så man kan forvente den adfærd, der er beskrevet i .
Sikkerhedskopier kan krypteres og signeres ved hjælp af gnupg, hvilket er vigtigt, når man bruger forskellige udbydere til lagring af sikkerhedskopier (s3, backblaze, gdrive osv.)
Lad os se, hvad resultaterne bliver:
Her er resultaterne ved kørsel uden kryptering
spoiler
Tid for hver teststart:
Start 1
Start 2
Start 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Og her er resultaterne ved at aktivere kryptering med gnupg, med en nøglestørrelse på 2048 bit:
Tid for arbejde med de samme data, med kryptering:
Start 1
Start 2
Start 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blokstørrelsen blev angivet til 512 megabyte, hvilket tydeligt kan ses på graferne; CPU-belastningen holdt sig reelt på omkring 50%, hvilket betyder, at programmet ikke udnytter mere end ét processorafsnit.
Det er også ret tydeligt at se principperne bag programmets drift: tag en sektion af data, komprimer dem, send dem til backup-serveren, som kan være ret langsom.
En anden funktion er det forudsigelige arbejdsforløb for programmet, som kun afhænger af størrelsen på de ændrede data.
Aktiveringen af kryptering øgede ikke programmet støtte tid særligt, men forøgede CPU-belastningen med cirka 10%, hvilket kan være en ret god bonus.
Desværre kunne dette program ikke korrekt registrere situationen med omdøbning af kataloget, og den resulterende størrelse af depotet viste sig at være lig med ændringsstørrelsen (dvs. alle 18 GB), men muligheden for at bruge en ikke-pålidelig server til sikkerhedskopiering opvejer bestemt denne adfærd.
Test af duplicati
Denne software er skrevet i C#, og kører ved hjælp af et sæt biblioteker fra Mono. Den har både et GUI samt en cli version.
Den omtrentlige liste over hovedfunktioner ligner duplicity, inklusive forskellige udbydere til opbevaring af sikkerhedskopier, men i modsætning til duplicity, er de fleste funktioner tilgængelige uden eksterne værktøjer. Om dette er en fordel eller ulempe afhænger af den specifikke situation, men for nybegyndere er det sandsynligvis lettere at have en komplet liste over alle funktioner foran sig, snarere end at skulle installere pakker til python, som det er tilfældet med duplicity.
En anden lille detalje — programmet skriver aktivt til en lokal sqlite database under navnet på den bruger, der starter sikkerhedskopieringen, så der skal holdes ekstra øje med korrekt angivelse af den nødvendige database ved hver start af processen ved brug af cli. Ved brug af GUI eller WEBGUI vil detaljerne være skjult for brugeren.
Lad os se, hvilke målinger denne løsning kan give:
Hvis krypteringen deaktiveres (hvor WEBGUI ikke anbefaler at gøre dette), er resultaterne som følger:
Tid for arbejde:
Start 1
Start 2
Start 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Med kryptering aktiveret ved brug af aes, ser det således ud:
Tid for arbejde:
Start 1
Start 2
Start 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Og hvis en ekstern program gnupg bruges, bliver outputtene sådan:
Start 1
Start 2
Start 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Som det kan ses, kan programmet arbejde i flere tråde, men det er ikke nødvendigvis en mere effektiv løsning; og hvis man sammenligner krypteringsarbejdet — kørsel af det eksterne program
blev hurtigere end brugen af biblioteket fra Mono. Dette kan skyldes, at det eksterne program er bedre optimeret.
En hyggelig ting var også, at størrelsen på repository’et præcist svarer til mængden af ændrede data, dvs. Duplicati registrerede navneændringen af mappen og håndterede situationen korrekt. Dette kan ses ved gennemførelsen af den anden test.
Generelt set er der ganske positive indtryk af programmet, inklusive dets brugervenlighed for nybegyndere.
Resultater
Begge kandidater arbejdede temmelig langsomt, men i forhold til den sædvanlige tar, er der fremskridt, især hos Duplicati. Prisen for denne forbedring er også forståelig — en betydelig belastning.
af CPU'en. Generelt er der ingen væsentlige afvigelser i resultaternes prognose.
Konklusioner
Hvis der ikke er pres for at skynde sig, og der er kapacitet i CPU’en—så er enhver af de overvejede løsninger passende, i hvert fald er der udført et betydeligt stykke arbejde, som ikke bør gentages ved at skrive wrapper-scripts ovenfor tar. Tilstedeværelsen af kryptering er en meget vigtig egenskab, hvis serveren til opbevaring af backup ikke kan være fuldstændig pålidelig.
Sammenlignet med løsninger baseret på — kan ydeevnen være flere gange dårligere, selvom ren tar arbejdede hurtigere end rsync med 20-30%.
Der er en besparelse i repository-størrelsen, men kun hos Duplicati.
Annonce
Backup, del 3: Gennemgang og test af duplicity, duplicati, deja dup
Sikkerhedskopiering, del 4: Oversigt og test af zbackup, restic, borgbackup
Sikkerhedskopiering, del 5: Test af bacula og veeam backup for linux
Sikkerhedskopiering, del 6: Sammenligning af sikkerhedskopieringsværktøjer
Backup, del 7: Konklusioner
Forfatteren af indlægget: Pavel Demkovich
Kilde: habr.com
