In dit artikel wordt ingegaan op back-upsoftware die, door de datastroom op te splitsen in afzonderlijke componenten (chunks), een opslagplaats vormt.
Repositorycomponenten kunnen verder worden gecomprimeerd en gecodeerd, en vooral – tijdens herhaalde back-upprocessen – hergebruikt.
Een reservekopie in zo'n repository is een benoemde keten van componenten die bijvoorbeeld met elkaar zijn verbonden op basis van verschillende hash-functies.
Er zijn verschillende vergelijkbare oplossingen, ik zal me concentreren op 3: zbackup, borgbackup en restic.
Verwachte resultaten
Aangezien alle aanvragers op de een of andere manier de oprichting van een repository nodig hebben, zal een van de belangrijkste factoren het inschatten van de omvang van de repository zijn. Idealiter zou de grootte ervan niet meer dan 13 GB moeten zijn volgens de geaccepteerde methodologie, of zelfs minder - onder voorbehoud van goede optimalisatie.
Het is ook zeer wenselijk om rechtstreeks back-upkopieën van bestanden te kunnen maken, zonder archiveringsprogramma's zoals tar te gebruiken, en om met ssh/sftp te kunnen werken zonder extra tools 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 minder.
- Er wordt een zware CPU-belasting verwacht bij het gebruik van compressie en/of encryptie, en een vrij hoge netwerk- en schijfbelasting is waarschijnlijk als het archiverings- en/of encryptieproces wordt uitgevoerd op een back-upopslagserver.
- Als de repository beschadigd is, is er waarschijnlijk sprake van een vertraagde fout bij het maken van nieuwe back-ups en bij het herstellen ervan. Het is noodzakelijk om aanvullende maatregelen te plannen om de integriteit van de repository te waarborgen of ingebouwde tools te gebruiken om de integriteit ervan te controleren.
Het werken met teer wordt als referentiewaarde genomen, zoals in één van de voorgaande artikelen is gebleken.
Zbackup testen
Het algemene mechanisme van zbackup is dat het programma in de invoergegevensstroom gebieden vindt die dezelfde gegevens bevatten, deze vervolgens optioneel comprimeert en versleutelt, waarbij elk gebied slechts één keer wordt opgeslagen.
Deduplicatie maakt gebruik van een 64-bit ring-hash-functie met een schuifvenster om te controleren op byte-voor-byte overeenkomsten met bestaande datablokken (vergelijkbaar met hoe rsync dit implementeert).
Multi-threaded lzma en lzo worden gebruikt voor compressie, en aes voor codering. De nieuwste versies hebben de mogelijkheid om in de toekomst oude gegevens uit de repository te verwijderen.
Het programma is geschreven in C++ met minimale afhankelijkheden. De auteur was blijkbaar geïnspireerd door de Unix-manier, dus accepteert het programma gegevens op stdin bij het maken van back-ups en produceert het een vergelijkbare gegevensstroom op stdout bij het herstellen. Zo kan zbackup gebruikt worden als een zeer goede “bouwsteen” bij het schrijven van uw eigen back-upoplossingen. De auteur van het artikel gebruikt dit programma bijvoorbeeld sinds ongeveer 2014 als belangrijkste back-uptool voor thuismachines.
De datastroom zal een normale tar zijn, tenzij anders vermeld.
Laten we eens kijken wat de resultaten zijn:
Het werk werd in 2 opties gecontroleerd:
- er wordt een repository gemaakt en zbackup wordt gelanceerd op de server met de brongegevens, waarna de inhoud van de repository wordt overgebracht naar de back-upopslagserver.
- er wordt een repository gemaakt op de back-upopslagserver, zbackup wordt via ssh op de back-upopslagserver gestart en er worden gegevens via pipe naartoe verzonden.
De resultaten van de eerste optie waren als volgt: 43m11s - bij gebruik van een niet-gecodeerde opslagplaats en de lzma-compressor, 19m13s - bij vervanging van de compressor door lzo.
De belasting op de server met de originele data was als volgt (een voorbeeld met lzma wordt getoond; met lzo was er ongeveer hetzelfde beeld, maar het aandeel van rsync was ongeveer een kwart van de tijd):
Het is duidelijk dat een dergelijk back-upproces alleen geschikt is voor relatief zeldzame en kleine wijzigingen. Het is ook zeer aan te raden om zbackup te beperken tot 1 thread, anders zal er een zeer hoge CPU-belasting zijn, omdat Het programma is erg goed in het werken in meerdere threads. De belasting op de schijf was klein, wat over het algemeen niet merkbaar zou zijn bij een modern, op SSD gebaseerd schijfsubsysteem. U kunt ook duidelijk het begin zien van het proces van het synchroniseren van repositorygegevens met een externe server; de werkingssnelheid is vergelijkbaar met gewone rsync en hangt af van de prestaties van het schijfsubsysteem van de back-upopslagserver. Het nadeel van deze aanpak is de opslag van een lokale repository en, als gevolg daarvan, duplicatie van gegevens.
Interessanter en in de praktijk toepasbaar is de tweede optie, waarbij zbackup rechtstreeks op de back-upopslagserver wordt uitgevoerd.
Eerst zullen we de werking testen zonder gebruik te maken van encryptie met de lzma-compressor:
Looptijd van elke testrun:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Als u encryptie inschakelt met behulp van aes, liggen de resultaten vrij dicht bij elkaar:
Bedrijfstijd op dezelfde gegevens, met encryptie:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Als encryptie wordt gecombineerd met compressie met behulp van lzo, ziet het er als volgt uit:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
De grootte van de resulterende repository was relatief hetzelfde: 13 GB. Dit betekent dat de deduplicatie correct werkt. Ook op reeds gecomprimeerde gegevens geeft het gebruik van lzo een merkbaar effect; in termen van totale gebruikstijd komt zbackup dicht bij dupliciteit/duplicati, maar blijft 2-5 keer achter bij die op basis van librsync.
De voordelen liggen voor de hand: het besparen van schijfruimte op de back-upopslagserver. Wat de hulpmiddelen voor het controleren van repository's betreft, biedt de auteur van zbackup deze niet; het wordt aanbevolen om een fouttolerante schijfarray of cloudprovider te gebruiken.
Al met al een zeer goede indruk, ondanks dat het project al zo'n 3 jaar stilstaat (de laatste feature request was ongeveer een jaar geleden, maar zonder reactie).
Borgbackup testen
Borgbackup is een zoldervork, een ander systeem vergelijkbaar met zbackup. Het is geschreven in Python en heeft een lijst met mogelijkheden die vergelijkbaar zijn met zbackup, maar kan bovendien:
- Back-ups monteren via zekering
- Controleer de inhoud van de opslagplaats
- Werk in client-servermodus
- Gebruik verschillende compressoren voor gegevens, evenals heuristische bepaling van het bestandstype bij het comprimeren ervan.
- 2 coderingsopties, aes en blake
- Ingebouwd hulpmiddel voor
prestatiecontroles
borgbackup benchmark ruwe ssh://backup_server/repo/path local_dir
De resultaten waren als volgt:
CZ-BIG 96.51 MB/s (10 100.00 MB geheel-nul-bestanden: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB geheel-nul-bestanden: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB geheel-nul-bestanden: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB geheel-nul-bestanden: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB willekeurige bestanden: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB willekeurige bestanden: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB willekeurige bestanden: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB willekeurige bestanden: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB geheel-nul-bestanden: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB geheel-nul-bestanden: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB geheel-nul-bestanden: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB geheel-nul-bestanden: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB willekeurige bestanden: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB willekeurige bestanden: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB willekeurige bestanden: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB willekeurige bestanden: 20.49 s)
CZ-KLEIN 11.72 MB/s (10000 10.00 kB alle-nul-bestanden: 8.53s)
RZ-KLEIN 32.57 MB/s (10000 10.00 kB alle-nul-bestanden: 3.07s)
UZ-KLEIN 19.37 MB/s (10000 10.00 kB alle-nul-bestanden: 5.16s)
DZ-KLEIN 33.71 MB/s (10000 10.00 kB alle-nul-bestanden: 2.97s)
CR-KLEIN 6.85 MB/s (10000 10.00 kB willekeurige bestanden: 14.60s)
RR-KLEIN 31.27 MB/s (10000 10.00 kB willekeurige bestanden: 3.20s)
UR-KLEIN 12.28 MB/s (10000 10.00 kB willekeurige bestanden: 8.14s)
DR-KLEIN 18.78 MB/s (10000 10.00 kB willekeurige bestanden: 5.32s)
Bij het testen wordt compressieheuristiek gebruikt om het bestandstype te bepalen (automatische compressie), en de resultaten zijn als volgt:
Laten we eerst eens kijken hoe het werkt zonder codering:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Als u repository-autorisatie (geverifieerde modus) inschakelt, zullen de resultaten vergelijkbaar zijn:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Toen AES-encryptie werd geactiveerd, verslechterden de resultaten niet veel:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
En als je aes in blake verandert, zal de situatie volledig verbeteren:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Net als in het geval van zbackup was de repositorygrootte 13 GB en zelfs iets minder, wat algemeen wordt verwacht. Ik was erg tevreden over de looptijd; deze is vergelijkbaar met oplossingen op basis van librsync en biedt veel bredere mogelijkheden. Ik was ook blij met de mogelijkheid om verschillende parameters in te stellen via omgevingsvariabelen, wat een zeer serieus voordeel oplevert bij het gebruik van borgbackup in de automatische modus. Ook over de belasting tijdens het backuppen was ik tevreden: afgaande op de processorbelasting werkt borgbackup in 1 thread.
Er waren geen bijzondere nadelen bij het gebruik ervan.
restisch testen
Ondanks dat restic een vrij nieuwe oplossing is (de eerste 2 kandidaten waren al in 2013 en ouder bekend), heeft het behoorlijk goede eigenschappen. Geschreven in Go.
In vergelijking met zbackup geeft het bovendien:
- Het controleren van de integriteit van de repository (inclusief het inchecken van onderdelen).
- Een enorme lijst met ondersteunde protocollen en providers voor het opslaan van back-ups, evenals ondersteuning voor rclone - rsync voor cloudoplossingen.
- Vergelijk 2 backups met elkaar.
- Montage van de opslagplaats via zekering.
Over het algemeen ligt de lijst met functies vrij dicht bij borgbackup, op sommige plaatsen meer, op andere minder. Een van de kenmerken is dat er geen manier is om de codering uit te schakelen, en daarom worden back-upkopieën altijd gecodeerd. Laten we in de praktijk kijken wat er uit deze software kan worden geperst:
De resultaten waren als volgt:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
De prestatieresultaten zijn ook vergelijkbaar met op rsync gebaseerde oplossingen en komen over het algemeen zeer dicht in de buurt van borgbackup, maar de CPU-belasting is hoger (meerdere threads actief) en zaagtand.
Hoogstwaarschijnlijk wordt het programma beperkt door de prestaties van het schijfsubsysteem op de gegevensopslagserver, zoals al het geval was met rsync. De repositorygrootte was 13 GB, net als bij zbackup of borgbackup waren er geen duidelijke nadelen bij het gebruik van deze oplossing.
Bevindingen
In feite behaalden alle kandidaten vergelijkbare resultaten, maar tegen verschillende prijzen. Borgbackup presteerde het beste van allemaal, restic was iets langzamer, zbackup is waarschijnlijk niet de moeite waard om te gebruiken,
en als het al in gebruik is, probeer het dan te veranderen naar borgbackup of restic.
Bevindingen
De meest veelbelovende oplossing lijkt terughoudend, omdat... Hij is degene die de beste verhouding tussen capaciteiten en werksnelheid heeft, maar laten we voorlopig niet overhaast algemene conclusies trekken.
Borgbackup is in principe niet slechter, maar zbackup is waarschijnlijk beter te vervangen. Het is waar dat zbackup nog steeds kan worden gebruikt om ervoor te zorgen dat de 3-2-1-regel werkt. Bijvoorbeeld naast (lib)rsync-gebaseerde back-upfaciliteiten.
aankondiging
Back-up Deel 5: Back-up van Bacula en Veam testen voor Linux
Back-up deel 6: back-uptools vergelijken
Back-up Deel 7: Conclusies
Gepost door: Pavel Demkovich
Bron: www.habr.com