Met deze opmerking rondt u de cyclus over back-up af. Er wordt ingegaan op de logische organisatie van een dedicated server (of VPS), handig voor back-up, en er wordt ook een mogelijkheid geboden om een server snel te herstellen vanaf een back-up zonder veel downtime in geval van een calamiteit.
Initiële gegevens
Een dedicated server heeft meestal minimaal twee harde schijven die dienen om een RAID-array (mirror) op het eerste niveau te organiseren. Dit is nodig om de server te kunnen blijven gebruiken als er één schijf uitvalt. Indien dit een reguliere dedicated server betreft, kan er eventueel een aparte hardware RAID-controller met actieve caching-technologie op SSD aanwezig zijn, zodat naast reguliere harde schijven ook één of meerdere SSD's aangesloten kunnen worden. Soms worden er dedicated servers aangeboden, waarbij de lokale schijven alleen SATADOM bevatten (kleine schijven, structureel een flashdrive aangesloten op een SATA-poort), of zelfs een gewone kleine (8-16GB) flashdrive aangesloten op een speciale interne poort, en de gegevens worden afkomstig van het opslagsysteem, verbonden via een speciaal opslagnetwerk (Ethernet 10G, FC, enz.), en er zijn speciale servers die rechtstreeks vanuit het opslagsysteem worden geladen. Ik zal dergelijke opties niet overwegen, omdat in dergelijke gevallen de taak van het maken van een back-up van de server soepel wordt overgedragen aan de specialist die het opslagsysteem onderhoudt; meestal zijn er verschillende eigen technologieën voor het maken van snapshots, ingebouwde deduplicatie en andere geneugten van de systeembeheerder , besproken in de vorige delen van deze serie. Het volume van de disk-array van een dedicated server kan enkele tientallen terabytes bereiken, afhankelijk van het aantal en de grootte van de schijven die op de server zijn aangesloten. Bij VPS zijn de volumes bescheidener: doorgaans niet meer dan 100GB (maar dat zijn er ook meer), en de tarieven voor zo’n VPS kunnen makkelijk duurder uitvallen dan de goedkoopste dedicated servers van dezelfde hoster. Een VPS heeft meestal één schijf, omdat daaronder een opslagsysteem (of iets hyperconverged) zit. Soms heeft een VPS meerdere schijven met verschillende eigenschappen, voor verschillende doeleinden:
- klein systeem - voor het installeren van het besturingssysteem;
- groot - opslag van gebruikersgegevens.
Wanneer u het systeem opnieuw installeert via het bedieningspaneel, wordt de schijf met gebruikersgegevens niet overschreven, maar wordt de systeemschijf volledig opnieuw gevuld. Ook in het geval van een VPS kan de hoster een knop aanbieden die een momentopname maakt van de status van de VPS (of schijf), maar als je je eigen besturingssysteem installeert of vergeet de gewenste dienst binnen de VPS te activeren, kunnen sommige van de gegevens kan nog steeds verloren gaan. Naast de knop wordt meestal een dienst voor gegevensopslag aangeboden, meestal zeer beperkt. Meestal is dit een account met toegang via FTP of SFTP, soms samen met SSH, met een uitgeklede shell (bijvoorbeeld rbash), of een beperking op het uitvoeren van opdrachten via geautoriseerde_sleutels (via ForcedCommand).
Een dedicated server is via twee poorten met een snelheid van 1 Gbps met het netwerk verbonden, soms kunnen dit kaarten zijn met een snelheid van 10 Gbps. VPS heeft meestal één netwerkinterface. Meestal beperken datacenters niet de netwerksnelheid binnen het datacenter, maar beperken ze wel de snelheid van de internettoegang.
De typische belasting van zo’n dedicated server of VPS is een webserver, een database en een applicatieserver. Soms kunnen er verschillende aanvullende hulpdiensten worden geïnstalleerd, ook voor een webserver of database: zoekmachine, mailsysteem, enz.
Een speciaal voorbereide server fungeert als ruimte voor het opslaan van back-upkopieën, we zullen er later meer in detail over schrijven.
Logische organisatie van het schijfsysteem
Als je een RAID-controller hebt, of een VPS met één schijf, en er zijn geen speciale voorkeuren voor de werking van het schijfsubsysteem (bijvoorbeeld een aparte snelle schijf voor de database), dan wordt alle vrije ruimte als volgt verdeeld: één partitie wordt gemaakt en er wordt een LVM-volumegroep bovenop gemaakt, er worden verschillende volumes in gemaakt: 2 kleine van dezelfde grootte, gebruikt als het rootbestandssysteem (een voor een gewijzigd tijdens updates voor de mogelijkheid van snel terugdraaien, het idee is overgenomen van de Calculate Linux-distributie), een andere is voor de swappartitie, de rest van de vrije ruimte is verdeeld in kleine volumes, gebruikt als het rootbestandssysteem voor volwaardige containers, schijven voor virtuele machines, bestanden systemen voor accounts in /home (elke account heeft zijn eigen bestandssysteem), bestandssystemen voor applicatiecontainers.
Belangrijke opmerking: volumes moeten volledig op zichzelf staand zijn, d.w.z. mogen niet afhankelijk zijn van elkaar of van het rootbestandssysteem. In het geval van virtuele machines of containers wordt dit punt automatisch waargenomen. Als dit applicatiecontainers of homedirectories zijn, moet u overwegen om de configuratiebestanden van de webserver en andere services zo te scheiden dat afhankelijkheden tussen de volumes zoveel mogelijk worden geëlimineerd. Elke site draait bijvoorbeeld vanaf zijn eigen gebruiker, de siteconfiguratiebestanden bevinden zich in de thuismap van de gebruiker, in de webserverinstellingen worden siteconfiguratiebestanden niet opgenomen via /etc/nginx/conf.d/.conf, en bijvoorbeeld /home//configs/nginx/*.conf
Als er meerdere schijven zijn, kunt u een softwarematige RAID-array maken (en de caching ervan op een SSD configureren, als daar behoefte en gelegenheid voor is), waarop u LVM kunt bouwen volgens de hierboven voorgestelde regels. Ook in dit geval kun je ZFS of BtrFS gebruiken, maar je moet hier goed over nadenken: beide vereisen een veel serieuzere benadering van bronnen, en bovendien is ZFS niet inbegrepen bij de Linux-kernel.
Ongeacht het gebruikte schema, het is altijd de moeite waard om vooraf de geschatte snelheid van het schrijven van wijzigingen naar schijven te schatten en vervolgens de hoeveelheid vrije ruimte te berekenen die wordt gereserveerd voor het maken van snapshots. Als onze server bijvoorbeeld gegevens schrijft met een snelheid van 10 megabytes per seconde en de grootte van de gehele data-array 10 terabytes is, kan de synchronisatietijd een dag bereiken (22 uur - dit is hoeveel zo'n volume zal worden overgedragen via het netwerk 1 Gbps) - het is de moeite waard om ongeveer 800 GB te reserveren. In werkelijkheid zal het cijfer kleiner zijn, je kunt het veilig delen door het aantal logische volumes.
Back-upopslagserverapparaat
Het belangrijkste verschil tussen een server voor het opslaan van back-upkopieën zijn de grote, goedkope en relatief trage schijven. Omdat moderne HDD's de limiet van 10TB op één schijf al hebben overschreden, is het noodzakelijk om bestandssystemen of RAID met checksums te gebruiken, omdat tijdens het opnieuw opbouwen van de array of het herstellen van het bestandssysteem (meerdere dagen!) de tweede schijf defect kan raken vanwege tot verhoogde belasting. Op schijven met een capaciteit tot 1TB was dit niet zo gevoelig. Voor de eenvoud van de beschrijving ga ik ervan uit dat de schijfruimte is verdeeld in twee delen van ongeveer gelijke grootte (opnieuw bijvoorbeeld met behulp van LVM):
- volumes die overeenkomen met de servers die worden gebruikt om gebruikersgegevens op te slaan (de laatst gemaakte back-up wordt daarop ter verificatie ingezet);
- volumes die worden gebruikt als BorgBackup-repository's (gegevens voor back-ups komen hier rechtstreeks terecht).
Het werkingsprincipe is dat voor elke server afzonderlijke volumes worden gemaakt voor de BorgBackup-repository's, waar gegevens van de gevechtsservers naartoe gaan. De opslagplaatsen werken in de alleen-toevoegen-modus, waardoor de mogelijkheid van het opzettelijk verwijderen van gegevens wordt geëlimineerd, en door deduplicatie en periodieke opschoning van opslagplaatsen van oude back-ups (er blijven jaarlijkse kopieën over, maandelijks voor het afgelopen jaar, wekelijks voor de laatste maand, dagelijks voor de vorige week, eventueel in speciale gevallen - elk uur voor de laatste dag: totaal 24 + 7 + 4 + 12 + jaarlijks - ongeveer 50 exemplaren voor elke server).
BorgBackup-repository's schakelen de alleen-toevoegen-modus niet in; in plaats daarvan wordt een ForcedCommand in .ssh/authorized_keys ongeveer als volgt gebruikt:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Het opgegeven pad bevat een wrapper-script bovenop borg, dat, naast het starten van het binaire bestand met parameters, bovendien het proces start van het herstellen van de back-upkopie nadat de gegevens zijn verwijderd. Om dit te doen, maakt het wrapperscript een tagbestand aan naast de overeenkomstige repository. De laatst gemaakte back-up wordt automatisch teruggezet op het overeenkomstige logische volume nadat het gegevensinvulproces is voltooid.
Met dit ontwerp kunt u periodiek onnodige back-ups opruimen en voorkomt u ook dat gevechtsservers iets op de back-upopslagserver verwijderen.
Back-upproces
De initiatiefnemer van de back-up is de dedicated server of VPS zelf, aangezien dit schema meer controle geeft over het back-upproces aan de kant van deze server. Eerst wordt er een momentopname gemaakt van de status van het actieve rootbestandssysteem, die wordt aangekoppeld en met behulp van BorgBackup naar de back-upopslagserver wordt geüpload. Nadat het vastleggen van gegevens is voltooid, wordt de momentopname ontkoppeld en verwijderd.
Als er een kleine database is (tot 1 GB voor elke site), wordt er een databasedump gemaakt, die wordt opgeslagen in het juiste logische volume, waar de rest van de gegevens voor dezelfde site zich bevindt, maar zo dat de dump wordt opgeslagen niet toegankelijk via de webserver. Als de databases groot zijn, moet u ‘hot’ gegevensverwijdering configureren, bijvoorbeeld met behulp van xtrabackup voor MySQL, of werken met WAL met archive_command in PostgreSQL. In dit geval wordt de database afzonderlijk van de sitegegevens hersteld.
Als containers of virtuele machines worden gebruikt, moet u qemu-guest-agent, CRIU of andere noodzakelijke technologieën configureren. In andere gevallen zijn aanvullende instellingen meestal niet nodig: we maken eenvoudigweg momentopnamen van logische volumes, die vervolgens op dezelfde manier worden verwerkt als een momentopname van de status van het rootbestandssysteem. Nadat de gegevens zijn opgenomen, worden de foto's verwijderd.
Verdere werkzaamheden worden uitgevoerd op de back-upopslagserver:
- de laatste back-up die in elke repository is gemaakt, wordt gecontroleerd,
- de aanwezigheid van een markeringsbestand wordt gecontroleerd, wat aangeeft dat het gegevensverzamelingsproces is voltooid,
- de gegevens worden uitgebreid naar het overeenkomstige lokale volume,
- het tagbestand wordt verwijderd
Serverherstelproces
Als de hoofdserver uitvalt, wordt een soortgelijke speciale server gelanceerd, die opstart vanaf een standaardimage. Hoogstwaarschijnlijk zal de download via het netwerk plaatsvinden, maar de datacentertechnicus die de server instelt, kan dit standaardimage onmiddellijk naar een van de schijven kopiëren. De download vindt plaats in het RAM, waarna het herstelproces begint:
- er wordt een verzoek gedaan om een blokapparaat via iscsinbd of een ander vergelijkbaar protocol te koppelen aan een logisch volume dat het rootbestandssysteem van de overleden server bevat; Omdat het rootbestandssysteem klein moet zijn, zou deze stap binnen enkele minuten voltooid moeten zijn. De bootloader is ook hersteld;
- de structuur van lokale logische volumes wordt opnieuw gemaakt, logische volumes worden gekoppeld vanaf de back-upserver met behulp van de dm_clone kernelmodule: het gegevensherstel begint en wijzigingen worden onmiddellijk naar lokale schijven geschreven
- er wordt een container gelanceerd met alle beschikbare fysieke schijven - de functionaliteit van de server is volledig hersteld, maar met verminderde prestaties;
- nadat de gegevenssynchronisatie is voltooid, worden de logische volumes van de back-upserver losgekoppeld, wordt de container uitgeschakeld en wordt de server opnieuw opgestart;
Na een herstart beschikt de server over alle gegevens die aanwezig waren op het moment dat de back-up werd gemaakt, en ook over alle wijzigingen die tijdens het herstelproces zijn aangebracht.
Andere artikelen in de serie
Back-up Deel 7: Conclusies
Ik nodig u uit om de voorgestelde optie in de reacties te bespreken, bedankt voor uw aandacht!
Bron: www.habr.com