Back-up is niet een van de trendy technologieën waar elk strijkijzer over roept. Het moet gewoon in een serieus gezelschap zijn, dat is alles. We maken back-ups van enkele duizenden servers in onze bank - dit is een complexe, interessante taak, waarvan sommige subtiliteiten, evenals typische misvattingen over back-ups, gewoon willen worden verteld.
Ik werk al bijna 20 jaar aan dit onderwerp, waarvan de laatste 2 jaar bij Promsvyazbank. Helemaal aan het begin van de training deed ik back-ups bijna handmatig, met scripts die simpelweg bestanden kopieerden. Toen verschenen handige tools in Windows: het hulpprogramma Robocopy om bestanden voor te bereiden en NT Backup om te kopiëren. En pas toen kwam de tijd voor gespecialiseerde software, voornamelijk Veritas Backup Exec, dat nu Symantec Backup Exec heet. Ik ben dus al heel lang bekend met back-ups.
Eenvoudig gezegd is back-up het met een zekere regelmaat bewaren van een kopie van gegevens (virtuele machines, applicaties, databases en bestanden). Elk geval manifesteert zich meestal als een hardware- of logische fout en resulteert in gegevensverlies. Het doel van een back-upsysteem is om het verlies van informatie te verminderen. Een hardware storing is bijvoorbeeld een storing van de server of storage waar de database zich bevindt. Logisch - dit is het verlies of de wijziging van een deel van de gegevens, ook vanwege de menselijke factor: ze hebben per ongeluk een tabel, bestand verwijderd, een krom script gelanceerd voor uitvoering. Er zijn ook regelgevende vereisten voor het bewaren van een bepaald type informatie voor een lange periode, bijvoorbeeld tot meerdere jaren.
Het meest typische gebruik van back-ups is het herstellen van een opgeslagen kopie van databases voor de implementatie van verschillende testsystemen, klonen voor ontwikkelaars.
Er zijn een paar typische mythen rond back-up die al lang geleden moeten worden verdreven. Hier zijn de meest bekende van hen.
Mythe 1. Back-up is lange tijd slechts een kleine functie geweest binnen beveiligings- of opslagsystemen
Back-upsystemen blijven nog steeds een aparte klasse van oplossingen en zijn zeer onafhankelijk. Ze hebben te veel werk te doen. In feite vormen ze de laatste verdedigingslinie als het gaat om gegevensintegriteit. Dus back-up werkt in zijn eigen tempo, volgens zijn eigen schema. Er wordt dagelijks een rapport gegenereerd voor de servers, er zijn gebeurtenissen die fungeren als triggers voor het monitoringsysteem.
Bovendien stelt het rolmodel van toegang tot het back-upsysteem u in staat een deel van de bevoegdheid te delegeren aan beheerders van doelsystemen om back-ups te beheren.
Mythe 2. Als er een RAID is, is er geen back-up meer nodig.
Ongetwijfeld zijn RAID-arrays en gegevensreplicatie een goede manier om informatiesystemen te beschermen tegen hardwarestoringen, en als u een stand-byserver heeft, kunt u er snel naar overschakelen voor het geval de hoofdmachine uitvalt.
Van de logische fouten die zijn gemaakt door de gebruikers van het systeem, redden redundantie en replicatie niet. Hier is een standby-server voor terugschrijven - ja, deze kan helpen als er een fout wordt gedetecteerd voordat deze is gesynchroniseerd. En als het moment wordt gemist? Alleen een tijdige back-up helpt hier. Als u weet dat de gegevens gisteren zijn gewijzigd, kunt u het systeem herstellen naar eergisteren en de benodigde gegevens eruit halen. Gezien het feit dat logische fouten de meest voorkomende zijn, blijft de goede oude back-up een bewezen en noodzakelijk hulpmiddel.
Mythe 3. Een back-up is iets dat eens per maand wordt gedaan.
De back-upfrequentie is een configureerbare instelling die voornamelijk afhangt van uw back-upsysteemvereisten. Het is heel goed mogelijk om gegevens te vinden die bijna nooit veranderen en niet bijzonder belangrijk zijn, hun verlies zal niet kritiek zijn voor het bedrijf.
Er kan inderdaad één keer per maand een back-up van worden gemaakt en zelfs minder vaak. Maar meer kritieke gegevens worden vaker opgeslagen, afhankelijk van de RPO-indicator (Recovery Point Objective), die het toegestane gegevensverlies bepaalt. Dit kan een keer per week, een keer per dag of zelfs meerdere keren per uur zijn. We hebben deze transactielogboeken van het DBMS.
Wanneer systemen commercieel in gebruik worden genomen, moet back-updocumentatie worden goedgekeurd, waarin de hoofdlijnen, de updateprocedure, de procedure voor het herstellen van het systeem, de procedure voor het opslaan van back-ups en dergelijke worden weergegeven.
Mythe 4. Het aantal kopieën groeit voortdurend en neemt alle toegewezen ruimte volledig in beslag.
Back-ups hebben een beperkte bewaartermijn. Het heeft bijvoorbeeld geen zin om gedurende het jaar alle 365 dagelijkse back-ups op te slaan. In de regel is het acceptabel om dagelijkse kopieën gedurende 2 weken te bewaren, waarna ze worden vervangen door nieuwe, en de versie die als eerste in de maand is gemaakt, blijft voor lange tijd opgeslagen. Het wordt op zijn beurt ook voor een bepaalde tijd bewaard - elk exemplaar heeft een leven lang.
Er is bescherming tegen gegevensverlies. De regel is van toepassing: voordat een back-up wordt verwijderd, moet de volgende worden gevormd. Daarom worden de gegevens niet verwijderd als de back-up niet is voltooid, bijvoorbeeld omdat de server niet beschikbaar is. Niet alleen termijnen worden gerespecteerd, maar ook het aantal exemplaren in de set wordt gecontroleerd. Als het systeem is ontworpen om twee volledige back-ups te hebben, zullen er altijd twee zijn en wordt de oude alleen verwijderd als een nieuwe derde met succes is geschreven. De groei van het volume dat wordt ingenomen door het back-uparchief hangt dus alleen samen met de groei van de hoeveelheid beschermde gegevens en is niet afhankelijk van de tijd.
Mythe 5. Back-up gestart - alles bleef hangen
Het is beter om dit te zeggen: als alles hangt, groeien de handen van de beheerder niet vanaf daar. Over het algemeen zijn de prestaties van een back-up afhankelijk van veel factoren. Bijvoorbeeld over de snelheid van het back-upsysteem zelf: hoe snel zijn schijfopslag, tapebibliotheken. Van de snelheid van de servers van het back-upsysteem: of ze tijd hebben om gegevens te verwerken, compressie en deduplicatie uit te voeren. En ook op de snelheid van de communicatielijnen tussen de client en de server.
De back-up kan naar een of meer streams gaan, afhankelijk van of het systeem waarvan de back-up wordt gemaakt multithreading ondersteunt. Met Oracle DBMS kunt u bijvoorbeeld meerdere threads opgeven, afhankelijk van het aantal beschikbare processors, totdat de overdrachtssnelheid de limiet van de netwerkbandbreedte bereikt.
Als u een back-up van een groot aantal threads probeert te maken, bestaat de kans dat een actief systeem wordt overbelast, het zal echt langzamer gaan werken. Daarom wordt het optimale aantal threads gekozen om voldoende prestaties te garanderen. Als zelfs de geringste afname van de prestaties van cruciaal belang is, dan is er een uitstekende optie wanneer de back-up niet wordt uitgevoerd vanaf een gevechtsserver, maar vanaf de kloon - stand-by in databaseterminologie. Dit proces start het hoofdbesturingssysteem niet op. Gegevens kunnen via meer streams worden opgehaald, aangezien de server niet wordt gebruikt voor onderhoud.
Bij grote organisaties wordt voor het back-up systeem een apart netwerk aangelegd zodat de back-up geen invloed heeft op de productie. Daarnaast mag het verkeer niet via het netwerk, maar via het SAN verlopen.
We proberen de belasting ook in de tijd te spreiden. Back-ups worden meestal buiten kantooruren gemaakt: 's nachts, in het weekend. Ze draaien ook niet allemaal tegelijk. Back-ups van virtuele machines zijn een speciaal geval. Het proces heeft praktisch geen effect op de prestaties van de machine zelf, dus de back-up kan overdag worden gespreid en 's nachts niet alles uitstellen. Er zijn veel subtiliteiten, als u met alles rekening houdt, heeft back-up geen invloed op de prestaties van systemen.
Mythe 6. Een back-upsysteem gelanceerd - dat is fouttolerantie voor jou
Vergeet nooit dat een back-upsysteem de laatste verdedigingslinie is, wat betekent dat er nog vijf systemen voor moeten staan die zorgen voor de continuïteit, hoge beschikbaarheid en rampenbestendigheid van de IT-infrastructuur en bedrijfsinformatiesystemen.
In de hoop dat de back-up alle gegevens zal herstellen en de verbroken service snel zal verhogen, is het niet waard. Gegevensverlies vanaf het moment van back-up tot het moment van falen is gegarandeerd en gegevens kunnen enkele uren (of dagen, als je geluk hebt) naar een nieuwe server worden geüpload. Daarom is het logisch om volwaardige fouttolerante systemen te creëren zonder alles naar een back-up te verplaatsen.
Mythe 7. Ik heb een keer een back-up gemaakt en gecontroleerd of deze werkt. Het blijft alleen om naar de logboeken te kijken
Dit is een van de meest schadelijke mythen, waarvan je de vervalsing pas tijdens het incident beseft. Succesvolle back-uplogboeken zijn geen garantie dat alles echt is verlopen zoals het hoort. Het is belangrijk om het opgeslagen exemplaar vooraf te controleren op inzetbaarheid. Dat wil zeggen, start het herstelproces in een testomgeving en bekijk het resultaat.
En een beetje over het werk van de systeembeheerder
In de handmatige modus heeft niemand lange tijd gegevens gekopieerd. Moderne SRK's kunnen van bijna alles een back-up maken, je moet het alleen goed instellen. Als er een nieuwe server is toegevoegd, stelt u beleid in: selecteer de inhoud waarvan u een back-up wilt maken, geef opslagopties op en pas het schema toe.
Tegelijkertijd is er nog steeds veel werk vanwege het uitgebreide serverpark, waaronder databases, mailsystemen, virtuele machineclusters en fileshares zowel op Windows als Linux/Unix. Medewerkers die het back-upsysteem draaiende houden zitten niet stil.
Ter ere van de vakantie wens ik alle beheerders veel zenuwen, duidelijkheid van bewegingen en eindeloze ruimte voor het opslaan van back-ups!
Bron: www.habr.com