In dit artikel worden softwaretools voor back-up besproken die door het splitsen van datastromen in afzonderlijke componenten (chunks) een repository vormen.
De componenten van de repository kunnen bovendien worden gecomprimeerd en versleuteld, en het belangrijkste is dat ze bij herhaalde back-upprocessen opnieuw kunnen worden gebruikt.
Een back-up in een dergelijke repository is een benoemde keten van met elkaar verbonden componenten, bijvoorbeeld op basis van verschillende hash-functies.
Er zijn verschillende oplossingen, ik zal me richten op drie: zbackup, borgbackup en restic.
Verwachte resultaten
Aangezien alle kandidaten op de een of andere manier vereisen dat er een repository wordt aangemaakt, is een van de belangrijkste factoren de beoordeling van de grootte van de repository. Idealiter zou de grootte niet meer dan 13 GB moeten zijn volgens de gehanteerde methode, en misschien zelfs minder ā mits goed geoptimaliseerd.
Het is ook uiterst wenselijk om de mogelijkheid te hebben om bestanden rechtstreeks te back-uppen, zonder gebruik te maken van archiveringshulpmiddelen zoals tar, evenals werken met ssh/sftp zonder extra middelen zoals rsync en sshfs.
Gedrag bij het maken van back-ups:
- De grootte van de repository zal gelijk zijn aan de grootte van de wijzigingen, of kleiner.
- Er wordt een hoge belasting van de CPU verwacht bij gebruik van compressie en/of versleuteling, en er kan ook een aanzienlijke belasting op het netwerk en de schijfsubsystemen zijn als het archiverings- en/of versleutelingsproces op de back-upserver draait.
- Als de repository beschadigd raakt, kan er een vertraagde fout optreden bij zowel het maken van nieuwe back-ups als bij pogingen tot herstel. Het is noodzakelijk om extra maatregelen te plannen voor het waarborgen van de integriteit van de repository of gebruik te maken van ingebouwde tools voor het controleren van de integriteit.
Als referentiewaarde is het werken met tar aangenomen, zoals aangetoond in een van de vorige artikelen.
Testen van zbackup
Het algemene werkmechanisme van zbackup is dat het programma gelijke gegevens in de inkomende datastroom vindt, vervolgens optioneel comprimeert en versleutelt, en elke gebied slechts Ć©Ć©n keer opslaat.
Voor deduplicatie wordt een 64-bits ringhashfunctie met een glijdend venster gebruikt om byte-per-byte te controleren op overeenkomsten met reeds bestaande datablocks (vergelijkbaar met wat in rsync is geĆÆmplementeerd).
Voor compressie worden lzma en lzo in multithreading gebruikt, en voor versleuteling - aes. In de laatste versies is het mogelijk om in de toekomst oude gegevens uit het repository te verwijderen.
Het programma is geschreven in C++ met minimale afhankelijkheden. De auteur lijkt geĆÆnspireerd te zijn door de unix-way, daarom accepteert het programma gegevens van stdin bij het maken van back-ups, en geeft een vergelijkbare gegevensstroom naar stdout bij het herstellen. Op deze manier kan zbackup worden gebruikt als een behoorlijk goede 'stenen' bij het schrijven van eigen back-upoplossingen. Bijvoorbeeld, voor de auteur van dit artikel is dit programma al sinds 2014 het belangrijkste middel voor back-up van thuiscomputers.
Als gegevensstroom wordt gewoonlijk tar gebruikt, tenzij anders aangegeven.
Laten we kijken wat de resultaten zullen zijn:
De werking is getest in 2 varianten:
- er wordt een repository aangemaakt en zbackup wordt uitgevoerd op de server met de oorspronkelijke gegevens, vervolgens wordt de inhoud van de repository overgedragen naar de back-upserver.
- er wordt een repository aangemaakt op de back-upserver, zbackup wordt via ssh op de back-upserver uitgevoerd, waarbij gegevens via een pipe worden aangeleverd.
De resultaten van de eerste variant waren als volgt: 43m11s - bij het gebruik van een niet-geƫncrypteerd repository en lzma-compressor, 19m13s - bij vervanging van de compressor door lzo.
De belasting op de server met de originele gegevens was als volgt (hier een voorbeeld met lzma, met lzo was het ongeveer hetzelfde, maar het aandeel van rsync was ongeveer een kwart van de tijd):
Het is duidelijk dat dit soort back-up processen slechts geschikt is bij relatief zeldzame en kleine wijzigingen. Het is ook uiterst wenselijk om de werking van zbackup te beperken tot 1 thread, anders zal de CPU belast zijn, omdat het programma zeer goed kan werken met meerdere threads. De belasting op de schijf was gering, wat over het algemeen met moderne schijfsystemen op basis van ssd niet merkbaar zal zijn. Het is ook duidelijk te zien dat het proces van gegevenssynchronisatie van de repository naar de externe server is gestart, en de snelheid van werken is vergelijkbaar met gewone rsync en is afhankelijk van de prestaties van het schijfsysteem van de back-upserver. Een nadeel van deze aanpak is het opslaan van een lokale repository en, als gevolg daarvan, de duplicatie van gegevens.
De tweede optie, waarbij zbackup direct op de opslagserver voor back-ups wordt gestart, is interessanter en praktischer toepasbaar.
We beginnen met het testen zonder versleuteling met de lzma-compressor:
De uitvoeringstijd van elke testuitvoering:
Uitvoering 1
Uitvoering 2
Uitvoering 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Wanneer we versleuteling met aes inschakelen, zijn de resultaten behoorlijk vergelijkbaar:
De uitvoeringstijd op dezelfde gegevens, met encryptie:
Uitvoering 1
Uitvoering 2
Uitvoering 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Wanneer we versleuteling combineren met compressie met lzo, zien we het volgende:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
De grootte van de resulterende repository was grotendeels constant op 13GB. Dit betekent dat deduplicatie correct werkt. Ook geeft het toepassen van lzo op reeds gecomprimeerde gegevens een merkbaar effect, en de totale tijd die zbackup verbruikt, nadert die van duplicity/duplicati, maar blijft 2-5 keer achter bij oplossingen die gebaseerd zijn op librsync.
De voordelen zijn duidelijk ā besparing van schijfruimte op de opslagserver voor back-ups. Wat betreft de middelen voor het controleren van de repository ā deze zijn niet voorzien door de auteur van zbackup, dus het wordt aanbevolen gebruik te maken van een redundant schijfsysteem of cloudprovider.
Algemeen genomen een heel goede indruk, hoewel het project inmiddels ongeveer 3 jaar stil staat (de laatste feature request was ongeveer een jaar geleden, maar zonder reactie).
Testen van borgbackup
Borgbackup is een fork van attic, een ander systeem dat lijkt op zbackup. Het is geschreven in Python en heeft een vergelijkbare set functies als zbackup, maar kan bovendien:
- Back-ups via fuse aankoppelen
- Inhoud van de repository controleren
- Werken in client-server modus
- Verschillende compressoren voor gegevens gebruiken en ook heuristisch het bestandstype bepalen bij compressie.
- 2 versleutelingsopties, aes en blake
- Ingebouwd hulpmiddel voor
prestatiecontrole
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
De resultaten waren als volgt:
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)
Bij de tests zal heuristiek worden gebruikt bij compressie met bestandstypebepaling (compressie automatisch), en de resultaten zullen als volgt zijn:
Laten we beginnen met de werking zonder encryptie:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Als we repository-authenticatie inschakelen (geauthenticeerde modus), zullen de resultaten vergelijkbaar zijn:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Bij het activeren van aes-encryptie zijn de resultaten niet veel verslechterd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Maar als we aes vervangen door blake, verbetert de situatie helemaal:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Net als bij zbackup was de grootte van het repository 13 GB en zelfs iets minder, wat in het algemeen verwacht werd. We waren zeer tevreden over de looptijd, deze is vergelijkbaar met oplossingen op basis van librsync en biedt veel bredere mogelijkheden. We waren ook tevreden met de mogelijkheid om verschillende parameters via omgevingsvariabelen in te stellen, wat aanzienlijke voordelen biedt bij het gebruik van borgbackup in automatische modus. Ook de belasting bij het maken van back-ups was positief: gezien de CPU-belasting werkt borgbackup in 1 thread.
Er zijn geen significante nadelen geconstateerd bij het gebruik.
Test van restic
Ondanks dat restic een relatief nieuwe oplossing is (de eerste 2 kandidaten waren al bekend sinds 2013 of ouder), heeft het vrij goede kenmerken. Het is geschreven in Go.
In vergelijking met zbackup biedt het daarnaast:
- Integriteitscontrole van het repository (inclusief controle per stuk).
- Een enorme lijst van ondersteunde protocollen en providers voor het opslaan van back-ups, evenals ondersteuning voor rclone ā rsync voor 'cloud'-oplossingen.
- Vergelijking van 2 back-ups met elkaar.
- Repository montage via fuse.
Over het algemeen is de lijst van mogelijkheden vrij vergelijkbaar met borgbackup, soms meer, soms minder. Van de bijzonderheden is er geen mogelijkheid om encryptie uit te schakelen, wat betekent dat back-ups altijd geƫncrypteerd zullen zijn. Laten we in de praktijk bekijken wat we uit deze software kunnen halen:
De resultaten zijn als volgt:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
De resultaten zijn vergelijkbaar met oplossingen op basis van rsync en over het algemeen vrij dicht bij borgbackup, maar de CPU-belasting is hoger (werkt met meerdere threads) en heeft een zaagtandpatroon.
Het is zeer waarschijnlijk dat het programma tegen de prestaties van de schijfsubsystemen op de gegevensopslagserver aanloopt, zoals al het geval was met rsync. De grootte van het repository is 13 GB, net als bij zbackup of borgbackup, er zijn geen duidelijke nadelen vastgesteld bij het gebruik van deze oplossing.
Resultaten
In feite hebben alle kandidaten vergelijkbare uitslagen behaald, maar met verschillende prijzen. Borgbackup presteerde het beste, gevolgd door restic, zbackup lijkt waarschijnlijk niet de moeite waard om mee te beginnen,
en als het al in gebruik is ā probeer over te stappen naar borgbackup of restic.
Conclusies
Het meest veelbelovende lijkt restic, omdat het de beste verhouding tussen mogelijkheden en snelheid biedt, maar laten we ons nog niet haasten met definitieve conclusies.
Borgbackup is in principe niet slechter, maar zbackup kan waarschijnlijk beter worden vervangen. Echter, voor het waarborgen van de toepassing van de 3-2-1 regel kan zbackup nog steeds worden ingezet. Bijvoorbeeld, als aanvulling op (lib)rsync-gebaseerde back-up oplossingen.
Aankondiging
Back-up, deel 5: Testen van bacula en veeam backup voor linux
Back-up, deel 6: Vergelijking van back-upoplossingen
Back-up, deel 7: Conclusies
Auteur van de publicatie: Pavel Demkovich
Bron: habr.com
