{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Back-up, deel 6: Vergelijking van back-upoplossingen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Back-up,
\nIn 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.
\nVoor 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).
\n<\/a><\/noindex><\/p>\n

Gegevensherstel<\/h2>\n

\nAls referentiepunt worden rsync en tar gebruikt, omdat ze meestal de basis vormen voor<\/a><\/noindex> de eenvoudigste back-up scripts.<\/p>\n

Rsync<\/i> heeft de testset gegevens binnen 4 minuten en 28 seconden verwerkt, met <\/p>\n

deze belasting.<\/b>\"Back-up,
\n
\nHet herstelproces liep tegen de beperkingen van het schijf subsysteem van de back-up server (zaagtandgrafieken). Ook is de belasting van \u00e9\u00e9n kern duidelijk zichtbaar zonder noemenswaardige problemen (lage iowait en softirq \u2014 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.<\/p>\n

Tar<\/i> was iets sneller, in <\/p>\n

2 minuten en 43 seconden:<\/b>\"Back-up,
\n
\nDe totale systeembelasting was gemiddeld 20% hoger door de toegenomen softirq \u2014 de overhead was stijgend bij de werking van het netwerk subsysteem.<\/p>\n

Als het archief bovendien wordt gecomprimeerd, dan stijgt de hersteltijd naar 3 minuten en 19 seconden met
\ndeze belasting op de hoofd server (uitpakken aan de kant van de hoofd server):<\/b>\"Back-up,
\n
\nHet 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).<\/p>\n

In rdiff-backup<\/i> 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 <\/p>\n

de volgende belasting:<\/b>\"Back-up,
\n
\nHet kan zijn dat dit zo bedoeld was; in elk geval voor de snelheidsbeperking stellen de auteurs dit soort oplossing voor.<\/a><\/noindex>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.<\/p>\n

Rsnapshot<\/i> 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.<\/p>\n

Burp<\/i> voltooid de hersteltaak in 7 minuten en 2 seconden met
\nde volgende belasting:<\/b>\"Back-up,
\n
\nHet ging vrij snel en, tenminste, het is veel handiger dan pure rsync: je hoeft je geen vlaggen te herinneren, een eenvoudige en intu\u00eftieve cli-interface, ingebouwde ondersteuning voor meerdere kopie\u00ebn \u2014 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.<\/p>\n

Ongeveer dezelfde snelheid en belasting werd getoond door het programma BackupPC<\/i> bij het inschakelen van de rsync-transmissiemodus, waarbij de back-up werd hersteld in <\/p>\n

7 minuten en 42 seconden:<\/b>\"Back-up,
\n
\nMaar in de tar-transmissiemodus was BackupPC trager: in 12 minuten en 15 seconden, met een lagere CPU-belasting over het algemeen <\/p>\n

van anderhalf keer:<\/b>\"Back-up,
\n
\nDupliciteit<\/i> 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:<\/p>\n

zonder encryptie<\/b>\"Back-up,
\n
\nmet encryptie<\/b>\"Back-up,
\n
\nDuplicati<\/i> 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 <\/p>\n

redelijk hoog:<\/b>\"Back-up,
\n
\nToen 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 \u00e9\u00e9n thread actief, die \u00e9\u00e9n CPU-kern bezette. De controle van de gegevens na het herstel kostte dezelfde 5 minuten (totaal bijna 27 minuten).<\/p>\n

Resultaat<\/b>\"Back-up,
\n
\nDuplicati 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 <\/p>\n

als volgt:<\/b>\"Back-up,
\n
\nAMANDA<\/i>, 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 <\/p>\n

dezelfde:<\/b>\"Back-up,
\n
\nBij het herstellen van een back-up met behulp van zbackup<\/i> werden de volgende resultaten verkregen:<\/p>\n

encryptie, compressie lzma<\/b>\"Back-up,
\n
\nTotale werktijd 11 minuten en 8 seconden<\/p>\n

encryptie aes, compressie lzma<\/b>\"Back-up,
\n
\nTotale werktijd 14 minuten<\/p>\n

encryptie aes, compressie lzo<\/b>\"Back-up,
\n
\nTotale werktijd 6 minuten en 19 seconden<\/p>\n

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 \u2014 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.<\/p>\n

BorgBackup<\/i> 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 <\/p>\n

als volgt:<\/b>\"Back-up,
\n
\nAls 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 <\/p>\n

als volgt:<\/b>\"Back-up,
\n
\nAES-versleuteling werkt iets langzamer, waarbij de hersteltijd 3 minuten en 23 seconden bedraagt; de belasting is niet bijzonder <\/p>\n

veranderd:<\/b>\"Back-up,
\n
\nAangezien 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.<\/p>\n

Restic<\/i> was iets langzamer bij het herstel, met een uitvoeringstijd van 4 minuten en 28 seconden. De belasting zag er bij dat uit <\/p>\n

zo:<\/b>\"Back-up,
\n
\nHet lijkt erop dat het herstelproces in meerdere threads werkt, maar de effici\u00ebntie is niet zo hoog als bij BorgBackup, maar qua tijd is het vergelijkbaar met de gebruikelijke rsync.<\/p>\n

Met UrBackup<\/i> kon de gegevens herstellen in 8 minuten en 19 seconden; de belasting was hierbij <\/p>\n

als volgt:<\/b>\"Back-up,
\n
\nNog 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 \u00e9\u00e9n kern aan kan.<\/p>\n

Kies en motiveer de criteria voor vergelijking<\/h2>\n

\nZoals eerder in een van de artikelen werd vermeld, moet het back-upsysteem voldoen aan de volgende criteria:<\/p>\n