Waarom moet u back-ups maken? De apparatuur is immers heel erg betrouwbaar, en bovendien zijn er ‘clouds’ die qua betrouwbaarheid beter zijn dan fysieke servers: met de juiste configuratie kan een ‘cloud’-server gemakkelijk het falen van een fysieke infrastructuurserver overleven, en van Vanuit het oogpunt van de gebruikers van de dienst zal er sprake zijn van een kleine, nauwelijks waarneembare sprong in de tijd van de dienst. Bovendien vereist het dupliceren van informatie vaak dat er moet worden betaald voor ‘extra’ processortijd, schijfbelasting en netwerkverkeer.
Een ideaal programma werkt snel, lekt geen geheugen, heeft geen gaten en bestaat niet.
-Onbekend
Omdat programma's nog steeds door eiwitontwikkelaars worden geschreven, en er vaak geen testproces is, en programma's zelden worden geleverd met behulp van 'best practices' (die zelf ook programma's zijn en daarom onvolmaakt), moeten systeembeheerders meestal problemen oplossen die kort maar krachtig klinken. kort en bondig: "keer terug naar hoe het was", "breng de basis naar de normale werking", "werkt langzaam - terugdraaien", en ook mijn favoriet "Ik weet niet wat, maar repareer het".
Naast logische fouten die ontstaan als gevolg van onzorgvuldig werk van ontwikkelaars, of een combinatie van omstandigheden, evenals onvolledige kennis of misverstanden over kleine kenmerken van bouwprogramma's - inclusief verbindings- en systeemprogramma's, inclusief besturingssystemen, stuurprogramma's en firmware - er zijn ook andere fouten. De meeste ontwikkelaars vertrouwen bijvoorbeeld op runtime en vergeten de fysieke wetten volledig, die nog steeds niet te omzeilen zijn met behulp van programma's. Dit omvat de oneindige betrouwbaarheid van het schijfsubsysteem en, in het algemeen, elk gegevensopslagsubsysteem (inclusief RAM en processorcache!), en nulverwerkingstijd op de processor, en de afwezigheid van fouten tijdens transmissie via het netwerk en tijdens verwerking op de processor en netwerklatentie, die gelijk is aan 0. Je moet de beruchte deadline niet verwaarlozen, want als je deze niet op tijd haalt, zullen er problemen zijn die erger zijn dan de nuances van het netwerk- en schijfgebruik.
Wat te doen met problemen die in volle omvang toenemen en waardevolle gegevens in de weg staan? Er is niets dat levende ontwikkelaars kan vervangen, en het is ook geen feit dat dit in de nabije toekomst mogelijk zal zijn. Aan de andere kant zijn slechts enkele projecten erin geslaagd volledig te bewijzen dat het programma zal werken zoals bedoeld, en het zal niet noodzakelijkerwijs mogelijk zijn om het bewijsmateriaal over te nemen en toe te passen op andere, soortgelijke projecten. Bovendien kost dergelijk bewijsmateriaal veel tijd en vereist het speciale vaardigheden en kennis, en dit minimaliseert praktisch de mogelijkheid dat het wordt gebruikt, rekening houdend met deadlines. Bovendien weten we nog niet hoe we ultrasnelle, goedkope en oneindig betrouwbare technologie moeten gebruiken voor het opslaan, verwerken en verzenden van informatie. Dergelijke technologieën, als ze al bestaan, zijn aanwezig in de vorm van concepten, of – meestal – alleen in sciencefictionboeken en -films.
Goede artiesten kopiëren, geweldige artiesten stelen.
-Pablo Picasso.
De meest succesvolle oplossingen en verrassend eenvoudige dingen gebeuren meestal daar waar concepten, technologieën, kennis en wetenschapsgebieden die op het eerste gezicht absoluut onverenigbaar zijn, elkaar ontmoeten.
Vogels en vliegtuigen hebben bijvoorbeeld vleugels, maar ondanks de functionele gelijkenis is het werkingsprincipe in sommige modi hetzelfde en worden technische problemen op een vergelijkbare manier opgelost: holle botten, het gebruik van sterke en lichtgewicht materialen, enz. - de resultaten zijn totaal verschillend, hoewel zeer vergelijkbaar. De beste voorbeelden die we in onze technologie zien, zijn ook grotendeels ontleend aan de natuur: de onder druk staande compartimenten van schepen en onderzeeërs zijn een directe analogie met ringwormen; het bouwen van raid-arrays en het controleren van de gegevensintegriteit - het dupliceren van de DNA-keten; evenals gepaarde organen, onafhankelijkheid van het werk van verschillende organen van het centrale zenuwstelsel (automatisering van het hart) en reflexen - autonome systemen op internet. Natuurlijk brengt het ‘frontaal’ nemen en toepassen van kant-en-klare oplossingen veel problemen met zich mee, maar wie weet zijn er misschien geen andere oplossingen.
Had ik maar geweten waar je zou vallen, dan had ik rietjes neergelegd!
– Wit-Russisch volksspreekwoord
Dit betekent dat back-upkopieën van cruciaal belang zijn voor degenen die:
- U kunt de werking van uw systemen herstellen met minimale downtime, of zelfs helemaal zonder
- Handel moedig, want in geval van een fout bestaat altijd de mogelijkheid van een terugdraaiing
- Minimaliseer de gevolgen van opzettelijke datacorruptie
Hier is een kleine theorie
Elke classificatie is willekeurig. De natuur classificeert niet. We classificeren omdat het handiger voor ons is. En we classificeren op basis van gegevens die we ook willekeurig verzamelen.
—Jean Bruler
Ongeacht de fysieke opslagmethode kan logische gegevensopslag worden onderverdeeld in twee manieren om toegang te krijgen tot deze gegevens: blok en bestand. Deze scheiding is de laatste tijd erg vervaagd, omdat zowel puur blok- als puur bestands-logische opslag niet bestaat. Voor de eenvoud gaan we er echter van uit dat ze bestaan.
Blokgegevensopslag houdt in dat er een fysiek apparaat is waarop gegevens in bepaalde vaste gedeelten, blokken, worden geschreven. Blokken zijn toegankelijk op een bepaald adres; elk blok heeft zijn eigen adres binnen het apparaat.
Een back-up wordt meestal gemaakt door gegevensblokken te kopiëren. Om de gegevensintegriteit te garanderen, wordt de opname van nieuwe blokken, evenals wijzigingen in bestaande blokken, opgeschort op het moment van kopiëren. Als we een analogie uit de gewone wereld nemen, komt het dichtst in de buurt van een kast met identiek genummerde cellen.
De opslag van bestandsgegevens op basis van het logische apparaatprincipe komt dicht in de buurt van blokopslag en wordt vaak bovenaan georganiseerd. Belangrijke verschillen zijn de aanwezigheid van een opslaghiërarchie en voor mensen leesbare namen. Een abstractie wordt toegewezen in de vorm van een bestand - een benoemd gegevensgebied, evenals een map - een speciaal bestand waarin beschrijvingen en toegang tot andere bestanden worden opgeslagen. Bestanden kunnen worden voorzien van aanvullende metadata: aanmaaktijd, toegangsvlaggen, etc. Back-ups worden meestal op deze manier gemaakt: ze zoeken naar gewijzigde bestanden en kopiëren ze vervolgens naar een andere bestandsopslag met dezelfde structuur. Gegevensintegriteit wordt meestal geïmplementeerd door de afwezigheid van bestanden waarnaar wordt geschreven. Van de metagegevens van bestanden wordt op dezelfde manier een back-up gemaakt. De dichtstbijzijnde analogie is een bibliotheek, die secties heeft met verschillende boeken, en ook een catalogus heeft met voor mensen leesbare namen van de boeken.
Onlangs wordt soms een andere optie beschreven, van waaruit in principe de opslag van bestandsgegevens begon, en die dezelfde archaïsche kenmerken heeft: objectgegevensopslag.
Het verschilt van bestandsopslag doordat het niet meer dan één nesting heeft (plat schema), en de bestandsnamen, hoewel voor mensen leesbaar, nog steeds geschikter zijn voor verwerking door machines. Bij het uitvoeren van back-ups wordt objectopslag meestal op dezelfde manier behandeld als bestandsopslag, maar af en toe zijn er andere opties.
— Er zijn twee soorten systeembeheerders: degenen die geen back-ups maken, en degenen die dat AL doen.
- Eigenlijk zijn er drie soorten: er zijn ook mensen die controleren of back-ups kunnen worden hersteld.-Onbekend
Het is ook de moeite waard om te begrijpen dat het gegevensback-upproces zelf wordt uitgevoerd door programma's, en dus dezelfde nadelen heeft als elk ander programma. Om de afhankelijkheid van de menselijke factor en kenmerken – die afzonderlijk geen sterk effect hebben, maar samen wel een merkbaar effect kunnen hebben – weg te nemen (niet te elimineren!) worden de zogenaamde regel 3-2-1. Er zijn veel opties om het te ontcijferen, maar ik vind de volgende interpretatie beter: 3 sets van dezelfde gegevens moeten worden opgeslagen, 2 sets moeten in verschillende formaten worden opgeslagen en 1 set moet worden opgeslagen in een geografisch afgelegen opslagplaats.
Het opslagformaat moet als volgt worden begrepen:
- Als er een afhankelijkheid is van de fysieke opslagmethode, veranderen we de fysieke methode.
- Als er een afhankelijkheid is van de logische opslagmethode, veranderen we de logische methode.
Om het maximale effect van de 3-2-1-regel te bereiken, wordt aanbevolen om het opslagformaat op beide manieren te wijzigen.
Vanuit het oogpunt van de gereedheid van een backup voor het beoogde doel – het herstellen van functionaliteit – wordt onderscheid gemaakt tussen “hot” en “cold” backups. Warme versies verschillen slechts in één ding van koude: ze zijn onmiddellijk klaar voor gebruik, terwijl koude versies enkele extra stappen vereisen voor herstel: decodering, extractie uit het archief, enz.
Verwar warme en koude kopieën niet met online en offline kopieën, die fysieke isolatie van gegevens impliceren en in feite een ander teken zijn van de classificatie van back-upmethoden. Een offline kopie - die niet rechtstreeks is verbonden met het systeem waarop deze moet worden hersteld - kan dus zowel warm als koud zijn (in termen van gereedheid voor herstel). Een online exemplaar kan direct beschikbaar zijn waar het moet worden hersteld, en meestal is het heet, maar er zijn ook koude exemplaren.
Vergeet bovendien niet dat het proces van het maken van back-upkopieën zelf meestal niet eindigt met het maken van één back-upkopie, en dat er een vrij groot aantal kopieën kan zijn. Daarom is het noodzakelijk om onderscheid te maken tussen volledige back-ups, d.w.z. degenen die onafhankelijk van andere back-ups kunnen worden hersteld, evenals differentiële (incrementeel, differentieel, decrementeel, enz.) kopieën - kopieën die niet onafhankelijk kunnen worden hersteld en waarvoor het voorlopige herstel van een of meer andere back-ups vereist is.
Differentiële incrementele back-ups zijn een poging om back-upopslagruimte te besparen. Er worden dus alleen gewijzigde gegevens uit de vorige back-up naar de back-upkopie geschreven.
Differentiële decrementele kopieën worden voor hetzelfde doel gemaakt, maar op een iets andere manier: er wordt een volledige back-upkopie gemaakt, maar alleen het verschil tussen de nieuwe kopie en de vorige wordt daadwerkelijk opgeslagen.
Afzonderlijk is het de moeite waard om het proces van back-up boven opslag te overwegen, wat de afwezigheid van opslag van duplicaten ondersteunt. Als u dus volledige back-ups erbovenop schrijft, worden alleen de verschillen tussen de back-ups daadwerkelijk geschreven, maar het proces van het herstellen van de back-ups zal vergelijkbaar zijn met het herstellen vanaf een volledige kopie en volledig transparant zijn.
Wat is de custodiet ipsos custode?
(Wie zal de wachters zelf bewaken? - lat.)
Het is erg vervelend als er geen reservekopieën zijn, maar nog veel erger als er wel een reservekopie gemaakt lijkt te zijn, maar bij het terugzetten blijkt dat deze niet meer terug te zetten is omdat:
- De integriteit van de brongegevens is aangetast.
- De back-upopslag is beschadigd.
- Herstel werkt erg langzaam; gegevens die gedeeltelijk zijn hersteld, kunt u niet gebruiken.
Een goed opgebouwd back-upproces moet rekening houden met dergelijke opmerkingen, vooral met de eerste twee.
De integriteit van de brondata kan op verschillende manieren worden gegarandeerd. De meest gebruikte zijn de volgende: a) het maken van snapshots van het bestandssysteem op blokniveau, b) het “bevriezen” van de status van het bestandssysteem, c) een speciaal blokapparaat met versieopslag, d) sequentiële opname van bestanden of blokken. Er worden ook controlesommen toegepast om ervoor te zorgen dat gegevens tijdens het herstel worden geverifieerd.
Opslagcorruptie kan ook worden gedetecteerd met behulp van controlesommen. Een aanvullende methode is het gebruik van gespecialiseerde apparaten of bestandssystemen waarin reeds opgenomen gegevens niet kunnen worden gewijzigd, maar nieuwe kunnen worden toegevoegd.
Om het herstel te versnellen, wordt dataherstel gebruikt met meerdere herstelprocessen - op voorwaarde dat er geen knelpunt is in de vorm van een langzaam netwerk of een langzaam schijfsysteem. Om de situatie met gedeeltelijk herstelde gegevens te omzeilen, kunt u het back-upproces opdelen in relatief kleine subtaken, die elk afzonderlijk worden uitgevoerd. Het wordt dus mogelijk om de prestaties consistent te herstellen en tegelijkertijd de hersteltijd te voorspellen. Dit probleem ligt meestal op het organisatievlak (SLA), dus we zullen hier niet in detail op ingaan.
Een expert op het gebied van specerijen is niet degene die ze aan elk gerecht toevoegt, maar degene die er nooit iets extra’s aan toevoegt.
-IN. Sinjavski
De praktijken met betrekking tot de software die door systeembeheerders wordt gebruikt, kunnen variëren, maar de algemene principes zijn op de een of andere manier nog steeds hetzelfde, met name:
- Het wordt sterk aanbevolen om kant-en-klare oplossingen te gebruiken.
- Programma’s moeten voorspelbaar werken, d.w.z. Er mogen geen ongedocumenteerde kenmerken of knelpunten zijn.
- Het instellen van elk programma moet zo eenvoudig zijn dat u niet elke keer de handleiding of het spiekbriefje hoeft te lezen.
- Indien mogelijk moet de oplossing universeel zijn, omdat servers kunnen sterk variëren in hun hardwarekenmerken.
Er zijn de volgende veelgebruikte programma's voor het maken van back-ups van blokapparaten:
- dd, bekend bij systeembeheerderveteranen, dit omvat ook soortgelijke programma's (dezelfde dd_rescue bijvoorbeeld).
- Hulpprogramma's die in sommige bestandssystemen zijn ingebouwd en die een dump van het bestandssysteem maken.
- Omnivore nutsvoorzieningen; bijvoorbeeld partclone.
- Eigen, vaak bedrijfseigen, beslissingen; bijvoorbeeld NortonGhost en hoger.
Voor bestandssystemen wordt het back-upprobleem gedeeltelijk opgelost met behulp van methoden die van toepassing zijn op blokapparaten, maar het probleem kan efficiënter worden opgelost door bijvoorbeeld:
- Rsync, een programma en protocol voor algemene doeleinden voor het synchroniseren van de status van bestandssystemen.
- Ingebouwde archiveringstools (ZFS).
- Archiveringstools van derden; de meest populaire vertegenwoordiger is teer. Er zijn anderen, bijvoorbeeld dar - een vervanging voor teer gericht op moderne systemen.
Het is de moeite waard om apart te vermelden over softwaretools om de gegevensconsistentie te garanderen bij het maken van back-upkopieën. De meest gebruikte opties zijn:
- Het bestandssysteem aankoppelen in de alleen-lezen-modus (ReadOnly), of het bestandssysteem bevriezen (freeze) - de methode is van beperkte toepasbaarheid.
- Het maken van snapshots van de status van bestandssystemen of blokkeerapparaten (LVM, ZFS).
- Het gebruik van tools van derden voor het organiseren van vertoningen, zelfs in gevallen waarin de voorgaande punten om een of andere reden niet kunnen worden geleverd (programma's zoals hotcopy).
- De copy-on-change-techniek (CopyOnWrite) is echter meestal gekoppeld aan het gebruikte bestandssysteem (BTRFS, ZFS).
Voor een kleine server moet u dus een back-upschema bieden dat aan de volgende vereisten voldoet:
- Gemakkelijk te gebruiken - er zijn geen speciale extra stappen vereist tijdens de werking, minimale stappen om kopieën te maken en te herstellen.
- Universeel - werkt op zowel grote als kleine servers; dit is belangrijk bij het uitbreiden van het aantal servers of bij schaalvergroting.
- Geïnstalleerd door een pakketbeheerder, of in een of twee commando's zoals "downloaden en uitpakken".
- Stabiel - er wordt een standaard of al lang bestaand opslagformaat gebruikt.
- Snel in het werk.
Aanvragers van degenen die min of meer aan de vereisten voldoen:
- rdiff-back-up
- rsnapshot
- boeren
- duplicatie
- dubbelhartigheid
- laat dup
- maar
- zback-up
- rustiek
- borgback-up
Als testbank zal een virtuele machine (gebaseerd op XenServer) met de volgende kenmerken worden gebruikt:
- 4 kernen 2.5 GHz,
- 16 GB RAM,
- 50 GB hybride opslag (opslagsysteem met caching op SSD 20% van de virtuele schijfgrootte) in de vorm van een aparte virtuele schijf zonder partitionering,
- 200 Mbit internetkanaal.
Bijna dezelfde machine zal worden gebruikt als backup-ontvangerserver, alleen met een harde schijf van 500 GB.
Besturingssysteem - Centos 7 x64: standaardpartitie, extra partitie wordt gebruikt als gegevensbron.
Laten we als initiële gegevens een WordPress-site nemen met 40 GB aan mediabestanden en een MySQL-database. Omdat virtuele servers sterk variëren qua kenmerken, en ook voor een betere reproduceerbaarheid, is dit het geval
servertestresultaten met behulp van sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 CPU-run
sysbench 1.1.0-18a9f86 (met gebundelde LuaJIT 2.1.0-beta3)
De test uitvoeren met de volgende opties:
Aantal threads: 4
Initialiseren van de generator voor willekeurige getallen vanaf de huidige tijd
Limiet voor priemgetallen: 20000
Werkthreads initialiseren…
Threads begonnen!
CPU snelheid:
gebeurtenissen per seconde: 836.69
Doorvoer:
gebeurtenissen/s (eps): 836.6908
verstreken tijd: 30.0039s
totaal aantal evenementen: 25104
Latentie (ms):
minuut: 2.38
gemiddelde: 4.78
maximum: 22.39
95e percentiel: 10.46
som: 119923.64
Threads eerlijkheid:
gebeurtenissen (gem/stddev): 6276.0000/13.91
uitvoeringstijd (gem./stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=lees geheugenrun
sysbench 1.1.0-18a9f86 (met gebundelde LuaJIT 2.1.0-beta3)
De test uitvoeren met de volgende opties:
Aantal threads: 4
Initialiseren van de generator voor willekeurige getallen vanaf de huidige tijd
Voer een geheugensnelheidstest uit met de volgende opties:
blokgrootte: 1KiB
totale grootte: 102400MiB
werking: lezen
reikwijdte: mondiaal
Werkthreads initialiseren…
Threads begonnen!
Totaal aantal bewerkingen: 50900446 (1696677.10 per seconde)
49707.47 MiB overgedragen (1656.91 MiB/sec)
Doorvoer:
gebeurtenissen/s (eps): 1696677.1017
verstreken tijd: 30.0001s
totaal aantal evenementen: 50900446
Latentie (ms):
minuut: 0.00
gemiddelde: 0.00
maximum: 24.01
95e percentiel: 0.00
som: 39106.74
Threads eerlijkheid:
gebeurtenissen (gem/stddev): 12725111.5000/137775.15
uitvoeringstijd (gem./stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=schrijf geheugenrun
sysbench 1.1.0-18a9f86 (met gebundelde LuaJIT 2.1.0-beta3)
De test uitvoeren met de volgende opties:
Aantal threads: 4
Initialiseren van de generator voor willekeurige getallen vanaf de huidige tijd
Voer een geheugensnelheidstest uit met de volgende opties:
blokgrootte: 1KiB
totale grootte: 102400MiB
werking: schrijven
reikwijdte: mondiaal
Werkthreads initialiseren…
Threads begonnen!
Totaal aantal bewerkingen: 35910413 (1197008.62 per seconde)
35068.76 MiB overgedragen (1168.95 MiB/sec)
Doorvoer:
gebeurtenissen/s (eps): 1197008.6179
verstreken tijd: 30.0001s
totaal aantal evenementen: 35910413
Latentie (ms):
minuut: 0.00
gemiddelde: 0.00
maximum: 16.90
95e percentiel: 0.00
som: 43604.83
Threads eerlijkheid:
gebeurtenissen (gem/stddev): 8977603.2500/233905.84
uitvoeringstijd (gem./stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (met gebundelde LuaJIT 2.1.0-beta3)
De test uitvoeren met de volgende opties:
Aantal threads: 4
Initialiseren van de generator voor willekeurige getallen vanaf de huidige tijd
Extra vlaggen voor openen van bestanden: (geen)
128 bestanden, elk 8 MiB
1GiB totale bestandsgrootte
Blokgrootte 4KiB
Aantal IO-verzoeken: 0
Lees-/schrijfverhouding voor gecombineerde willekeurige IO-test: 1.50
Periodieke FSYNC ingeschakeld, waarbij fsync() elke 100 verzoeken wordt aangeroepen.
Aanroepen van fsync() aan het einde van de test, ingeschakeld.
Synchrone I/O-modus gebruiken
Willekeurige r/w-test uitvoeren
Werkthreads initialiseren…
Threads begonnen!
Doorvoer:
lezen: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
schrijven: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latentie (ms):
minuut: 0.00
gemiddelde: 0.27
maximum: 18.01
95e percentiel: 1.08
som: 238469.45
Deze notitie begint groot
serie artikelen over back-up
- Back-up, deel 1: Waarom back-up nodig is, een overzicht van methoden, technologieën
- Back-up Deel 2: Op rsync gebaseerde back-uptools bekijken en testen
- Back-up Deel 3: Herzien en testen van dubbelheid, dubbelheid, deja-dup
- 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
Bron: www.habr.com