Vandaag presenteer ik u graag opnieuw nuttige tips van mijn collega Evgeniy Ivanov, teamleider van het technische ondersteuningsteam van Veeam. Dit keer deelde Zhenya aanbevelingen voor het werken met back-ups en replica's. Ik hoop dat ze je zullen helpen veelvoorkomende fouten te voorkomen, en dat je replica's en back-ups indien nodig nooit een 'zwakke schakel' zullen zijn in het herstelproces.

Dus welkom bij kat.

In mijn vorige статье we hebben gekeken hoe we de belasting van componenten van de back-upinfrastructuur kunnen optimaliseren en hebben gekeken naar veelvoorkomende configuratiefouten. Laten we verder gaan met een ander belangrijk onderwerp: een goede voorbereiding en implementatie van herstel. We zullen het ook analyseren met behulp van echte voorbeelden waarmee het technische ondersteuningsteam heeft kunnen werken.

Back-up zonder restaurant - geld in de put

We worden regelmatig gecontacteerd door gebruikers die zich in soortgelijke moeilijke situaties bevinden: het is noodzakelijk om te herstellen vanaf een back-up, maar wanneer ze dit proberen, stuiten mensen op een probleem dat voor hen onoplosbaar is. En dit probleem is niet een gebrek aan back-up, CryptoLocker-activiteit of iets dergelijks. Dit is “gewoon” onvoldoende aandacht voor het testen van back-ups en replica’s op herstelbaarheid. Veel mensen concentreren zich vaak uitsluitend op het proces van het maken van een back-up, waarbij ze vergeten dat het simpelweg hebben van een back-up geen wondermiddel is voor mogelijke problemen. U moet begrijpen dat restauratie een heel ander proces is, dat zijn eigen kenmerken heeft, en dat moet worden gecontroleerd en getest voordat het in productie wordt genomen. Hier zijn enkele illustratieve voorbeelden:

Een gebruiker heeft te maken gehad met een storing van een kritieke virtuele machine van 20 TB. Downtime is uiteraard onaanvaardbaar en de beheerder start het onmiddellijke herstelproces (VM instant recovery) - na 5 minuten is de machine actief. Maar we herinneren ons dat deze status van de machine slechts tijdelijk kan worden gebruikt: deze moet worden gemigreerd naar de productiedatastore. En in dit voorbeeld, zo bleek, lieten de infrastructuurmogelijkheden het niet toe om binnen een redelijke tijd 20 TB aan gegevens te kopiëren. In de instellingen van het onmiddellijke herstelproces werd geselecteerd om wijzigingen op schijf op te slaan C: Veeam Backup & Replication-server (in tegenstelling tot vSphere-snapshot) - hierdoor raakte de vrije schijfruimte uiteraard snel vol. Tegen de tijd dat de gebruiker contact opnam met de ondersteuning, had de VM wijzigingen die niet konden worden genegeerd. Dat wil zeggen, we hebben een situatie waarin het onmogelijk is om het proces van onmiddellijk herstel van een kritieke machine snel af te ronden - hoe kunnen we de gegevens opslaan?
Eerlijk gezegd herinner ik me door de jaren heen niet meer alle details van de finale, maar ik herinner me dat we uiteindelijk niets briljants hebben bedacht. Klanten van hun kant hebben dit probleem in ieder geval opgelost door de C: schijf uit de reserves uit te breiden, de belangrijkste bestanden te kopiëren en pas daarna de VM uit te zetten en op die manier te migreren. Over het algemeen gebeurde er geen wonder.
De infrastructuur van de gebruiker draaide op één domeincontroller en alle componenten van Veeam Backup & Replication waren geconfigureerd met behulp van DNS. Ja, ja, dat klopt, je hebt het goed gehoord. Er waren niet minder dan honderd opties voor de ontwikkeling van evenementen, maar in werkelijkheid verliep alles zo: mensen planden onderhoud en besloten over te stappen op een replica van hun domeincontroller. Ze gebruikten een geplande schakelaar, die in dergelijke situaties over het algemeen wordt aanbevolen. In de eerste fase ging alles prima, maar in de tweede fase werd de bron-VM kortstondig uitgeschakeld om de resterende gegevens over te dragen. Uiteraard mislukte de omschakeling meteen omdat DNS niet meer werkte.
Gelukkig konden we de situatie hier oplossen door de replica van vSphere handmatig in te schakelen (het is eigenlijk niet aan te raden om dit zelf te doen, zoals je in het volgende voorbeeld zult zien). Maar zoals u begrijpt, werd het onderhoudsproces onderbroken en vertraagd. Bovendien moesten we de hostnamen handmatig in het bestand invoeren C:WindowsSystem32driversetchosts op de Veeam Backup & Replication-server om de juistheid tijdens het terugschakelen te garanderen.
Een andere klant had een volledige back-upinfrastructuur opgebouwd rond tapedrives, met slechts korte reeksen bestanden op schijf. Toen ze een aantal bestanden van een grote bestandsserver moesten herstellen, ontdekten ze dat geen van beide machines als secundaire opslagplaats voor tapeherstel kon worden gebruikt, omdat geen enkele machine over voldoende vrije ruimte beschikte. (U kunt rechtstreeks lezen over herstel vanaf magneetband en het gebruik van een aanvullende opslagplaats hier (voorlopig in het Engels)).

