In dit artikel worden back-uptools vergeleken, maar eerst moet u ontdekken hoe snel en goed ze omgaan met het herstellen van gegevens uit back-ups.
Voor het gemak van vergelijking zullen we overwegen om te herstellen vanaf een volledige back-up, vooral omdat alle kandidaten deze werkingsmodus ondersteunen. Voor de eenvoud zijn de getallen al gemiddeld (het rekenkundig gemiddelde van verschillende runs). De resultaten worden samengevat in een tabel, die ook informatie bevat over de mogelijkheden: de aanwezigheid van een webinterface, installatie- en bedieningsgemak, de mogelijkheid om te automatiseren, de aanwezigheid van verschillende extra functies (bijvoorbeeld het controleren van de gegevensintegriteit) , enz. De grafieken tonen de belasting van de server waarop de gegevens zullen worden gebruikt (niet de server voor het opslaan van back-upkopieën).
Gegevens herstel
rsync en tar zullen sindsdien als referentiepunt worden gebruikt eenvoudige scripts voor het maken van back-upkopieën.
rsync verwerkte de testgegevensset in 4 minuten en 28 seconden, wat blijkt
zo'n last
Het herstelproces stuitte op een beperking van het schijfsubsysteem van de back-upopslagserver (zaagtandgrafieken). Je kunt ook duidelijk het laden van één kernel zien zonder enige problemen (low iowait en softirq - geen problemen met respectievelijk de schijf en het netwerk). Omdat de andere twee programma's, namelijk rdiff-backup en rsnapshot, gebaseerd zijn op rsync en ook reguliere rsync aanbieden als hersteltool, zullen ze ongeveer hetzelfde laadprofiel en dezelfde back-uphersteltijd hebben.
Teer heb het iets sneller gedaan
2 minuten en 43 seconden:
De totale systeembelasting was gemiddeld 20% hoger vanwege de toegenomen softirq - de overheadkosten tijdens de werking van het netwerksubsysteem namen toe.
Als het archief verder wordt gecomprimeerd, neemt de hersteltijd toe tot 3 minuten en 19 seconden.
met een dergelijke belasting van de hoofdserver (uitpakken aan de zijkant van de hoofdserver):
Het decompressieproces neemt beide processorkernen in beslag omdat er twee processen actief zijn. Over het algemeen is dit het verwachte resultaat. Ook werd een vergelijkbaar resultaat (3 minuten en 20 seconden) verkregen bij het uitvoeren van gzip op de server met back-ups; het belastingsprofiel op de hoofdserver was zeer vergelijkbaar met het uitvoeren van tar zonder de gzip-compressor (zie vorige grafiek).
В rdiff-back-up je kunt de laatste back-up die je hebt gemaakt synchroniseren met reguliere rsync (de resultaten zullen vergelijkbaar zijn), maar oudere back-ups moeten nog steeds worden hersteld met behulp van het rdiff-backup-programma, dat het herstel in 17 minuten en 17 seconden voltooide, wat laat zien
deze lading:
Misschien was dit de bedoeling, in ieder geval om de snelheid van de auteurs te beperken . Het proces van het herstellen van een back-upkopie zelf neemt iets minder dan de helft van één kern in beslag, met proportioneel vergelijkbare prestaties (dat wil zeggen 2-5 keer langzamer) via schijf en netwerk met rsync.
Momentopname Voor herstel wordt aangeraden om reguliere rsync te gebruiken, zodat de resultaten vergelijkbaar zullen zijn. Over het algemeen is dit hoe het bleek.
Boeren Ik voltooide de taak van het herstellen van een back-up in 7 minuten en 2 seconden met
met deze lading:
Het werkte vrij snel, en is in ieder geval veel handiger dan pure rsync: je hoeft geen vlaggen te onthouden, een eenvoudige en intuïtieve cli-interface, ingebouwde ondersteuning voor meerdere kopieën - hoewel het twee keer langzamer is. Als u gegevens wilt herstellen van de laatste back-up die u hebt gemaakt, kunt u rsync gebruiken, met een paar kanttekeningen.
Het programma vertoonde ongeveer dezelfde snelheid en belasting Back-upPC bij het inschakelen van de rsync-overdrachtsmodus, het implementeren van de back-up voor
7 minuten en 42 seconden:
Maar in de gegevensoverdrachtmodus ging BackupPC langzamer om met teer: in 12 minuten en 15 seconden was de processorbelasting over het algemeen lager
anderhalf keer:
Dubbelhartigheid zonder codering liet iets betere resultaten zien: het herstellen van een back-up in 10 minuten en 58 seconden. Als u de versleuteling activeert met behulp van gpg, wordt de hersteltijd verlengd tot 15 minuten en 3 seconden. Wanneer u een opslagplaats maakt voor het opslaan van kopieën, kunt u ook de archiefgrootte opgeven die wordt gebruikt bij het splitsen van de binnenkomende gegevensstroom. Over het algemeen is er op conventionele harde schijven, ook vanwege de single-threaded werkingsmodus, niet veel verschil. Het kan bij verschillende blokgroottes verschijnen wanneer hybride opslag wordt gebruikt. De belasting op de hoofdserver tijdens het herstel was als volgt:
geen encryptie
met encryptie
Duplicati toonde een vergelijkbaar herstelpercentage en voltooide het in 13 minuten en 45 seconden. Het duurde nog ongeveer 5 minuten om de juistheid van de herstelde gegevens te controleren (in totaal ongeveer 19 minuten). De lading was
nogal hoog:
Wanneer AES-encryptie intern was ingeschakeld, bedroeg de hersteltijd 21 minuten en 40 seconden, waarbij het CPU-gebruik maximaal was (beide cores!) tijdens het herstel; Bij het controleren van de gegevens was er slechts één thread actief, die één processorkern in beslag nam. Het controleren van de gegevens na herstel duurde dezelfde 5 minuten (bijna 27 minuten in totaal).
Resultaat
duplicati was iets sneller met herstel bij gebruik van het externe gpg-programma voor codering, maar over het algemeen zijn de verschillen met de vorige modus minimaal. De bedrijfstijd was 16 minuten en 30 seconden, met gegevensverificatie in 6 minuten. De lading was
zo een:
AMANDA, met teer, voltooide het in 2 minuten en 49 seconden, wat in principe heel dicht bij gewone teer ligt. Belast het systeem in principe
hetzelfde:
Wanneer u een back-up herstelt met behulp van zback-up de volgende resultaten werden verkregen:
encryptie, lzma-compressie
Speelduur 11 minuten en 8 seconden
AES-codering, lzma-compressie
Werktijd 14 minuten
AES-codering, lzo-compressie
Speelduur 6 minuten, 19 seconden
Over het algemeen niet slecht. Het hangt allemaal af van de snelheid van de processor op de back-upserver, wat duidelijk te zien is aan de looptijd van het programma met verschillende compressoren. Aan de kant van de back-upserver werd een gewone tar gelanceerd, dus als je het daarmee vergelijkt, is het herstel 3 keer langzamer. Het kan de moeite waard zijn om de werking in multi-threaded modus, met meer dan twee threads, te controleren.
BorgBack-up in de niet-gecodeerde modus was het iets langzamer dan tar, in 2 minuten en 45 seconden, maar in tegenstelling tot tar werd het mogelijk om de repository te ontdubbelen. De lading bleek te zijn
De volgende:
Als u op blake gebaseerde codering inschakelt, is de herstelsnelheid van de back-up iets langzamer. De hersteltijd in deze modus is 3 minuten en 19 seconden en de belasting is verdwenen
soortgelijk:
AES-codering is iets langzamer, de hersteltijd bedraagt 3 minuten en 23 seconden, vooral de belasting
is niet veranderd:
Omdat Borg in multi-threaded modus kan werken, is de processorbelasting maximaal en wanneer extra functies worden geactiveerd, neemt de bedrijfstijd eenvoudigweg toe. Blijkbaar is het de moeite waard om multithreading op een vergelijkbare manier als zbackup te verkennen.
Restisch ging iets langzamer om met het herstel, de operatietijd was 4 minuten en 28 seconden. De lading zag eruit
als volgt:
Blijkbaar werkt het herstelproces in meerdere threads, maar de efficiëntie is niet zo hoog als die van BorgBackup, maar qua tijd vergelijkbaar met gewone rsync.
Met uwBack-up Het was mogelijk om de gegevens in 8 minuten en 19 seconden te herstellen, de belasting was
zo een:
De belasting is nog steeds niet erg hoog, zelfs lager dan die van teer. Op sommige plaatsen zijn er uitbarstingen, maar niet meer dan de belasting van één kern.
Selectie en rechtvaardiging van vergelijkingscriteria
Zoals vermeld in een van de voorgaande artikelen moet het backupsysteem aan de volgende criteria voldoen:
- Makkelijk te gebruiken
- Universalisme
- stabiliteit
- snelheid
Het is de moeite waard om elk punt afzonderlijk in meer detail te bekijken.
Bedieningsgemak
Het is het beste als er één knop is 'Doe alles goed', maar als je terugkeert naar echte programma's, is het handigste een bekend en standaard werkingsprincipe.
De meeste gebruikers zullen waarschijnlijk beter af zijn als ze niet een aantal sleutels voor cli hoeven te onthouden, een heleboel verschillende, vaak obscure opties via internet of tui hoeven te configureren, of meldingen over mislukte bewerkingen hoeven in te stellen. Dit omvat ook de mogelijkheid om een back-upoplossing eenvoudig in de bestaande infrastructuur te ‘inpassen’, evenals de automatisering van het back-upproces. Er is ook de mogelijkheid om te installeren met behulp van een pakketbeheerder, of met een of twee commando's zoals "downloaden en uitpakken". curl ссылка | sudo bash - een complexe methode, omdat je moet controleren wat er via de link binnenkomt.
Van de onderzochte kandidaten is een eenvoudige oplossing bijvoorbeeld burp, rdiff-backup en restic, die geheugensleutels hebben voor verschillende bedieningsmodi. Iets complexer zijn borg en dubbelhartigheid. Het moeilijkste was AMANDA. De rest zit qua gebruiksgemak ergens in het midden. Hoe dan ook, als u meer dan 30 seconden nodig heeft om de gebruikershandleiding te lezen, of als u naar Google of een andere zoekmachine moet gaan en ook door een lang blad met hulp moet scrollen, is de beslissing op de een of andere manier moeilijk.
Sommige van de overwogen kandidaten kunnen automatisch een bericht sturen via e-mailjabber, terwijl anderen vertrouwen op geconfigureerde waarschuwingen in het systeem. Bovendien hebben complexe oplossingen meestal niet geheel voor de hand liggende waarschuwingsinstellingen. In ieder geval, als het back-upprogramma een retourcode produceert die niet nul is, die correct zal worden begrepen door de systeemservice voor periodieke taken (er wordt een bericht verzonden naar de systeembeheerder of rechtstreeks naar de monitoring), dan is de situatie eenvoudig. Maar als het back-upsysteem, dat niet op een back-upserver draait, niet kan worden geconfigureerd, is de voor de hand liggende manier om over het probleem te zeggen dat de complexiteit al buitensporig groot is. In ieder geval is het een slechte gewoonte om waarschuwingen en andere berichten alleen naar de webinterface of naar het logboek te sturen, omdat deze meestal worden genegeerd.
Wat automatisering betreft: een eenvoudig programma kan omgevingsvariabelen lezen die de werkingsmodus bepalen, of het heeft een ontwikkelde cli die het gedrag volledig kan dupliceren wanneer u bijvoorbeeld via een webinterface werkt. Hieronder valt ook de mogelijkheid tot continue exploitatie, de beschikbaarheid van uitbreidingsmogelijkheden, etc.
Universalisme
Gedeeltelijk in navolging van de vorige paragraaf over automatisering, zou het geen bijzonder probleem moeten zijn om het back-upproces in de bestaande infrastructuur in te passen.
Het is vermeldenswaard dat het gebruik van niet-standaard poorten (nou ja, behalve de webinterface) voor werk, de implementatie van encryptie op een niet-standaard manier, de uitwisseling van gegevens met behulp van een niet-standaard protocol tekenen zijn van een niet-standaard protocol. -universele oplossing. Voor het grootste deel hebben alle kandidaten ze op de een of andere manier om de voor de hand liggende reden: eenvoud en veelzijdigheid gaan meestal niet samen. Als uitzondering - boer, zijn er anderen.
Als teken - de mogelijkheid om met reguliere ssh te werken.
Werk snelheid
Het meest controversiële en controversiële punt. Aan de ene kant hebben we het proces gelanceerd, het werkte zo snel mogelijk en interfereerde niet met de hoofdtaken. Aan de andere kant is er tijdens de back-upperiode sprake van een toename van het verkeer en de processorbelasting. Het is ook vermeldenswaard dat de snelste programma's voor het maken van kopieën meestal de slechtste zijn in termen van functies die belangrijk zijn voor gebruikers. Nogmaals: als je één ongelukkig tekstbestand van enkele tientallen bytes groot wilt krijgen met een wachtwoord, en daardoor de volledige servicekosten (ja, ja, ik begrijp dat het back-upproces hier meestal niet de schuld is), en je moet alle bestanden in de repository achtereenvolgens opnieuw lezen of het hele archief uitbreiden - het back-upsysteem is nooit snel. Een ander punt dat vaak een struikelblok vormt, is de snelheid waarmee een back-up uit een archief kan worden ingezet. Er is hier een duidelijk voordeel voor degenen die eenvoudigweg bestanden naar de gewenste locatie kunnen kopiëren of verplaatsen zonder veel manipulatie (bijvoorbeeld rsync), maar meestal moet het probleem op een organisatorische manier worden opgelost, empirisch: door de hersteltijd van de back-up te meten en het openlijk informeren van gebruikers hierover.
stabiliteit
Het moet op deze manier worden opgevat: aan de ene kant moet het mogelijk zijn om de back-upkopie op welke manier dan ook terug te zetten, aan de andere kant moet deze bestand zijn tegen verschillende problemen: netwerkonderbreking, schijfstoring, verwijdering van een deel van de opslagplaats.
Vergelijking van back-uptools
Kopieer de aanmaaktijd
Kopieer de hersteltijd
Makkelijke installatie
остая астройка
Makkelijk te gebruiken
Eenvoudige automatisering
Heeft u een clientserver nodig?
Controle van de integriteit van de repository
Differentiële kopieën
Werken via pijp
Universalisme
Onafhankelijkheid
Transparantie van de opslagplaats
Versleuteling
samendrukking
Ontdubbeling
Web-interface
Vullen tot aan de wolk
Windows-ondersteuning
mark
rsync
4m15s
4m28s
ja
geen
geen
geen
ja
geen
geen
ja
geen
ja
ja
geen
geen
geen
geen
geen
ja
6
Teer
zuiver
3m12s
2m43s
ja
geen
geen
geen
geen
geen
ja
ja
geen
ja
geen
geen
geen
geen
geen
geen
ja
8,5
gzip
9m37s
3m19s
ja
Rdiff-back-up
16m26s
17m17s
ja
ja
ja
ja
ja
geen
ja
geen
ja
geen
ja
geen
ja
ja
ja
geen
ja
11
Momentopname
4m19s
4m28s
ja
ja
ja
ja
geen
geen
ja
geen
ja
geen
ja
geen
geen
ja
ja
geen
ja
12,5
Boeren
11m9s
7m2s
ja
geen
ja
ja
ja
ja
ja
geen
ja
ja
geen
geen
ja
geen
ja
geen
ja
10,5
Dubbelhartigheid
geen encryptie
16m48s
10m58s
ja
ja
geen
ja
geen
ja
ja
geen
geen
ja
geen
ja
ja
geen
ja
geen
ja
11
GPG
17m27s
15m3s
Duplicati
geen encryptie
20m28s
13m45s
geen
ja
geen
geen
geen
ja
ja
geen
geen
ja
geen
ja
ja
ja
ja
ja
ja
11
aes
29m41s
21m40s
GPG
26m19s
16m30s
zbackup
geen encryptie
40m3s
11m8s
ja
ja
geen
geen
geen
ja
ja
ja
geen
ja
geen
ja
ja
ja
geen
geen
geen
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBack-up
geen encryptie
4m7s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
geen
ja
ja
ja
ja
geen
ja
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restisch
5m38s
4m28s
ja
ja
ja
ja
geen
ja
ja
ja
ja
ja
geen
ja
geen
ja
geen
ja
ja
15,5
uwBack-up
8m21s
8m19s
ja
ja
ja
geen
ja
geen
ja
geen
ja
ja
geen
ja
ja
ja
ja
geen
ja
12
Amanda
9m3s
2m49s
ja
geen
geen
ja
ja
ja
ja
geen
ja
ja
ja
ja
ja
geen
ja
ja
ja
13
Back-upPC
rsync
12m22s
7m42s
ja
geen
ja
ja
ja
ja
ja
geen
ja
geen
geen
ja
ja
geen
ja
geen
ja
10,5
teer
12m34s
12m15s
Tabellegenda:
- Groen, bedrijfstijd minder dan vijf minuten, of antwoord “Ja” (behalve de kolom “Cliëntserver nodig?”), 1 punt
- Geel, bedrijfstijd vijf tot tien minuten, 0.5 punt
- Rood, de werktijd is meer dan tien minuten, of het antwoord is “Nee” (behalve de kolom “Heeft u een clientserver nodig?”), 0 punten
Volgens de bovenstaande tabel is BorgBackup de eenvoudigste, snelste en tegelijkertijd handige en krachtige back-uptool. Restic behaalde de tweede plaats, de rest van de overwogen kandidaten werd ongeveer gelijk geplaatst met een spreiding van één of twee punten aan het einde.
Ik bedank iedereen die de serie tot het einde heeft gelezen, ik nodig je uit om de opties te bespreken en eventueel je eigen opties aan te bieden. Naarmate de discussie vordert, kan de tabel worden uitgebreid.
Het resultaat van de serie zal het laatste artikel zijn, waarin wordt geprobeerd een ideale, snelle en beheersbare back-uptool te ontwikkelen waarmee u in de kortst mogelijke tijd een kopie kunt terugzetten en tegelijkertijd handig en gemakkelijk kunt zijn configureren en onderhouden.
aankondiging
Back-up deel 6: back-uptools vergelijken
Back-up Deel 7: Conclusies
Bron: www.habr.com