Dette notatet diskuterer sikkerhetskopieringsverktøy som utfører sikkerhetskopiering ved å lage arkiver på en backupserver.
Blant de som oppfyller kravene er duplicity (som har et fint grensesnitt i form av deja dup) og duplicati.
Et annet veldig bemerkelsesverdig sikkerhetskopieringsverktøy er dar, men siden det har en veldig omfattende liste med alternativer - testmetoden dekker knapt 10% av hva den er i stand til - tester vi den ikke som en del av den nåværende syklusen.
Forventede resultater
Siden begge kandidatene lager arkiver på en eller annen måte, kan vanlig tjære brukes som veiledning.
I tillegg vil vi evaluere hvor godt datalagring på lagringsserveren er optimalisert ved å lage sikkerhetskopier som kun inneholder forskjellen mellom en fullstendig kopi og den nåværende tilstanden til filene, eller mellom de forrige og nåværende arkivene (inkrementelle, dekrementelle, etc.) .
Atferd når du lager sikkerhetskopier:
- Et relativt lite antall filer på lagringsserveren for sikkerhetskopiering (sammenlignbar med antall sikkerhetskopier eller størrelsen på data i GB), men størrelsen er ganske stor (ti til hundrevis av megabyte).
- Depotstørrelsen vil kun inkludere endringer - ingen duplikater vil bli lagret, så depotstørrelsen vil være mindre enn med rsync-basert programvare.
- Forvent stor CPU-belastning når du bruker komprimering og/eller kryptering, og sannsynligvis ganske høy nettverks- og diskbelastning hvis arkiverings- og/eller krypteringsprosessen kjører på en backuplagringsserver.
La oss kjøre følgende kommando som en referanseverdi:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Utførelsesresultatene var som følger:
Gjennomføringstid 3m12s. Det kan sees at hastigheten er begrenset av diskundersystemet til backuplagringsserveren, som i eksemplet med . Bare litt raskere, fordi... opptaket går til én fil.
La oss også kjøre det samme alternativet for å evaluere komprimering, men aktivere komprimering på backupserversiden:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Resultatene er:
Gjennomføringstid 10m11s. Mest sannsynlig er flaskehalsen enkeltstrømskompressoren på mottakerenden.
Den samme kommandoen, men med komprimering overført til serveren med de originale dataene for å teste hypotesen om at flaskehalsen er en entrådet kompressor.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Det ble slik:
Utførelsestiden var 9m37s. Belastningen på den ene kjernen ved kompressoren er godt synlig, pga Nettverksoverføringshastigheten og belastningen på kildediskens undersystem er like.
For å evaluere kryptering kan du bruke openssl eller gpg ved å koble til en ekstra kommando openssl eller gpg i rør. For referanse vil det 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"Resultatene kom slik ut:
Utførelsestiden viste seg å være 10m30s, siden 2 prosesser kjørte på mottakersiden - flaskehalsen er igjen en en-trådet kompressor, pluss liten kryptering overhead.
OPP: På forespørsel fra bliznezz legger jeg til tester med pigz. Hvis du bare bruker kompressoren, vil det ta 6m30s, hvis du også legger til kryptering, vil det være ca. 7m. Fallet i den nederste grafen er en diskbuffer som ikke er tømt:
Duplikattesting
Duplicity er en python-programvare for sikkerhetskopiering ved å lage krypterte arkiver i tjæreformat.
For inkrementelle arkiver brukes librsync, slik at du kan forvente atferden beskrevet i .
Sikkerhetskopier kan krypteres og signeres med gnupg, noe som er viktig når du bruker forskjellige leverandører for lagring av sikkerhetskopier (s3, backblaze, gdrive, etc.)
La oss se hva resultatene er:
Dette er resultatene vi fikk når vi kjørte uten kryptering
spoiler
Kjøretid for hver testkjøring:
Lansering 1
Lansering 2
Lansering 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Og her er resultatene når gnupg-kryptering er aktivert, med en nøkkelstørrelse på 2048 biter:
Driftstid på samme data, med kryptering:
Lansering 1
Lansering 2
Lansering 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blokkstørrelsen ble indikert - 512 megabyte, som er tydelig synlig i grafene; Prosessorbelastningen holdt seg faktisk på 50 %, noe som betyr at programmet ikke bruker mer enn én prosessorkjerne.
Prinsippet for programmets drift er også ganske tydelig: de tok et stykke data, komprimerte det og sendte det til en backuplagringsserver, som kan være ganske treg.
En annen funksjon er den forutsigbare kjøretiden til programmet, som kun avhenger av størrelsen på de endrede dataene.
Aktivering av kryptering økte ikke programmets kjøretid nevneverdig, men det økte prosessorbelastningen med omtrent 10 %, noe som kan være en ganske fin bonus.
Dessverre klarte ikke dette programmet å oppdage situasjonen riktig med katalogomdøpningen, og den resulterende depotstørrelsen viste seg å være lik størrelsen på endringene (dvs. alle 18 GB), men muligheten til å bruke en ikke-klarert server for sikkerhetskopiering tydelig dekker denne oppførselen.
Duplikattesting
Denne programvaren er skrevet i C# og kjører ved hjelp av et sett med biblioteker fra Mono. Det er en GUI så vel som en CLI-versjon.
Den omtrentlige listen over hovedfunksjonene ligner på duplisitet, inkludert ulike leverandører av backuplagring, men i motsetning til duplisitet er de fleste funksjonene tilgjengelige uten tredjepartsverktøy. Om dette er et pluss eller et minus avhenger av det spesifikke tilfellet, men for nybegynnere er det mest sannsynlig lettere å ha en liste over alle funksjonene foran seg på en gang, i stedet for å måtte installere tilleggspakker for python, som det er. saken med dobbelthet.
En annen liten nyanse - programmet skriver aktivt en lokal sqlite-database på vegne av brukeren som starter sikkerhetskopieringen, så du må i tillegg sørge for at den nødvendige databasen er riktig spesifisert hver gang prosessen startes ved å bruke cli. Når du arbeider gjennom GUI eller WEBGUI, vil detaljer bli skjult for brukeren.
La oss se hvilke indikatorer denne løsningen kan produsere:
Hvis du slår av kryptering (og WEBGUI anbefaler ikke å gjøre dette), er resultatene som følger:
Timer:
Lansering 1
Lansering 2
Lansering 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Med kryptering aktivert, ved hjelp av aes, ser det slik ut:
Timer:
Lansering 1
Lansering 2
Lansering 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Og hvis du bruker det eksterne programmet gnupg, kommer følgende resultater ut:
Lansering 1
Lansering 2
Lansering 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Som du kan se, kan programmet fungere i flere tråder, men dette gjør det ikke til en mer produktiv løsning, og hvis du sammenligner krypteringsarbeidet, starter det et eksternt program
viste seg å være raskere enn å bruke biblioteket fra Mono-settet. Dette kan skyldes at det eksterne programmet er mer optimalisert.
Et hyggelig poeng var også det faktum at størrelsen på depotet tar nøyaktig like mye som de faktisk endrede dataene, d.v.s. duplicati oppdaget et katalognavn og håndterte denne situasjonen på riktig måte. Dette kan sees når du kjører den andre testen.
Totalt sett ganske positive inntrykk av programmet, inkludert å være ganske vennlig mot nybegynnere.
Funn
Begge kandidatene jobbet ganske sakte, men generelt sett, sammenlignet med vanlig tjære, er det fremgang, i hvert fall med duplicati. Prisen på en slik fremgang er også klar - en merkbar belastning
prosessor. Generelt er det ingen spesielle avvik i å forutsi resultatene.
Funn
Hvis du ikke trenger å skynde deg noe sted, og i tillegg har en ekstra prosessor, vil enhver av løsningene som vurderes gjøre, uansett, det er gjort ganske mye arbeid som ikke bør gjentas ved å skrive wrapper-skript på toppen av tjære . Tilstedeværelsen av kryptering er en svært nødvendig egenskap hvis serveren for lagring av sikkerhetskopier ikke kan stoles fullt ut.
Sammenlignet med løsningsbasert - ytelsen kan være flere ganger dårligere, til tross for at tjære i sin rene form fungerte 20-30% raskere enn rsync.
Det er besparelser på depotstørrelse, men bare med duplikater.
Kunngjøring
Backup del 3: Gjennomgå og test duplicity, duplicati, deja dup
Backup Del 4: Gjennomgang og testing av zbackup, restic, borgbackup
Sikkerhetskopiering del 5: Tester bacula og veeam backup for linux
Sikkerhetskopiering del 6: Sammenligning av sikkerhetskopieringsverktøy
Backup Del 7: Konklusjoner
Postet av: Pavel Demkovich
Kilde: www.habr.com