Denne artikkelen vil vurdere sikkerhetskopieringsprogramvare som, ved å dele datastrømmen i separate komponenter (biter), danner et depot.
Depotkomponenter kan komprimeres og krypteres ytterligere, og viktigst av alt - under gjentatte sikkerhetskopieringsprosesser - gjenbrukes.
En sikkerhetskopi i et slikt depot er en navngitt kjede av komponenter koblet til hverandre, for eksempel basert på ulike hash-funksjoner.
Det er flere lignende løsninger, jeg vil fokusere på 3: zbackup, borgbackup og restic.
Forventede resultater
Siden alle søkere krever opprettelse av et depot på en eller annen måte, vil en av de viktigste faktorene være å anslå størrelsen på depotet. Ideelt sett bør størrelsen ikke være mer enn 13 GB i henhold til den aksepterte metoden, eller enda mindre - med forbehold om god optimalisering.
Det er også svært ønskelig å kunne lage sikkerhetskopier av filer direkte, uten å bruke arkivere som tar, samt arbeide med ssh/sftp uten tilleggsverktøy som rsync og sshfs.
Atferd når du lager sikkerhetskopier:
- Størrelsen på depotet vil være lik størrelsen på endringene, eller mindre.
- Tung CPU-belastning forventes ved bruk av komprimering og/eller kryptering, og ganske høy nettverks- og diskbelastning er sannsynlig hvis arkiverings- og/eller krypteringsprosessen kjører på en backuplagringsserver.
- Hvis depotet er skadet, er det sannsynligvis en forsinket feil både når du oppretter nye sikkerhetskopier og når du prøver å gjenopprette. Det er nødvendig å planlegge ytterligere tiltak for å sikre integriteten til depotet eller bruke innebygde verktøy for å sjekke integriteten.
Arbeid med tjære er tatt som en referanseverdi, som ble vist i en av de tidligere artiklene.
Tester zbackup
Den generelle mekanismen til zbackup er at programmet finner områder i inngangsdatastrømmen som inneholder de samme dataene, og deretter eventuelt komprimerer og krypterer dem, og lagrer hvert område bare én gang.
Deduplisering bruker en 64-biters ringhash-funksjon med et skyvevindu for å se etter byte-for-byte-treff mot eksisterende datablokker (ligner på hvordan rsync implementerer det).
Multi-threaded lzma og lzo brukes til komprimering, og aes for kryptering. De nyeste versjonene har muligheten til å slette gamle data fra depotet i fremtiden.
Programmet er skrevet i C++ med minimale avhengigheter. Forfatteren var tilsynelatende inspirert av unix-veien, så programmet godtar data på stdin når du lager sikkerhetskopier, og produserer en lignende datastrøm på stdout ved gjenoppretting. Dermed kan zbackup brukes som en veldig god "byggestein" når du skriver dine egne backupløsninger. For eksempel har forfatteren av artikkelen brukt dette programmet som det viktigste sikkerhetskopieringsverktøyet for hjemmemaskiner siden ca. 2014.
Datastrømmen vil være en vanlig tar med mindre annet er oppgitt.
La oss se hva resultatene er:
Arbeidet ble sjekket i 2 alternativer:
- et depot opprettes og zbackup startes på serveren med kildedataene, deretter overføres innholdet i depotet til backuplagringsserveren.
- et repository opprettes på backuplagringsserveren, zbackup startes via ssh på backuplagringsserveren, og data sendes til den via pipe.
Resultatene av det første alternativet var som følger: 43m11s - når du bruker et ukryptert depot og lzma-kompressoren, 19m13s - når du erstatter kompressoren med lzo.
Belastningen på serveren med de originale dataene var som følger (et eksempel med lzma er vist; med lzo var det omtrent det samme bildet, men andelen av rsync var omtrent en fjerdedel av tiden):
Det er klart at en slik backup-prosess kun egner seg for relativt sjeldne og små endringer. Det er også sterkt tilrådelig å begrense zbackup til 1 tråd, ellers vil det være en veldig høy CPU-belastning, fordi Programmet er veldig bra til å jobbe i flere tråder. Belastningen på disken var liten, noe som generelt ikke ville vært merkbar med et moderne ssd-basert diskundersystem. Du kan også tydelig se starten på prosessen med å synkronisere depotdata til en ekstern server; operasjonshastigheten er sammenlignbar med vanlig rsync og avhenger av ytelsen til diskundersystemet til backuplagringsserveren. Ulempen med denne tilnærmingen er lagring av et lokalt depot og som et resultat duplisering av data.
Mer interessant og anvendelig i praksis er det andre alternativet, som kjører zbackup direkte på backuplagringsserveren.
Først vil vi sjekke operasjonen uten å bruke kryptering med lzma-kompressoren:
Kjøretid for hver testkjøring:
Lansering 1
Lansering 2
Lansering 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Hvis du aktiverer kryptering ved hjelp av aes, er resultatene ganske nærme:
Driftstid på samme data, med kryptering:
Lansering 1
Lansering 2
Lansering 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Hvis kryptering er kombinert med komprimering ved hjelp av lzo, ser det slik ut:
Timer:
Lansering 1
Lansering 2
Lansering 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Størrelsen på det resulterende depotet var relativt den samme på 13 GB. Dette betyr at deduplisering fungerer som den skal. På allerede komprimerte data gir bruk av lzo en merkbar effekt; når det gjelder total driftstid, kommer zbackup nær duplicity/duplicati, men ligger 2-5 ganger bak de basert på librsync.
Fordelene er åpenbare - sparer diskplass på backuplagringsserveren. Når det gjelder verktøy for lagringskontroll, gir ikke forfatteren av zbackup dem; det anbefales å bruke en feiltolerant diskmatrise eller skyleverandør.
Totalt sett et veldig godt inntrykk, til tross for at prosjektet har stått stille i ca. 3 år (siste funksjonsforespørsel var for ca. ett år siden, men uten svar).
Tester borgbackup
Borgbackup er en gaffel på loftet, et annet system som ligner på zbackup. Den er skrevet i python og har en liste over funksjoner som ligner på zbackup, men kan i tillegg:
- Monter sikkerhetskopier via sikring
- Sjekk lagerinnholdet
- Arbeid i klient-server-modus
- Bruk ulike kompressorer for data, samt heuristisk bestemmelse av filtypen ved komprimering.
- 2 krypteringsalternativer, aes og blake
- Innebygd verktøy for
ytelseskontroller
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Resultatene ble som følger:
CZ-BIG 96.51 MB/s (10 100.00 MB helt null-filer: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB helt null-filer: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB helt null-filer: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB helt null-filer: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB tilfeldige filer: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB tilfeldige filer: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB tilfeldige filer: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB tilfeldige filer: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB helt null-filer: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB helt null-filer: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB helt null-filer: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB helt null-filer: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB tilfeldige filer: 26.45s)
RR-MIDDELS 68.90 MB/s (1000 1.00 MB tilfeldige filer: 14.51s)
UR-MIDDELS 347.24 MB/s (1000 1.00 MB tilfeldige filer: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB tilfeldige filer: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB helt null filer: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB helt null filer: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB helt null filer: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB helt null filer: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB tilfeldige filer: 14.60s)
RR-LITEN 31.27 MB/s (10000 10.00 kB tilfeldige filer: 3.20s)
UR-LITEN 12.28 MB/s (10000 10.00 kB tilfeldige filer: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB tilfeldige filer: 5.32s)
Ved testing vil komprimeringsheuristikk bli brukt for å bestemme filtypen (komprimering auto), og resultatene vil være som følger:
Først, la oss sjekke hvordan det fungerer uten kryptering:
Timer:
Lansering 1
Lansering 2
Lansering 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Hvis du aktiverer depotautorisasjon (autentisert modus), vil resultatene være nærme:
Timer:
Lansering 1
Lansering 2
Lansering 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Når aes-kryptering ble aktivert, ble ikke resultatene dårligere:
Lansering 1
Lansering 2
Lansering 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Og hvis du endrer aes til blake, vil situasjonen forbedre seg fullstendig:
Timer:
Lansering 1
Lansering 2
Lansering 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Som i tilfellet med zbackup, var depotstørrelsen 13 GB og til og med litt mindre, noe som vanligvis forventes. Jeg var veldig fornøyd med kjøretiden; den kan sammenlignes med løsninger basert på librsync, og gir mye bredere muligheter. Jeg var også fornøyd med muligheten til å sette ulike parametere gjennom miljøvariabler, noe som gir en svært alvorlig fordel når man bruker borgbackup i automatisk modus. Jeg var også fornøyd med belastningen under backup: etter prosessorbelastningen å dømme fungerer borgbackup i 1 tråd.
Det var ingen spesielle ulemper ved bruk.
restisk testing
Til tross for at restic er en ganske ny løsning (de to første kandidatene ble kjent tilbake i 2 og eldre), har den ganske gode egenskaper. Skrevet i Go.
Sammenlignet med zbackup gir det i tillegg:
- Kontrollere integriteten til depotet (inkludert innsjekking av deler).
- En enorm liste over støttede protokoller og leverandører for lagring av sikkerhetskopier, samt støtte for rclone - rsync for skyløsninger.
- Sammenligner 2 sikkerhetskopier med hverandre.
- Montering av depotet via sikring.
Generelt er listen over funksjoner ganske nær borgbackup, noen steder mer, andre mindre. En av funksjonene er at det ikke er noen måte å deaktivere kryptering, og derfor vil sikkerhetskopier alltid være kryptert. La oss se i praksis hva som kan presses ut av denne programvaren:
Resultatene ble som følger:
Timer:
Lansering 1
Lansering 2
Lansering 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Ytelsesresultatene er også sammenlignbare med rsync-baserte løsninger og generelt svært nær borgbackup, men CPU-belastningen er høyere (flere tråder kjører) og sagtann.
Mest sannsynlig er programmet begrenset av ytelsen til diskundersystemet på datalagringsserveren, som allerede var tilfellet med rsync. Lagringsstørrelsen var 13 GB, akkurat som zbackup eller borgbackup, var det ingen åpenbare ulemper ved bruk av denne løsningen.
Funn
Faktisk oppnådde alle kandidater lignende resultater, men til forskjellige priser. Borgbackup presterte best av alt, restic var litt tregere, zbackup er nok ikke verdt å begynne å bruke,
og hvis den allerede er i bruk, prøv å endre den til borgbackup eller restic.
Funn
Den mest lovende løsningen ser ut til å være restisk, fordi... det er han som har det beste forholdet mellom evner og driftshastighet, men la oss ikke skynde oss til generelle konklusjoner for nå.
Borgbackup er i utgangspunktet ikke dårligere, men zbackup er nok bedre erstattet. Riktignok kan zbackup fortsatt brukes for å sikre at 3-2-1-regelen fungerer. For eksempel i tillegg til (lib)rsync-baserte sikkerhetskopieringsfasiliteter.
Kunngjøring
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