Ik denk dat de gebruikers in alle drie de voorbeelden als het ware gefascineerd waren door illusies - ze gingen ervan uit dat als de back-up succesvol was, er geen problemen zouden zijn met het herstel. Maar dit is, zoals u begrijpt, lang niet altijd het geval, en daarom moet u zich net zo zorgvuldig voorbereiden op herstel als op back-up. Om te beginnen is het de moeite waard om te studeren gebruikershandleiding, die vrij gedetailleerde informatie bevat over verschillende soorten herstel. Aan het begin van elke paragraaf worden de vereisten, voorbereidende acties en mogelijke beperkingen vermeld. Een beschrijving van het herstel vanaf magneetbanden of vanaf hardwareopslag-snapshots kunt u vinden in de documentatiesecties en in onze Lidwoord op Habré. Bovendien worden de stappen ter voorbereiding op het herstellen van applicatieobjecten met Veeam Explorers beschreven in de sectie 'Planning en voorbereiding'. gidsen voor elk van de instrumenten. Ik raad u aan ze aandachtig te lezen - dit zal u helpen het systeem indien nodig goed voor te bereiden op herstel. Instructies voor het herstellen van een SQL Server-database worden in het Russisch gegeven: hier.

Waarom zou ik niet met replica's van de vSphere-console werken?

In theorie zijn Veeam-replica's gewone virtuele machines, waarmee het logisch lijkt om ermee te werken met behulp van de vSphere-tools, in het bijzonder de vSphere-client. We raden dit echter niet aan, en dit is de reden: het overstappen naar een replica in Veeam Backup & Replication is een nogal ingewikkeld proces, waarbij strikt opeenvolgende stappen nodig zijn (zodat als er iets gebeurt, u een stap terug kunt draaien) en de juiste uiteindelijke acties - kijk maar naar de afbeelding die het proces illustreert:

Als u besluit een replica van de vSphere-client in te schakelen, zult u in de toekomst waarschijnlijk een aantal problemen tegenkomen:

Het mechanisme voor het overstappen naar een replica van Veeam Backup & replication (weergegeven in het diagram) werkt niet meer voor deze machine.
De gegevens in de Veeam Backup-database komen niet overeen met de werkelijke status van de VM. In het ergste geval moet u de database bewerken om deze te repareren.
Gegevensverlies is zelfs mogelijk, zoals in dit voorbeeld: de gebruiker schakelde de replica handmatig in de vSphere-client in en besloot ermee verder te werken. Na enige tijd merkte hij dat de replica nog steeds werd weergegeven in de Veeam Backup & Replication-console en besloot hij deze te verwijderen omdat hij niet nodig was. Klik er met de rechtermuisknop op en geef het commando "Verwijderen van schijf". Veeam Backup & Replication verwijderde de replica onmiddellijk van de schijf, die even al volop in gebruik was als reguliere VM en de noodzakelijke en nuttige data bevatte.

Natuurlijk zijn er situaties waarin u nog steeds een replica van de vSphere-client moet inschakelen. In de regel zijn dit gevallen waarin de Veeam-server is uitgeschakeld en de replica met vertraging moet worden ingeschakeld. Maar als alles in orde is met de Veeam-server, moet je met replica's vanaf de console werken.

U mag ook geen replica's verwijderen met behulp van de vSphere-client. Veeam Backup & Replication zal zich niet bewust zijn van deze wijziging, wat kan leiden tot fouten en verouderde data. Als u een replica niet langer nodig heeft, verwijdert u deze via de Veeam-console en niet als VM uit de vSphere-client. Zo beschikt u altijd over een actuele lijst met replica’s.

"Oh" - wees voorzichtig, updates!

We bedoelen hier uiteraard updates voor hypervisors en diverse applicaties waarvan een back-up wordt gemaakt met Veeam. Als je ze bekijkt vanuit het perspectief van het werken met Veeam Backup & Replication, kunnen updates worden onderverdeeld in 2 categorieën: groot, serieus, met veel veranderingen - en kleine.

Laten we eerst naar de eerste categorie kijken.

