In dit artikel wordt een vergelijking gemaakt van back-up oplossingen, maar het is eerst belangrijk om te begrijpen hoe snel en effectief ze gegevens kunnen herstellen vanuit back-ups.
Voor de eenvoud van de vergelijking wordt het herstel uit een volledige back-up behandeld, vooral omdat deze werkwijze door alle kandidaten wordt ondersteund. Voor de eenvoud zijn de cijfers al gemiddeld (gemiddelde van verschillende uitvoeringen). De resultaten worden samengevat in een tabel, waarin ook informatie zal staan over mogelijkheden: aanwezigheid van een webinterface, eenvoud in configuratie en gebruik, automatiseringsmogelijkheden, aanwezigheid van diverse extra functies (bijvoorbeeld dataintegriteitscontrole) enzovoort. Grafieken zullen de belasting van de server tonen, waar de gegevens zullen worden toegepast (niet de servers voor het opslaan van back-ups).
Gegevensherstel
Als referentiepunt worden rsync en tar gebruikt, omdat de eenvoudigste back-up scripts.
Rsync heeft de testset gegevens binnen 4 minuten en 28 seconden verwerkt, met
deze belasting.
Het herstelproces liep tegen de beperkingen van het schijf subsysteem van de back-up server (zaagtandgrafieken). Ook is de belasting van één kern duidelijk zichtbaar zonder noemenswaardige problemen (lage iowait en softirq — geen problemen met de schijf en het netwerk respectievelijk). Aangezien de twee andere programma's, namelijk rdiff-backup en rsnapshot, gebaseerd zijn op rsync en bovendien rsync als herstel middel aanbieden, zullen ze een vergelijkbaar belastingprofiel en hersteltijd hebben.
Tar was iets sneller, in
2 minuten en 43 seconden:
De totale systeembelasting was gemiddeld 20% hoger door de toegenomen softirq — de overhead was stijgend bij de werking van het netwerk subsysteem.
Als het archief bovendien wordt gecomprimeerd, dan stijgt de hersteltijd naar 3 minuten en 19 seconden met
deze belasting op de hoofd server (uitpakken aan de kant van de hoofd server):
Het uitpakproces verbruikt beide CPU-kernen, omdat er twee processen draaien. Over het geheel genomen is dit het verwachte resultaat. Een vergelijkbaar resultaat (3 minuten en 20 seconden) werd behaald bij het uitvoeren van gzip op de serverzijde met back-ups, de belasting op de hoofdserver was vrij vergelijkbaar met de uitvoering van tar zonder de compressie van gzip (zie de vorige grafiek).
In rdiff-backup Je kunt de laatste gemaakte back-up synchroniseren met behulp van gewone rsync (de resultaten zullen vergelijkbaar zijn), maar oudere back-ups moeten nog steeds worden hersteld met behulp van het programma rdiff-backup, dat de hersteloperatie voltooide in 17 minuten en 17 seconden, wat liet zien
de volgende belasting:
Het kan zijn dat dit zo bedoeld was; in elk geval voor de snelheidsbeperking stellen de auteurs Het herstelproces van de back-up neemt iets minder dan de helft van een kern in beslag, met een proportioneel vergelijkbare prestatie (d.w.z. 2-5 keer trager) voor schijf en netwerk met rsync.
Rsnapshot stelt voor om gewone rsync te gebruiken voor het herstel, dus de resultaten zullen vergelijkbaar zijn. Over het geheel genomen bleek dat ook zo te zijn.
Burp voltooid de hersteltaak in 7 minuten en 2 seconden met
de volgende belasting:
Het ging vrij snel en, tenminste, het is veel handiger dan pure rsync: je hoeft je geen vlaggen te herinneren, een eenvoudige en intuïtieve cli-interface, ingebouwde ondersteuning voor meerdere kopieën — hoewel het wel twee keer zo traag is. Als je gegevens moet herstellen uit de laatst gemaakte back-up, kun je gebruik maken van rsync, met enkele kleine aanpassingen.
Ongeveer dezelfde snelheid en belasting werd getoond door het programma BackupPC bij het inschakelen van de rsync-transmissiemodus, waarbij de back-up werd hersteld in
7 minuten en 42 seconden:
Maar in de tar-transmissiemodus was BackupPC trager: in 12 minuten en 15 seconden, met een lagere CPU-belasting over het algemeen
van anderhalf keer:
Dupliciteit zonder encryptie liet het iets betere resultaten zien, met een herstel van de back-up in 10 minuten en 58 seconden. Het inschakelen van encryptie met gpg verlengt de hersteltijd tot 15 minuten en 3 seconden. Bij het maken van een repository voor het opslaan van back-ups kan ook de grootte van het archief worden opgegeven dat zal worden gebruikt bij het splitsen van de stroom van binnenkomende gegevens. Over het algemeen is er op gewone harde schijven, gezien de enkelvoudige werkmodus, niet veel verschil. Dit kan mogelijk blijken bij verschillende blokgroottes wanneer hybride opslag wordt gebruikt. De belasting op de hoofdserver tijdens het herstel was als volgt:
zonder encryptie
met encryptie
Duplicati toonde een vergelijkbare herstelsnelheid, met een tijd van 13 minuten en 45 seconden. Nog eens ongeveer 5 minuten was nodig voor de controle van de correctheid van de herstelde gegevens (totaal ongeveer 19 minuten). De belasting was hierbij
redelijk hoog:
Toen aes-encryptie met interne middelen werd ingeschakeld, bedroeg de hersteltijd 21 minuten en 40 seconden, terwijl de CPU-belasting maximaal was (beide kernen!) tijdens het herstel; bij de gegevenscontrole was slechts één thread actief, die één CPU-kern bezette. De controle van de gegevens na het herstel kostte dezelfde 5 minuten (totaal bijna 27 minuten).
Resultaat
Duplicati was iets sneller met het herstel wanneer een extern programma gpg voor encryptie werd gebruikt, maar over het algemeen zijn de verschillen met de vorige modus minimaal. De werktijd bedroeg 16 minuten en 30 seconden, met een gegevenscontrole van 6 minuten. De belasting was
als volgt:
AMANDA, gebruikmakend van tar, voltooide het in 2 minuten en 49 seconden, wat in principe vrij dicht bij de gebruikelijke tar ligt. De systeembelasting was in principe
dezelfde:
Bij het herstellen van een back-up met behulp van zbackup werden de volgende resultaten verkregen:
encryptie, compressie lzma
Totale werktijd 11 minuten en 8 seconden
encryptie aes, compressie lzma
Totale werktijd 14 minuten
encryptie aes, compressie lzo
Totale werktijd 6 minuten en 19 seconden
Over het algemeen niet slecht. Alles hangt af van de snelheid van de processor op de back-up server, wat duidelijk zichtbaar is aan de hand van de uitvoeringstijd van het programma met verschillende compressoren. Aan de kant van de back-up server werd de gebruikelijke tar gebruikt, dus als je dat vergelijkt — werkt het herstel drie keer langzamer. Misschien is het de moeite waard om de werking in multithreading modus te controleren, met meer dan twee threads.
BorgBackup in niet-versleutelde modus was iets langzamer dan tar, met een tijd van 2 minuten en 45 seconden, maar in tegenstelling tot tar had het de mogelijkheid tot deduplicatie van het repository. De belasting was hierbij
als volgt:
Als je versleuteling op basis van blake activeert, dan vertraagt de snelheid van het herstellen van de back-up iets. De hersteltijd in deze modus is 3 minuten en 19 seconden, en de belasting was
als volgt:
AES-versleuteling werkt iets langzamer, waarbij de hersteltijd 3 minuten en 23 seconden bedraagt; de belasting is niet bijzonder
veranderd:
Aangezien Borg in multithreading modus kan werken, is de CPU-belasting maximaal; bij het activeren van extra functies neemt echter simpelweg de uitvoeringstijd toe. Het lijkt erop dat het de moeite waard is om de multithreading werking net als zbackup te onderzoeken.
Restic was iets langzamer bij het herstel, met een uitvoeringstijd van 4 minuten en 28 seconden. De belasting zag er bij dat uit
zo:
Het lijkt erop dat het herstelproces in meerdere threads werkt, maar de efficiëntie is niet zo hoog als bij BorgBackup, maar qua tijd is het vergelijkbaar met de gebruikelijke rsync.
Met UrBackup kon de gegevens herstellen in 8 minuten en 19 seconden; de belasting was hierbij
als volgt:
Nog steeds is er te zien dat de belasting niet bijzonder hoog is, zelfs lager dan die van tar. Soms zijn er pieken, maar niet meer dan wat één kern aan kan.
Kies en motiveer de criteria voor vergelijking
Zoals eerder in een van de artikelen werd vermeld, moet het back-upsysteem voldoen aan de volgende criteria:
- Eenvoudig in gebruik
- Veelzijdigheid
- Stabiliteit
- Snelheid
Laten we elk punt apart wat gedetailleerder bekijken.
Ease of use
Het is het beste als er één knop is ‘Alles goed doen’, maar als we terugkeren naar echte programma's — zal een bepaalde vertrouwde en standaard werkmethode het handigst zijn.
De meeste gebruikers zullen waarschijnlijk liever hebben dat ze zich geen hele reeks sleutels voor de CLI hoeven te herinneren, dat ze niet een heleboel verschillende, vaak onduidelijke opties via web of TUI hoeven in te stellen, en dat ze meldingen over mislukte operaties kunnen instellen. Dit omvat ook de mogelijkheid om eenvoudig een back-upoplossing in de bestaande infrastructuur te integreren, evenals de automatisering van het back-upproces. Daarnaast is er de optie om het via een pakketbeheerder te installeren, of in een of twee commando's zoals 'downloaden en uitpakken'. curl link | sudo bash — een complexe methode, omdat je moet controleren wat er aankomt via de link.
Bijvoorbeeld, van de overwogen kandidaten zijn burp, rdiff-backup en restic eenvoudige oplossingen met gemakkelijk te onthouden sleutels voor verschillende werkingsmodi. Iets ingewikkelder zijn borg en duplicity. De meest complexe was AMANDA. De anderen zijn qua gebruiksgemak ergens daartussenin. In elk geval, als het meer dan 30 seconden kost om de gebruikershandleiding te lezen, of als je naar Google of een andere zoekmachine moet gaan, en ook een lang help-gever moet doorbladeren — dan is de oplossing complex, hoe dan ook.
Een deel van de overwogen kandidaten kan automatisch een bericht via e-mail of Jabber verzenden, terwijl anderen vertrouwen op ingestelde meldingen in het systeem. Vaak hebben complexe oplossingen niet al te duidelijke meldingsinstellingen. In elk geval, als het back-upprogramma een niet-nul terugkeercode genereert die correct door de systeemdienst voor periodieke taken wordt opgevat (het zou een bericht naar de systeembeheerder sturen of direct naar de monitoring) — dan is de situatie eenvoudig. Maar als het back-upsysteem, dat niet op de back-upserver draait, niet zonder configuratie op een voor de hand liggende manier over een probleem kan rapporteren — dan is de complexiteit al onterecht. In elk geval is het geven van waarschuwingen en andere meldingen alleen in de webinterface of in de logboeken — een slechte praktijk, omdat ze meestal genegeerd zullen worden.
Wat betreft automatisering — een eenvoudig programma kan omgevingsvariabelen lezen die zijn werkingsmodus bepalen, of het heeft een uitgebreide CLI die in staat is om het gedrag via de webinterface volledig te dupliceren, bijvoorbeeld. Dit omvat ook de mogelijkheid voor continue werking, uitbreidingsmogelijkheden, enz.
Veelzijdigheid
Deelt gedeeltelijk overeen met het vorige onderdeel met betrekking tot automatisering en het zou geen probleem moeten zijn om het backupproces in de bestaande infrastructuur te integreren.
Het is belangrijk op te merken dat het gebruik van niet-standaard poorten (behalve de webinterface) voor werking, het implementeren van encryptie op een niet-standaard manier, en gegevensuitwisseling via niet-standaard protocollen — tekenen zijn van een niet-universele oplossing. Bijna alle kandidaten hebben deze aspecten om een voor de hand liggende reden: eenvoud en universaliteit zijn meestal niet compatibel. Als uitzondering — burp, er zijn ook andere.
Een teken hiervan is de mogelijkheid om te werken met de reguliere ssh.
Snelheid
Het meest controversiële en betwiste punt. Aan de ene kant — het proces is gestart, het heeft zo snel mogelijk gewerkt en hinderde de hoofdtaken niet. Aan de andere kant — een piek in het verkeer en belasting van de CPU tijdens de backup. Het is ook belangrijk op te merken dat de snelste back-upprogramma's meestal de armste functionaliteit hebben, die belangrijk is voor gebruikers. Nogmaals: als het nodig is om één klein tekstbestand van een paar tientallen bytes met een wachtwoord op te halen, en vanwege dat bestand staat de hele service op het spel (ja, ik begrijp dat het backupproces hier meestal niet de schuld van is), en je moet alle bestanden in de repository sequenteel opnieuw lezen of een hele archief terugzetten — dan is het back-upsysteem bepaald niet snel. Een ander punt dat vaak een struikelblok is — de snelheid van het herstellen van een back-up uit een archief. Hier hebben degenen die eenvoudig bestanden naar de juiste locatie kunnen kopiëren of verplaatsen zonder veel poespas (bijvoorbeeld rsync) een duidelijk voordeel, maar meestal moet het probleem op een organisatorische manier worden opgelost, empirisch: de tijd voor het herstellen van de back-up meten en dit openlijk aan de gebruikers rapporteren.
Stabiliteit
Het moet zo worden begrepen: aan de ene kant moet het mogelijk zijn om de back-up op welke manier dan ook te herstellen, aan de andere kant — weerstand bieden aan verschillende problemen: netwerkonderbreking, schijfuitval, verwijdering van een deel van de repository.
Vergelijking van back-upmiddelen
Tijd voor het maken van een kopie
Tijd voor het herstellen van een kopie
Eenvoudige installatie
Eenvoudige configuratie
Eenvoudig gebruik
Eenvoudige automatisering
Is een client-server nodig?
Controle van de integriteit van de repository
Differentiële back-ups
Werken via pipe
Veelzijdigheid
Zelfstandigheid
Transparantie van de repository
Versleuteling
Compressie
Deduplicatie
Web-interface
Uploaden naar de cloud
Ondersteuning voor Windows
Score
Rsync
4m15s
4m28s
ja
nee
nee
nee
ja
nee
nee
ja
nee
ja
ja
nee
nee
nee
nee
nee
ja
6
Tar
pure
3m12s
2m43s
ja
nee
nee
nee
nee
nee
ja
ja
nee
ja
nee
nee
nee
nee
nee
nee
ja
8,5
gzip
9m37s
3m19s
ja
Rdiff-backup
16m26s
17m17s
ja
ja
ja
ja
ja
nee
ja
nee
ja
nee
ja
nee
ja
ja
ja
nee
ja
11
Rsnapshot
4m19s
4m28s
ja
ja
ja
ja
nee
nee
ja
nee
ja
nee
ja
nee
nee
ja
ja
nee
ja
12,5
Burp
11m9s
7m2s
ja
nee
ja
ja
ja
ja
ja
nee
ja
ja
nee
nee
ja
nee
ja
nee
ja
10,5
Dupliciteit
geen encryptie
16m48s
10m58s
ja
ja
nee
ja
nee
ja
ja
nee
nee
ja
nee
ja
ja
nee
ja
nee
ja
11
gpg
17m27s
15m3s
Duplicati
geen encryptie
20m28s
13m45s
nee
ja
nee
nee
nee
ja
ja
nee
nee
ja
nee
ja
ja
ja
ja
ja
ja
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
geen encryptie
40m3s
11m8s
ja
ja
nee
nee
nee
ja
ja
ja
nee
ja
nee
ja
ja
ja
nee
nee
nee
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
geen encryptie
4m7s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nee
ja
ja
ja
ja
nee
ja
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
ja
ja
ja
ja
nee
ja
ja
ja
ja
ja
nee
ja
nee
ja
nee
ja
ja
15,5
UrBackup
8m21s
8m19s
ja
ja
ja
nee
ja
nee
ja
nee
ja
ja
nee
ja
ja
ja
ja
nee
ja
12
Amanda
9m3s
2m49s
ja
nee
nee
ja
ja
ja
ja
nee
ja
ja
ja
ja
ja
nee
ja
ja
ja
13
BackupPC
rsync
12m22s
7m42s
ja
nee
ja
ja
ja
ja
ja
nee
ja
nee
nee
ja
ja
nee
ja
nee
ja
10,5
tar
12m34s
12m15s
Legenda van de tabel:
- Groen, werktijd minder dan vijf minuten, of antwoord 'Ja' (behalve in de kolom 'Is client-server nodig?'), 1 punt
- Geel, werktijd vijf tot tien minuten, 0,5 punt
- Rood, werktijd meer dan tien minuten, of antwoord 'Nee' (behalve in de kolom 'Is client-server nodig?'), 0 punten
Volgens de bovenstaande tabel is BorgBackup de eenvoudigste, snelste en tegelijkertijd gebruiksvriendelijke en krachtige back-uptool. De tweede plaats is voor Restic, terwijl de andere overwogen kandidaten ongeveer gelijk eindigden met een spreiding van één tot twee punten aan het eind.
Bedankt aan iedereen die de serie tot het einde heeft gelezen, ik nodig jullie uit om opties te bespreken en jullie suggesties te doen, indien beschikbaar. Naarmate de discussie vordert, kan de tabel worden aangevuld.
Het resultaat van de serie zal een afsluitend artikel zijn, waarin geprobeerd wordt een ideale, snelle en beheersbare back-upoplossing te presenteren die het mogelijk maakt om de back-up in de kortst mogelijke tijd te herstellen, terwijl er tevens gebruiksgemak en eenvoud in configuratie en onderhoud is.
Aankondiging
Back-up, deel 6: Vergelijking van back-upoplossingen
Back-up, deel 7: Conclusies
Bron: habr.com
