I denne artikel vil vi se på softwareværktøjer til sikkerhedskopiering, der ved at opdele datastreamen i separate komponenter (chunks) danner et repository.
Repository-komponenter kan yderligere komprimeres og krypteres, og vigtigst af alt – ved gentagne sikkerhedskopieringsprocesser – genbruges.
En sikkerhedskopi i et sådant repository er en navngivet kæde af relaterede komponenter, f.eks. baseret på forskellige hash-funktioner.
Der er flere sådanne løsninger, jeg vil fokusere på 3: zbackup, borgbackup og restic.
Forventede resultater
Da alle kandidater på en eller anden måde kræver oprettelse af et repository, vil en af de vigtigste faktorer være vurderingen af repositoryets størrelse. Ideelt set bør dets størrelse ikke overstige 13 GB ifølge den anerkendte metode, og gerne mindre – under forudsætning af god optimering.
Det er også yderst ønskeligt at have mulighed for at lave sikkerhedskopier af filer direkte, uden at anvende arkiveringsprogrammer som tar, samt at arbejde med ssh/sftp uden yderligere værktøjer som rsync og sshfs.
Adfærd ved sikkerhedskopiering:
- Repositoryets størrelse vil være lig med størrelsen af ændringerne, eller mindre.
- Der forventes en stor belastning på CPU'en ved brug af komprimering og/eller kryptering, og der kan også være en betydelig belastning på netværket og diskSubsystemet, hvis arkiverings- og/eller krypteringsprocessen kører på serveren til sikkerhedskopiering.
- Hvis repositoryet bliver beskadiget – er der risiko for forsinkede fejl både ved oprettelse af nye sikkerhedskopier og ved forsøg på at gendanne. Man skal planlægge ekstra foranstaltninger for at sikre repositoryets integritet eller bruge indbyggede værktøjer til at kontrollere dets integritet.
Som referenceværdien er der arbejdet med tar, som vist i en af de tidligere artikler.
Test af zbackup
Den overordnede funktion af zbackup er, at programmet finder områder i datastreamen, der sendes ind, som indeholder de samme data, og derefter komprimerer og krypterer dem valgfrit, idet hver område kun gemmes én gang.
Til deduplikation anvendes en 64-bit ringhash-funktion med et glidende vindue til byte-for-byte kontrol af match med allerede eksisterende datablokke (svarende til hvad der er implementeret i rsync).
Til kompression anvendes lzma og lzo i en multitrådet udførelse, mens kryptering benytter aes. I de seneste versioner er der mulighed for i fremtiden at slette gamle data fra depotet.
Programmet er skrevet i C++ med minimale afhængigheder. Forfatteren har tilsyneladende ladet sig inspirere af unix-way, derfor tager programmet data fra stdin ved oprettelse af sikkerhedskopier og returnerer et tilsvarende datastream til stdout ved gendannelse. Dermed kan zbackup bruges som en ret god "klods" ved skrivning af egne sikkerhedskopiløsninger. For eksempel har forfatteren af artiklen brugt dette program som primært værktøj til sikkerhedskopiering af hjemmecomputere siden omkring 2014.
Som datastream anvendes almindelig tar, medmindre andet er angivet.
Lad os se, hvad resultaterne bliver:
Testen blev udført i 2 varianter:
- et depot oprettes, og zbackup køres på serveren med de originale data, hvorefter indholdet af depotet overføres til backup-lagringsserveren.
- et depot oprettes på backup-lagringsserveren, zbackup køres via ssh på backup-lagringsserveren, hvor data gives til det gennem en pipe.
Resultaterne af den første variant var som følger: 43m11s — ved brug af et ukrypteret depot og kompressoren lzma, 19m13s — ved at erstatte kompressoren med lzo.
Belastningen på serveren med de originale data var som følger (her vises et eksempel med lzma, med lzo var billedet omtrent det samme, men andelen af rsync var cirka en fjerdedel af tiden):
Det er klart, at en sådan backup-proces kun er velegnet til relativt sjældne og små ændringer. Det er også meget ønskeligt at begrænse zbackup's arbejde til 1 tråd, ellers vil CPU-belastningen være meget høj, da programmet er meget godt til at arbejde med flere tråde. Belastningen på disken var lille, hvilket generelt vil være usynligt med moderne diskunderstøttelse baseret på SSD. Det er også tydeligt at se lanceringen af synchroniseringsprocessen af datalageret til den fjernserver, og hastigheden ligner den almindelige rsync og er begrænset af ydeevnen af diskunderstøttelsen i backup-serveren. Ulempen ved denne tilgang er, at den lokale repository skal opbevares, og som følge heraf — datadublisering.
Den mere interessante og praktisk anvendelige mulighed er den anden variant med at starte zbackup direkte på backup-serveren.
For at starte vil der blive tjekket arbejde uden brug af kryptering med lzma-komprimering:
Tid for hver teststart:
Start 1
Start 2
Start 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Hvis man aktiverer kryptering ved hjælp af aes, er resultaterne ret tæt på:
Tid for arbejde med de samme data, med kryptering:
Start 1
Start 2
Start 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Hvis kryptering kombineres med komprimering ved hjælp af lzo, bliver det sådan:
Tid for arbejde:
Start 1
Start 2
Start 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Størrelsen på det resulterende repository var relativt ens og udgjorde 13 GB. Dette betyder, at deduplikeringsprocessen fungerer korrekt. Desuden giver anvendelsen af lzo på allerede komprimerede data en betydelig effekt; den samlede arbejdstid for zbackup er nærmere duplicity/duplicati, men er 2-5 gange langsommere end dem baseret på librsync.
Fordelene er åbenlyse — besparelse af diskplads på backup-serveren. Hvad angår værktøjerne til at kontrollere repository — disse er ikke forudset af zbackup-forfatterne; det anbefales at bruge et fejltolerant diskarray eller en cloud-udbyder.
Generelt et ret godt indtryk, på trods af at projektet har stået stille i cirka 3 år (den seneste feature request var for omkring et år siden, men uden svar).
Testning af borgbackup
Borgbackup er en fork af attic, endnu et system, der ligner zbackup. Det er skrevet i Python og har en lignende funktionsliste som zbackup, men kan desuden:
- Monter sikkerhedskopier via fuse
- Kontroller indholdet af repositoryet
- Arbejd i klient-server-tilstand
- Brug forskellige data-kompressorer samt heuristisk bestemmelse af filtypen under kompression.
- 2 krypteringsmetoder, aes og blake
- Indbygget værktøj til
ydelsestest
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Resultaterne var som følger:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB random files: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB random files: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB all-zero files: 8.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB all-zero files: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB all-zero files: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB all-zero files: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB random files: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB random files: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB random files: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB random files: 5.32s)
Ved testningen vil heuristik blive anvendt ved kompression med filtypebestemmelse (compression auto), og resultaterne vil være som følger:
For at begynde med vil vi kontrollere arbejdet uden kryptering:
Tid for arbejde:
Start 1
Start 2
Start 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Hvis repositoryautorisering (authenticated mode) aktiveres, vil resultaterne være tættere:
Tid for arbejde:
Start 1
Start 2
Start 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Når aes-kryptering aktiveres, ændres resultaterne ikke drastisk:
Start 1
Start 2
Start 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Og hvis vi ændrer aes til blake, forbedres situationen betydeligt:
Tid for arbejde:
Start 1
Start 2
Start 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Som med zbackup var størrelsen på repositoryet 13 GB eller lidt mindre, hvilket var forventeligt. Tiden var imponerende og sammenlignelig med løsninger baseret på librsync og giver meget bredere muligheder. Desuden var det glædeligt at kunne angive forskellige parametre gennem miljøvariabler, hvilket giver en betydelig fordel ved automatisk brug af borgbackup. Også belastningen ved sikkerhedskopiering var tilfredsstillende: ifølge CPU-belastningen kører borgbackup i én tråd.
Der blev ikke opdaget nogen væsentlige ulemper ved brugen.
Testning af restic
Selv om restic er en relativt ny løsning (de første 2 kandidater har været kendt siden 2013 og tidligere), har den ret gode egenskaber. Den er skrevet i Go.
Sammenlignet med zbackup giver den desuden:
- Kontrol af integriteten af lageret (herunder kontrol stykke for stykke).
- En kæmpe liste over understøttede protokoller og udbydere til opbevaring af sikkerhedskopier samt support for rclone – rsync til "cloud" løsninger.
- Sammenligning af 2 sikkerhedskopier med hinanden.
- Montering af lageret via fuse.
Generelt er listen over funktioner ret tæt på borgbackup, nogle steder mere, andre steder mindre. En bemærkelsesværdig funktion er, at muligheden for at deaktivere kryptering ikke findes, hvilket betyder, at sikkerhedskopier altid vil være krypterede. Lad os se, hvad vi kan få ud af denne software i praksis:
Resultaterne var som følger:
Tid for arbejde:
Start 1
Start 2
Start 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Resultaterne er også sammenlignelige med løsninger baseret på rsync og er generelt meget tætte på borgbackup, men CPU-belastningen er højere (flere tråde arbejder) og svingende.
Det er sandsynligt, at programmet lider under diskens ydeevne på lagerserveren, ligesom det allerede er set med rsync. Størrelsen på lageret var 13 GB, ligesom hos zbackup eller borgbackup, og der blev ikke fundet nogen åbenlyse ulemper ved at bruge denne løsning.
Resultater
I realiteten viste alle kandidater sig at have lignende målinger, men med forskellige priser. Borgbackup klarede sig bedst, lidt langsommere var restic, zbackup er sandsynligvis ikke værd at begynde at bruge,
og hvis det allerede er i brug – prøv at skifte til borgbackup eller restic.
Konklusioner
Den mest lovende løsning ser ud til at være restic, da den har det bedste forhold mellem muligheder og hastighed, men lad os vente med at drage endelige konklusioner.
Borgbackup er ikke ringere, men zbackup bør sandsynligvis erstattes. Dog kan zbackup stadig bruges til at sikre, at reglerne for 3-2-1 fungerer. For eksempel som en supplement til backup-løsninger baseret på (lib)rsync.
Annonce
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