De belangrijkste updates zijn de updates die gericht zijn op de hypervisor. Voordat u een dergelijke update installeert, moet u ervoor zorgen dat deze wordt ondersteund door Veeam Backup & Replication. Deze updates introduceren veel wijzigingen in de bibliotheken en API's die Veeam Backup & Replication gebruikt, dus de code van Veeam Backup & Replication moet worden bijgewerkt en grondig getest om deze officieel te ondersteunen.

We moeten ook in gedachten houden dat VMware bijvoorbeeld geen geavanceerde toegang biedt tot de nieuwste versies van vSphere voor softwarefabrikanten, dus Veeam-ontwikkelaars en testers ontvangen een nieuwe versie op hetzelfde moment als de rest van de vooruitstrevende mensheid - daarom zijn er is meestal een vertraging tussen de VMware-release en een bepaalde tijd officieel aangekondigde ondersteuning. Het aantal en de verscheidenheid aan vereiste wijzigingen zijn zodanig dat de kans klein is dat ze in een eenvoudige hotfix kunnen worden ondergebracht - en officiële ondersteuning wordt in de regel aangekondigd samen met de release van de releaseversie van Veeam Backup & Replication.

Als gevolg hiervan doet zich dat ongemakkelijke moment voor waarop, na de release van een nieuwe versie van vSphere, het aantal verzoeken om technische ondersteuning sterk toeneemt, omdat gebruikers hals over kop haasten om de nieuwe versie te installeren, en hun back-ups uiteraard onmiddellijk niet meer werken . Wij, de technische ondersteuning van Veeam, moeten gebruikers uitleggen wat ze precies verkeerd hebben gedaan, hen vragen om terug te draaien (indien mogelijk) of ingewikkelde manieren bedenken om uit de impasse te komen. Zorg er daarom voor dat u, voordat u een serieuze update installeert, de compatibiliteit ervan controleert met de software die u gebruikt, ik smeek u!

Al het bovenstaande is ook van toepassing op applicaties waarvan u een back-up maakt en die u verwacht te herstellen met Veeam. De Veeam Explorers-lijn met tools bevat ook een lijst met ondersteunde versies van de bijbehorende applicaties, die bij elke release van Veeam Backup & Replication wordt bijgewerkt. Lees daarom het relevante gedeelte opnieuw voordat u een nieuwe versie van uw applicatie installeert (of het nu Exchange, Oracle of SharePoint is). Veeam Explorers-documentatie.

Tot de tweede categorie, d.w.z. Onder kleine updates versta ik bijvoorbeeld nieuwe versies van VMware Tools, cumulatieve Exchange-updates, vSphere-beveiligingsupdates, etc. Doorgaans voeren ze geen grote wijzigingen door en in de meeste gevallen ondervindt Veeam Backup & Replication er geen problemen mee. (Daarom zijn er geen openbare aankondigingen over officiële ondersteuning in het product voor hen.) In onze praktijk zijn er echter gevallen geweest waarin dergelijke updates de gebruikelijke gang van zaken zo aanzienlijk veranderden dat ze leidden tot fouten in de werking van Veeam Backup & Replicatie. In dergelijke situaties proberen Veeam-technici, nadat ze het probleem hebben bevestigd, snel een hotfix uit te brengen.

Voor degenen die technisch Engels sprekenAls je op de hoogte wilt blijven van waar engineers aan werken en waar systeemarchitecten en technische ondersteuningsspecialisten mee te maken krijgen, raad ik je aan je te abonneren op onze forums. Elke week verschijnt er een nieuwsbrief "Word from Gostev" voor zijn abonnees. De Echte Gostev. Daarin vertelt Anton Gostev, hoofd van de afdeling productmanagement, over recent gevonden problemen (en niet alleen aan Veeam-kant), plannen voor nieuwe versies en nieuws uit de IT-wereld. Als u meer informatie nodig heeft, kunt u de forumonderwerpen bestuderen - als een van de klanten na een update een probleem heeft met de werking van het product, heeft hij er hoogstwaarschijnlijk al over op het forum geschreven.

Zoals u begrijpt kunnen patches en updates niet alleen tot problemen leiden bij back-ups, maar ook bij de applicaties waarvoor deze back-ups worden gemaakt. En hier zullen virtuele laboratoria – Veeam DataLabs – u helpen. U heeft waarschijnlijk wel eens gehoord van SureBackup, een functionaliteit die is ontworpen om back-ups te verifiëren. Het is precies gebaseerd op het gebruik van DataLabs, waarbij een geïsoleerde omgeving wordt gecreëerd waarin u met name updates kunt testen voordat u ze in productie installeert. Ik raad je ten zeerste aan dit te doen – je bespaart jezelf een hoop zenuwcellen. En als iemand SureBackup nog niet kent, raad ik aan het te lezen de documentatie.

Ik denk dat dit alles is wat ik heb voor vandaag, bedankt voor je aandacht!