In deze opmerking worden back-uptools besproken die back-ups uitvoeren door archieven op een back-upserver te maken.
Onder degenen die aan de vereisten voldoen, zijn duplicity (die een mooie interface heeft in de vorm van deja dup) en duplicati.
Een andere zeer opmerkelijke back-uptool is dar, maar omdat het een zeer uitgebreide lijst met opties heeft (de testmethodologie dekt amper 10% van wat het kan) testen we het niet als onderdeel van de huidige cyclus.
Verwachte resultaten
Omdat beide kandidaten op de een of andere manier archieven creëren, kan reguliere tar als leidraad worden gebruikt.
Daarnaast zullen we evalueren hoe goed de gegevensopslag op de opslagserver is geoptimaliseerd door back-upkopieën te maken die alleen het verschil bevatten tussen een volledige kopie en de huidige status van de bestanden, of tussen de vorige en huidige archieven (incrementeel, decrementeel, enz.) .
Gedrag bij het maken van back-ups:
- Een relatief klein aantal bestanden op de back-upopslagserver (vergelijkbaar met het aantal back-upkopieën of de gegevensgrootte in GB), maar hun omvang is vrij groot (tientallen tot honderden megabytes).
- De repositorygrootte zal alleen wijzigingen bevatten - er worden geen duplicaten opgeslagen, dus de repositorygrootte zal kleiner zijn dan bij op rsync gebaseerde software.
- Verwacht een zware CPU-belasting bij gebruik van compressie en/of encryptie, en waarschijnlijk een behoorlijk hoge netwerk- en schijfbelasting als het archiverings- en/of encryptieproces op een back-upopslagserver wordt uitgevoerd.
Laten we de volgende opdracht uitvoeren als referentiewaarde:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"De uitvoeringsresultaten waren als volgt:
Uitvoeringstijd 3m12s. Het is duidelijk dat de snelheid wordt beperkt door het schijfsubsysteem van de back-upopslagserver, zoals in het voorbeeld met . Alleen iets sneller, want... opname gaat naar één bestand.
Om de compressie te evalueren, gebruiken we dezelfde optie, maar schakelen we compressie in op de back-upserver:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"De resultaten zijn:
Uitvoeringstijd 10m11s. Hoogstwaarschijnlijk is het knelpunt de single-flow-compressor aan de ontvangende kant.
Hetzelfde commando, maar met compressie overgebracht naar de server met de originele gegevens om de hypothese te testen dat het knelpunt een single-threaded compressor is.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Het bleek zo:
De uitvoeringstijd bedroeg 9m37s. De belasting op één kern door de compressor is duidelijk zichtbaar, omdat De netwerkoverdrachtsnelheid en de belasting van het bronschijfsubsysteem zijn vergelijkbaar.
Om de codering te evalueren, kunt u openssl of gpg gebruiken door een extra opdracht aan te sluiten openssl of gpg in pijp. Ter referentie zal er een commando als dit 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 kwamen er als volgt uit:
De uitvoeringstijd bleek 10m30s te zijn, aangezien er aan de ontvangende kant twee processen draaiden - het knelpunt is opnieuw een compressor met één thread, plus een kleine encryptie-overhead.
UPD: Op verzoek van bliznezz voeg ik testen toe met pigz. Als je alleen de compressor gebruikt, duurt het 6m30s, als je ook encryptie toevoegt, zou het ongeveer 7m zijn. De dip in de onderste grafiek is een niet-geschoonde schijfcache:
Dubbele testen
Duplicity is Python-software voor back-up door gecodeerde archieven in tar-formaat te maken.
Voor incrementele archieven wordt librsync gebruikt, dus u kunt het gedrag verwachten dat wordt beschreven in .
Back-ups kunnen worden gecodeerd en ondertekend met gnupg, wat belangrijk is bij het gebruik van verschillende providers voor het opslaan van back-ups (s3, backblaze, gdrive, enz.)
Laten we eens kijken wat de resultaten zijn:
Dit zijn de resultaten die we kregen als we zonder codering werkten
spoiler
Looptijd van elke testrun:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
En hier zijn de resultaten wanneer gnupg-codering is ingeschakeld, met een sleutelgrootte van 2048 bits:
Bedrijfstijd op dezelfde gegevens, met encryptie:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
De blokgrootte werd aangegeven: 512 megabytes, wat duidelijk zichtbaar is in de grafieken; De processorbelasting bleef feitelijk op 50%, wat betekent dat het programma niet meer dan één processorkern gebruikt.
Het principe van de werking van het programma is ook heel duidelijk zichtbaar: ze namen een stukje gegevens, comprimeerden het en stuurden het naar een back-upopslagserver, wat behoorlijk traag kan zijn.
Een ander kenmerk is de voorspelbare looptijd van het programma, die alleen afhankelijk is van de grootte van de gewijzigde gegevens.
Het inschakelen van encryptie heeft de looptijd van het programma niet significant vergroot, maar het CPU-gebruik is wel met ongeveer 10% toegenomen, wat een behoorlijk goede bonus kan zijn.
Helaas kon dit programma de situatie met het hernoemen van de directory niet correct detecteren en de resulterende repositorygrootte bleek gelijk te zijn aan de grootte van de wijzigingen (d.w.z. allemaal 18 GB), maar de mogelijkheid om een niet-vertrouwde server te gebruiken voor back-up is duidelijk dekt dit gedrag.
Dubbele testen
Deze software is geschreven in C# en draait met behulp van een set bibliotheken van Mono. Er is zowel een GUI als een CLI-versie.
De geschatte lijst met de belangrijkste functies is vergelijkbaar met dubbelhartigheid, inclusief verschillende leveranciers van back-upopslag. In tegenstelling tot dubbelhartigheid zijn de meeste functies echter beschikbaar zonder tools van derden. Of dit een pluspunt of een minpunt is, hangt af van het specifieke geval, maar voor beginners is het hoogstwaarschijnlijk gemakkelijker om een lijst met alle functies tegelijk voor zich te hebben, in plaats van extra pakketten voor Python te moeten installeren, zoals het geval is met dubbelhartigheid.
Nog een kleine nuance: het programma schrijft actief een lokale sqlite-database namens de gebruiker die de back-up start, dus u moet er bovendien voor zorgen dat de vereiste database correct wordt opgegeven telkens wanneer het proces wordt gestart met behulp van de cli. Wanneer u via GUI of WEBGUI werkt, worden details voor de gebruiker verborgen.
Laten we eens kijken welke indicatoren deze oplossing kan opleveren:
Als u de codering uitschakelt (en WEBGUI raadt dit niet aan), zijn de resultaten als volgt:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Als encryptie is ingeschakeld en aes wordt gebruikt, ziet het er als volgt uit:
Openingstijden:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
En als je het externe programma gnupg gebruikt, komen de volgende resultaten naar voren:
Uitvoeren 1
Uitvoeren 2
Uitvoeren 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Zoals je kunt zien, kan het programma in verschillende threads werken, maar dit maakt het geen productievere oplossing, en als je het versleutelingswerk vergelijkt, lanceert het een extern programma
bleek sneller dan het gebruik van de bibliotheek uit de Mono-set. Dit kan te wijten zijn aan het feit dat het externe programma meer geoptimaliseerd is.
Een ander aardig ding was het feit dat de grootte van de repository precies evenveel in beslag neemt als de feitelijk gewijzigde gegevens, d.w.z. duplicati heeft een maphernoeming gedetecteerd en deze situatie correct afgehandeld. Dit is te zien bij het uitvoeren van de tweede test.
Over het geheel genomen redelijk positieve indrukken van het programma, inclusief het feit dat het redelijk vriendelijk is voor nieuwkomers.
Bevindingen
Beide kandidaten werkten nogal langzaam, maar over het algemeen is er, vergeleken met gewone teer, vooruitgang, tenminste met duplicati. De prijs voor dergelijke vooruitgang is ook duidelijk: een merkbare last
verwerker. Over het algemeen zijn er geen speciale afwijkingen bij het voorspellen van de resultaten.
Bevindingen
Als je nergens heen hoeft te haasten en ook nog een reserveprocessor hebt, zullen alle overwogen oplossingen voldoende zijn. Er is in ieder geval behoorlijk wat werk gedaan dat niet herhaald mag worden door wrapper-scripts bovenop tar te schrijven . De aanwezigheid van codering is een zeer noodzakelijke eigenschap als de server voor het opslaan van back-upkopieën niet volledig kan worden vertrouwd.
Vergeleken met oplossingen gebaseerd - de prestaties kunnen meerdere malen slechter zijn, ondanks het feit dat tar in zijn pure vorm 20-30% sneller werkte dan rsync.
Er zijn besparingen op de grootte van de repository, maar alleen met duplicati.
aankondiging
Back-up deel 3: dubbelhartigheid, duplicati, deja dup beoordelen en testen
Back-up deel 4: zbackup, restic, borgbackup bekijken en testen
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