In deze notitie worden de back-up middelen besproken die back-ups maken door archieven te creƫren op een reserve-server.
Van de middelen die aan de vereisten voldoen, zijn duplicity (dat een fijne interface heeft in de vorm van deja dup) en duplicati.
Een ander opmerkelijk back-up middel is dar, maar aangezien het een zeer uitgebreide lijst opties heeft, zal de testmethode nauwelijks 10% van zijn mogelijkheden dekken - we testen het niet in deze cyclus.
Verwachte resultaten
Aangezien beide kandidaten op de een of andere manier archieven creƫren, kan de gebruikelijke tar als referentie dienen.
Bovendien zullen we evalueren hoe goed de opslag van gegevens op de opslagserver wordt geoptimaliseerd door de back-ups te maken die alleen de verschillen bevatten tussen een volledige kopie en de huidige staat van bestanden, of tussen de vorige en huidige archieven (incrementieel, decrementieel, enz.).
Gedrag bij het maken van back-ups:
- Relatief klein aantal bestanden op de opslagserver voor back-ups (vergeleken met het aantal back-ups of de grootte van gegevens in GB), maar met een aanzienlijk grote bestandsgrootte (tientallen tot honderden megabytes).
- De grootte van de repository zal alleen de wijzigingen omvatten - duplicaten worden niet opgeslagen, waardoor de grootte van de repository kleiner zal zijn dan bij software op basis van rsync.
- Er zal een zware belasting op de CPU worden verwacht bij het gebruik van compressie en/of encryptie, en ook waarschijnlijk een aanzienlijke belasting op het netwerk en de schijf subsystemen, als het archiverings- en/of encryptieproces op de opslagserver voor back-ups draait.
Als referentiewaarde zullen we de volgende opdracht uitvoeren:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"De resultaten van de uitvoering zijn als volgt:
De uitvoeringstijd was 3m12s. Het is duidelijk dat de snelheid werd beperkt door het schijfsysteem van de opslagserver voor back-ups, net als in het voorbeeld met . Alleen iets sneller, omdat de opname in Ć©Ć©n bestand plaatsvindt.
Ook om de compressie te evalueren, voeren we dezelfde variant uit, maar met compressie aan de kant van de back-upserver ingeschakeld:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"De resultaten zijn als volgt:
De uitvoeringstijd was 10m11s. Waarschijnlijk is de beperkende factor de enkelvoudige compressie aan de ontvangende kant.
Dezelfde opdracht, maar met compressie naar de server met de originele gegevens om de hypothese te testen dat de bottleneck de eencellige compressor is.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Het resultaat was als volgt:
De uitvoeringstijd was 9m37s. Het is duidelijk de belasting van Ć©Ć©n kern door de compressor, aangezien de netwerksnelheid en de belasting van het schijfsubsystem van de bron vergelijkbaar zijn.
Voor encryptie kan openssl of gpg gebruikt worden, mits een extra commando wordt toegevoegd openssl of gpg in de pipe. Ter referentie zou de volgende opdracht zijn:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"De resultaten waren als volgt:
De uitvoeringstijd was 10m30s, omdat er 2 processen aan de ontvangende kant werden gestart ā de bottleneck was weer de eenpijpscompressor, plus kleine overheadkosten voor encryptie.
UPD: Op verzoek van bliznezz voeg ik tests met pigz toe. Bij gebruik van alleen de compressor was het 6m30s, als encryptie wordt toegevoegd, is het ongeveer 7m. De daling in het onderste diagram is de niet-vrije schijfcache:
Testen van duplicity
Duplicity is software geschreven in python voor back-up door het maken van versleutelde archieven in tar-formaat.
Voor incrementele archieven wordt librsync gebruikt, dus we kunnen het gedrag verwachten dat in .
Back-ups kunnen worden versleuteld en ondertekend met behulp van gnupg, wat belangrijk is bij het gebruik van verschillende providers voor back-upopslag (s3, backblaze, gdrive, enz.)
Laten we kijken wat de resultaten zullen zijn:
Dit zijn de resultaten van de uitvoering zonder encryptie
spoiler
De uitvoeringstijd van elke testuitvoering:
Uitvoering 1
Uitvoering 2
Uitvoering 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
En hier zijn de resultaten bij het inschakelen van gnupg-encryptie, met een sleutellengte van 2048 bits:
De uitvoeringstijd op dezelfde gegevens, met encryptie:
Uitvoering 1
Uitvoering 2
Uitvoering 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Een blokgrootte van 512 megabyte werd opgegeven, wat duidelijk zichtbaar is in de grafieken; de CPU-belasting was eigenlijk rond de 50%, wat betekent dat het programma niet meer dan Ć©Ć©n processor kern benut.
Het is ook goed te zien hoe het programma functioneert: een stuk data werd genomen, gecomprimeerd en naar de back-upserver gestuurd, die vrij traag kan zijn.
Een andere functie is de voorspelbare looptijd van het programma, die alleen afhangt van de grootte van de gewijzigde gegevens.
Het inschakelen van encryptie heeft de looptijd van het programma niet significant verhoogd, maar de CPU-belasting steeg met ongeveer 10%, wat een behoorlijke bonus kan zijn.
Helaas kon dit programma de situatie met de hernoeming van de map niet correct detecteren, waardoor de resulterende grootte van de repository gelijk bleek te zijn aan de grootte van de wijzigingen (d.w.z. in totaal 18 GB), maar de mogelijkheid om een onbetrouwbare server voor back-ups te gebruiken, overtreft ongetwijfeld dit gedrag.
Testen met duplicati
Deze software is geschreven in C#, wordt uitgevoerd met behulp van een set bibliotheken van Mono. Er is zowel een GUI als een cli-versie beschikbaar.
Een aantal van de belangrijkste functies is vergelijkbaar met duplicity, inclusief verschillende providers voor het opslaan van back-ups, maar in tegenstelling tot duplicity is de meeste functionaliteit beschikbaar zonder extra hulpmiddelen. Of dit een voordeel of een nadeel is, hangt af van de specifieke situatie, maar voor beginners is het waarschijnlijker makkelijker om meteen een lijst met alle mogelijkheden voor ogen te hebben, in plaats van extra pakketten voor Python te installeren, zoals bij duplicity het geval is.
Een ander klein detail is dat het programma actief een lokale sqlite-database schrijft onder de naam van de gebruiker die de back-up uitvoert, dus het is noodzakelijk om extra op de juiste database te letten bij elke uitvoering van het proces met behulp van cli. Bij gebruik van de GUI of WEBGUI blijven de details verborgen voor de gebruiker.
Laten we kijken naar welke resultaten deze oplossing kan opleveren:
Als we encryptie uitschakelen (waarbij WEBGUI dit niet aanbeveelt), zijn de resultaten als volgt:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Met ingeschakelde encryptie, gebruikmakend van aes, zijn de resultaten als volgt:
Looptijd:
Uitvoering 1
Uitvoering 2
Uitvoering 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
En als we een extern programma zoals gnupg gebruiken, zijn de resultaten:
Uitvoering 1
Uitvoering 2
Uitvoering 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Zoals te zien is, kan het programma in meerdere threads werken, maar dit maakt het niet een productievere oplossing. En als we de werking van de encryptie vergelijken, was het starten van een extern programma
sneller dan het gebruik van de bibliotheek uit de Mono-set. Dit kan te maken hebben met het feit dat het externe programma beter geoptimaliseerd is.
Een aangenaam aspect was ook dat de grootte van het archief exact overeenkomt met de feitelijk gewijzigde gegevens, dat wil zeggen, duplicati ontdekte de hernoeming van de map en verwerkte deze situatie correct. Dit is te zien bij de uitvoering van de tweede test.
Al met al zijn de indrukken van het programma overwegend positief, inclusief de voldoende vriendelijkheid voor beginners.
Resultaten
Beide kandidaten werkten vrij langzaam, maar vergeleken met de gebruikelijke tar is er vooruitgang, tenminste bij duplicati. De prijs van deze vooruitgang is ook begrijpelijk ā merkbare belasting
van de processor. Over het algemeen zijn er geen bijzondere afwijkingen bij het voorspellen van de resultaten.
Conclusies
Als er geen haast is en er ook voldoende processorcapaciteit beschikbaar is, is elke van de besproken oplossingen geschikt; in elk geval is er voldoende werk verricht dat niet opnieuw moet worden gedaan door scripts bovenop tar te schrijven. Het hebben van encryptie is een zeer nuttige eigenschap als de server voor het opslaan van back-ups niet volledig te vertrouwen is.
Als we de oplossingen vergelijken die gebaseerd zijn op kan de prestaties enkele keren slechter zijn, hoewel tar in pure vorm 20-30% sneller werkte dan rsync.
Er zijn besparingen op de grootte van het archief, maar alleen bij duplicati.
Aankondiging
Back-up, deel 3: Overzicht en testen van duplicity, duplicati, deja dup
Back-up, deel 4: Overzicht en testen van zbackup, restic, borgbackup
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
