Denne artikel vil overveje backup-software, der ved at opdele datastrømmen i separate komponenter (bidder) danner et lager.
Lagerkomponenter kan yderligere komprimeres og krypteres, og vigtigst af alt - under gentagne sikkerhedskopieringsprocesser - genbruges.
En sikkerhedskopi i et sådant lager er en navngivet kæde af komponenter forbundet med hinanden, for eksempel baseret på forskellige hash-funktioner.
Der er flere lignende løsninger, jeg vil fokusere på 3: zbackup, borgbackup og restic.
Forventede resultater
Da alle ansøgere kræver oprettelse af et depot på den ene eller anden måde, vil en af de vigtigste faktorer være at estimere depotets størrelse. Ideelt set bør dens størrelse ikke være mere end 13 GB i henhold til den accepterede metode, eller endnu mindre - med forbehold for god optimering.
Det er også meget ønskeligt at kunne oprette sikkerhedskopier af filer direkte uden at bruge arkiveringsværktøjer som tar, samt arbejde med ssh/sftp uden yderligere værktøjer som rsync og sshfs.
Adfærd ved oprettelse af sikkerhedskopier:
- Størrelsen af depotet vil være lig med størrelsen af ændringerne eller mindre.
- Der forventes stor CPU-belastning ved brug af komprimering og/eller kryptering, og ret høj netværks- og diskbelastning er sandsynlig, hvis arkiverings- og/eller krypteringsprocessen kører på en backup-lagerserver.
- Hvis lageret er beskadiget, er en forsinket fejl sandsynligvis både ved oprettelse af nye sikkerhedskopier og ved forsøg på at gendanne. Det er nødvendigt at planlægge yderligere foranstaltninger for at sikre depotets integritet eller bruge indbyggede værktøjer til at kontrollere dets integritet.
Arbejde med tjære tages som referenceværdi, som det blev vist i en af de foregående artikler.
Tester zbackup
Den generelle mekanisme ved zbackup er, at programmet finder områder i inputdatastrømmen, der indeholder de samme data, og derefter eventuelt komprimerer og krypterer dem, og gemmer hvert område kun én gang.
Deduplikering bruger en 64-bit ring-hash-funktion med et glidende vindue til at kontrollere for byte-for-byte-matches mod eksisterende datablokke (svarende til, hvordan rsync implementerer det).
Multi-threaded lzma og lzo bruges til komprimering og aes til kryptering. De seneste versioner har mulighed for at slette gamle data fra depotet i fremtiden.
Programmet er skrevet i C++ med minimale afhængigheder. Forfatteren var tilsyneladende inspireret af unix-måden, så programmet accepterer data på stdin, når der oprettes sikkerhedskopier, og producerer en lignende datastrøm på stdout ved gendannelse. Således kan zbackup bruges som en rigtig god "byggesten", når du skriver dine egne backup-løsninger. For eksempel har forfatteren af artiklen brugt dette program som det vigtigste backupværktøj til hjemmemaskiner siden cirka 2014.
Datastrømmen vil være en almindelig tar, medmindre andet er angivet.
Lad os se, hvad resultaterne er:
Arbejdet blev tjekket i 2 muligheder:
- der oprettes et lager og zbackup startes på serveren med kildedataene, derefter overføres indholdet af lageret til backuplagerserveren.
- der oprettes et lager på backup-lagerserveren, zbackup startes via ssh på backup-lagerserveren, og data sendes til det via pipe.
Resultaterne af den første mulighed var som følger: 43m11s - ved brug af et ukrypteret depot og lzma-kompressoren, 19m13s - ved udskiftning af kompressoren med lzo.
Belastningen på serveren med de originale data var som følger (et eksempel med lzma er vist; med lzo var der omtrent det samme billede, men andelen af rsync var omkring en fjerdedel af tiden):
Det er klart, at en sådan backup-proces kun er egnet til relativt sjældne og små ændringer. Det er også stærkt tilrådeligt at begrænse zbackup til 1 tråd, ellers vil der være en meget høj CPU-belastning, fordi Programmet er meget godt til at arbejde i flere tråde. Belastningen på disken var lille, hvilket generelt ikke ville være mærkbar med et moderne ssd-baseret diskundersystem. Du kan også tydeligt se starten på processen med at synkronisere depotdata til en fjernserver; driftshastigheden er sammenlignelig med almindelig rsync og afhænger af ydeevnen af diskundersystemet på backup-lagerserveren. Ulempen ved denne tilgang er lagringen af et lokalt depot og som et resultat duplikering af data.
Mere interessant og anvendelig i praksis er den anden mulighed, der kører zbackup direkte på backup-lagringsserveren.
Først vil vi teste operationen uden at bruge kryptering med lzma-kompressoren:
Kørselstid for hver testkørsel:
Lancering 1
Lancering 2
Lancering 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Hvis du aktiverer kryptering ved hjælp af aes, er resultaterne ret tæt på:
Driftstid på de samme data, med kryptering:
Lancering 1
Lancering 2
Lancering 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Hvis kryptering kombineres med komprimering ved hjælp af lzo, ser det sådan ud:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Størrelsen af det resulterende depot var relativt den samme på 13 GB. Det betyder, at deduplikering fungerer korrekt. På allerede komprimerede data giver brugen af lzo også en mærkbar effekt; med hensyn til den samlede driftstid kommer zbackup tæt på duplicity/duplicati, men halter bagefter dem baseret på librsync med 2-5 gange.
Fordelene er indlysende - sparer diskplads på backup-lagringsserveren. Hvad angår lagerkontrolværktøjer, leverer forfatteren af zbackup dem ikke; det anbefales at bruge en fejltolerant diskarray eller cloud-udbyder.
Samlet set et meget godt indtryk, på trods af at projektet har stået stille i ca. 3 år (sidste feature-ønske var for ca. et år siden, men uden svar).
Test af borgbackup
Borgbackup er en loftsgaffel, et andet system, der ligner zbackup. Skrevet i python har den en liste over funktioner, der ligner zbackup, men kan desuden:
- Monter backups via sikring
- Tjek lagerindholdet
- Arbejd i klient-server-tilstand
- Brug forskellige kompressorer til data, samt heuristisk bestemmelse af filtypen ved komprimering.
- 2 krypteringsmuligheder, aes og blake
- Indbygget værktøj til
præstationstjek
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Resultaterne var som følger:
CZ-BIG 96.51 MB/s (10 100.00 MB helt nul filer: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB helt nul filer: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB helt nul filer: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB helt nul filer: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB tilfældige filer: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB tilfældige filer: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB tilfældige filer: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB tilfældige filer: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB helt nul filer: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB helt nul filer: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB helt nul filer: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB helt nul filer: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB tilfældige filer: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB tilfældige filer: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB tilfældige filer: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB tilfældige filer: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB helt nul filer: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB helt nul filer: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB helt nul filer: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB helt nul filer: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB tilfældige filer: 14.60s)
RR-SMALL 31.27 MB/s (10000 10.00 kB tilfældige filer: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB tilfældige filer: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB tilfældige filer: 5.32s)
Ved testning vil komprimeringsheuristik blive brugt til at bestemme filtypen (autokomprimering), og resultaterne vil være som følger:
Lad os først tjekke, hvordan det fungerer uden kryptering:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Hvis du aktiverer lagergodkendelse (godkendt tilstand), vil resultaterne være tætte:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Da aes-kryptering blev aktiveret, forværredes resultaterne ikke meget:
Lancering 1
Lancering 2
Lancering 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Og hvis du skifter aes til blake, vil situationen forbedres fuldstændig:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Som i tilfældet med zbackup var lagerstørrelsen 13 GB og endda lidt mindre, hvilket generelt forventes. Jeg var meget tilfreds med køretiden; den kan sammenlignes med løsninger baseret på librsync, hvilket giver meget bredere muligheder. Jeg var også glad for muligheden for at indstille forskellige parametre gennem miljøvariabler, hvilket giver en meget seriøs fordel ved brug af borgbackup i automatisk tilstand. Jeg var også tilfreds med belastningen under backup: at dømme efter processorbelastningen fungerer borgbackup i 1 tråd.
Der var ingen særlige ulemper ved brugen.
restisk test
På trods af at restic er en ret ny løsning (de første 2 kandidater var kendt tilbage i 2013 og ældre), har den ganske gode egenskaber. Skrevet i Go.
Sammenlignet med zbackup giver det desuden:
- Kontrol af depotets integritet (inklusive indtjekning af dele).
- En enorm liste over understøttede protokoller og udbydere til lagring af sikkerhedskopier, samt understøttelse af rclone - rsync for cloud-løsninger.
- Sammenligning af 2 sikkerhedskopier med hinanden.
- Montering af depotet via sikring.
Generelt er listen over funktioner ret tæt på borgbackup, nogle steder mere, andre mindre. En af funktionerne er, at der ikke er nogen måde at deaktivere kryptering, og derfor vil sikkerhedskopier altid være krypteret. Lad os se i praksis, hvad der kan presses ud af denne software:
Resultaterne var som følger:
Åbningstider:
Lancering 1
Lancering 2
Lancering 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Ydeevneresultaterne er også sammenlignelige med rsync-baserede løsninger og generelt meget tæt på borgbackup, men CPU-belastningen er højere (der kører flere tråde) og savtand.
Mest sandsynligt er programmet begrænset af ydeevnen af diskundersystemet på datalagringsserveren, som det allerede var tilfældet med rsync. Lagerstørrelsen var 13 GB, ligesom zbackup eller borgbackup, var der ingen åbenlyse ulemper ved brug af denne løsning.
Fund
Faktisk opnåede alle kandidater lignende resultater, men til forskellige priser. Borgbackup klarede sig bedst af alt, restic var lidt langsommere, zbackup er nok ikke værd at begynde at bruge,
og hvis det allerede er i brug, så prøv at ændre det til borgbackup eller restic.
Fund
Den mest lovende løsning ser ud til at være restisk, fordi... det er ham, der har det bedste forhold mellem kapacitet og driftshastighed, men lad os ikke skynde os til generelle konklusioner for nu.
Borgbackup er som udgangspunkt ikke værre, men zbackup er nok bedre erstattet. Sandt nok kan zbackup stadig bruges til at sikre, at 3-2-1-reglen virker. For eksempel udover (lib)rsync-baserede backupfaciliteter.
annoncering
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