{"id":33622,"date":"2019-10-31T21:53:47","date_gmt":"2019-10-31T18:53:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/veeam-backup-replication-poleznye-sovety-po-obespecheniyu-zhiznesposobnosti-bekapov-i-replik\/"},"modified":"2019-10-31T21:53:47","modified_gmt":"2019-10-31T18:53:47","slug":"veeam-backup-replication-poleznye-sovety-po-obespecheniyu-zhiznesposobnosti-bekapov-i-replik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/veeam-backup-replication-poleznye-sovety-po-obespecheniyu-zhiznesposobnosti-bekapov-i-replik","title":{"rendered":"Veeam Backup & Replication: nuttige tips voor het waarborgen van de levensvatbaarheid van back-ups en replica's","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vandaag presenteer ik met veel plezier opnieuw nuttige tips van mijn collega Evgeny Ivanov, teamleider van de technische ondersteuning van Veeam. Dit keer heeft Zhenya aanbevelingen gedeeld voor het werken met back-ups en replica's. Ik hoop dat ze je helpen typische fouten te vermijden, zodat je replica's en back-ups nooit de 'zwakke schakel' in het herstelproces zullen zijn, mocht dat nodig zijn. <\/p>\n

Dus, welkom onder de motorkap.<\/p>\n

\"Veeam
\n<\/a><\/noindex>
\nIn mijn vorige artikel<\/a><\/noindex> bekeken we hoe we de belasting op de componenten van de back-upinfrastructuur konden optimaliseren en behandelden we typische configuratiefouten. Laten we nu overstappen naar een ander belangrijk onderwerp \u2013 een goede voorbereiding en uitvoering van herstel. Dit zullen we ook aan de hand van echte voorbeelden doen waarmee het technische ondersteuningsteam heeft gewerkt.<\/p>\n

Back-up zonder herstel is geld weggooien<\/h1>\n

\nWe ontvangen regelmatig verzoeken van gebruikers die in soortgelijke lastige situaties verkeren: ze moeten een herstel uit een back-up uitvoeren, maar stuiten op een probleem dat voor hen onoplosbaar lijkt. En dit probleem is helemaal niet dat er geen back-up is, dat CryptoLocker actief is of iets dergelijks. Het is 'slechts' een gebrek aan aandacht voor het controleren van back-ups en replica's op hun herstelbaarheid. Velen concentreren zich vaak uitsluitend op het proces van back-up maken, terwijl ze vergeten dat het simpelweg hebben van een back-up geen garantie biedt tegen mogelijke problemen. Het is belangrijk te begrijpen dat herstel een heel ander proces is, met zijn eigen kenmerken, dat altijd gecontroleerd en getest moet worden voordat het in productie gaat. Hier zijn enkele sprekende voorbeelden:<\/p>\n

    \n
  1. Bij een gebruiker deed zich een uitval voor van een kritieke virtuele machine van 20 TB. Stilstand is uiteraard onaanvaardbaar en de admin start het proces voor directe herstelling (VM instant recovery) \u2013 binnen 5 minuten is de machine weer operationeel. Maar we herinneren ons dat deze staat van de machine slechts tijdelijk kan worden gebruikt \u2013 hij moet absoluut naar de productie-datastore worden gemigreerd. En in dit geval bleek dat de mogelijkheden van de infrastructuur niet toestonden om 20 TB gegevens in een redelijke tijd te kopi\u00ebren. Bij de instellingen van het instant recovery-proces was gekozen om wijzigingen op de schijf op te slaan. Van:<\/i> Veeam Backup & Replication-servers (in tegenstelling tot de vSphere-snapshot) \u2013 het gevolg hiervan was dat de schijfruimte snel vol raakte. Tegen de tijd dat de gebruiker ondersteuning zocht, waren er wijzigingen op de VM die niet genegeerd konden worden. We hebben dus een situatie waarin het niet mogelijk was om snel het proces van directe herstel van de kritische machine af te ronden \u2013 hoe kunnen we hier de gegevens redden?\n

    Om eerlijk te zijn, ik herinner me door de jaren heen de details van de afloop niet meer, maar ik weet nog dat we uiteindelijk niets geniaals verzonnen hebben. De klanten probeerden aan hun kant het probleem op te lossen door de schijf C: uit de reserves uit te breiden, kopieerden de belangrijkste bestanden en schakelden daarna de VM uit om zo te migreren. Kortom, er gebeurde geen wonder.<\/li>\n

  2. In de infrastructuur van de gebruiker werkte \u00e9\u00e9n domeincontroller, en alle componenten van Veeam Backup & Replication waren ingesteld met behulp van DNS. Ja, dat klopt, je hebt het goed gehoord. Er waren honderden scenario\u2019s mogelijk, maar de realiteit verliep als volgt: de mensen planden onderhoud en besloten over te schakelen naar de replica van hun domeincontroller. Ze gebruikten een geplande overschakeling, wat in dergelijke situaties wordt aanbevolen. In het eerste stadium verliep alles goed, maar in het tweede stadium werd de oorspronkelijke VM kort uitgeschakeld om de resterende gegevens over te brengen. Uiteraard voltooide het overschakelcommando zich meteen met een fout, omdat DNS niet meer werkte.\n

    Gelukkig konden we de situatie hier onder controle krijgen door de replica handmatig vanuit vSphere in te schakelen (over het algemeen wordt aanbevolen om deze operatie niet zelf uit te voeren, zoals je in het volgende voorbeeld zult zien). Maar zoals je begrijpt, werd het onderhoudsproces onderbroken en uitgesteld. Bovendien moesten we handmatig de hostnamen in het bestand C:WindowsSystem32driversetchosts<\/i> op de Veeam Backup & Replication-server invoeren om de juistheid bij de terugschakeling te waarborgen.<\/li>\n

  3. Bij een andere klant was de hele infrastructuur voor gegevensback-up opgebouwd rond magnetische tapeopslag, terwijl op de schijf slechts korte ketens van bestanden werden opgeslagen. Toen ze een aantal bestanden van een grote bestandenserver moesten herstellen, bleek dat geen enkele machine kon worden gebruikt als hulprepository voor herstel vanaf tape, omdat er op geen enkele voldoende vrije ruimte beschikbaar was. (Meer informatie over herstel vanaf magnetische tape direct en met behulp van een hulprepository is beschikbaar) hier<\/a><\/noindex> (tijdelijk in het Engels).<\/li>\n<\/ol>\n

    \nIk denk dat in alle drie de voorbeelden de gebruikers, zo te zeggen, gevangen waren in illusies \u2013 ze veronderstelden dat als de back-up succesvol was, er ook geen problemen bij het herstel zouden zijn. Zoals je begrijpt, is dat echter lang niet altijd zo, en daarom moet je je net zo goed voorbereiden op herstel als op de back-up. Als eerste is het raadzaam om de gebruikershandleiding<\/a><\/noindex>, waarin behoorlijk gedetailleerde informatie over verschillende soorten herstel te vinden is. Aan het begin van elke paragraaf worden de vereisten, voorbereidingsacties en mogelijke beperkingen opgesomd. In de documentatie en in onze artikelen<\/a><\/noindex> op Habr kan je beschrijvingen vinden over het herstel vanaf magnetische tapes of uit hardware snapshots van de opslag. Bovendien zijn de acties ter voorbereiding van het herstel van applicatie-objecten met behulp van Veeam Explorers beschreven in de sectie \u2018Planning and preparation\u2019 (planning en voorbereiding) handleiding<\/a><\/noindex> voor elk van de tools. Ik raad je aan om deze zorgvuldig door te nemen \u2013 dit zal je helpen om het systeem goed voor te bereiden op herstel in geval van nood. In het Russisch zijn er instructies voor het herstellen van SQL Server-databases beschikbaar hier<\/a><\/noindex>.<\/p>\n

    Waarom moet je niet werken met replica's vanuit de vSphere-console?<\/h1>\n

    \nIn principe zijn Veeam-replicas gewone virtuele machines, waarmee het logisch lijkt om te werken met behulp van de vSphere-hulpmiddelen, met name de vSphere-client. Toch raden we dit af, en hier is waarom: overstappen op een replica in Veeam Backup & Replication is een behoorlijk ingewikkeld proces dat een strikte volgorde van stappen vereist (zodat je in geval van problemen een stap terug kunt gaan) en correcte afsluitende acties - kijk maar eens naar de afbeelding die het proces illustreert:<\/p>\n

    \"Veeam
    \n
    \nAls je van plan bent om de replica vanuit de vSphere-client in te schakelen, dan verwacht je in de toekomst waarschijnlijk een aantal problemen:<\/p>\n

      \n
    1. Het mechanisme voor het overschakelen naar de replica vanuit Veeam Backup & replication (zoals weergegeven in het diagram) zal voor deze machine niet meer werken.<\/li>\n
    2. Gegevens in de Veeam Backup-database komen mogelijk niet overeen met de werkelijke toestand van de VM. In het slechtste geval moet de database worden bewerkt om dit te repareren.<\/li>\n
    3. Er is zelfs een risico op gegevensverlies, zoals in dit voorbeeld: een gebruiker schakelde handmatig de replica in via de vSphere-client en besloot verder te gaan met het werken met deze replica. Na een tijdje merkte hij op dat de replica nog steeds in de console van Veeam Backup & Replication werd weergegeven en besloot deze te verwijderen omdat hij deze niet meer nodig had. Hij klikte er met de rechtermuisknop op en gaf de opdracht \u00abDelete from disk\u00bb<\/i>. Veeam Backup & Replication verwijderde onmiddellijk de replica van de schijf, die, laten we wel wezen, al in gebruik was als een gewone VM en waardevolle gegevens bevatte.<\/li>\n<\/ol>\n

      \nZeker, er zijn situaties waarin je de replica toch vanuit de vSphere-client moet inschakelen - doorgaans wanneer de Veeam-server is uitgeschakeld en de replica met enige vertraging moet worden ingeschakeld. Maar als er niets met de Veeam-server aan de hand is, dan moet je met replica's werken vanuit de console.<\/p>\n

      Het is ook niet verstandig om replica's te verwijderen met behulp van de vSphere-client. Veeam Backup & Replication blijft in het ongewisse over een dergelijke wijziging, wat kan leiden tot fouten en verouderde gegevens. Als je de replica niet meer nodig hebt, verwijder deze dan via de console van Veeam, en niet als een VM vanuit de vSphere-client. Op die manier heb je altijd een actuele lijst van replica's. <\/p>\n

      \u00abO\u00bb \u2014 voorzichtig, updates!<\/h1>\n

      \nHier hebben we het natuurlijk over updates voor hypervisors en diverse applicaties die worden geback-upt met Veeam. Als we ze bekijken vanuit het perspectief van Veeam Backup & Replication, kunnen deze updates grofweg worden onderverdeeld in twee categorie\u00ebn: grote, ingrijpende updates die veel veranderingen met zich meebrengen \u2013 en kleinere.<\/p>\n

      Laten we eerst de eerste categorie bekijken. <\/p>\n

      De belangrijkste updates zijn die welke zijn bedoeld voor de hypervisor. Voordat je zo'n update installeert, moet je er zeker van zijn dat deze wordt ondersteund door Veeam Backup & Replication. Zulke updates brengen veel veranderingen aan in de bibliotheken en API-interface die door Veeam Backup & Replication worden gebruikt, daarom is het noodzakelijk om de code van Veeam Backup & Replication bij te werken en grondig te testen om officieel ondersteuning te kunnen aankondigen. <\/p>\n

      Je moet er ook rekening mee houden dat, bijvoorbeeld, VMware geen vroege toegang biedt tot de nieuwste versies van vSphere voor softwareontwikkelaars, zodat Veeam-ontwikkelaars en -testers de nieuwe versie gelijktijdig ontvangen met de rest van het vooruitstrevende publiek \u2013 daarom duurt het meestal enige tijd tussen de release van VMware en de offici\u00eble aankondiging van ondersteuning. Het aantal en de diversiteit van de noodzakelijke wijzigingen is zo groot dat het onwaarschijnlijk is dat deze allemaal in een simpele hotfix kunnen worden ondergebracht \u2013 en offici\u00eble ondersteuning wordt doorgaans aangekondigd tegelijk met de releaseversie van Veeam Backup & Replication. <\/p>\n

      Uiteindelijk is er dat ongemakkelijke moment wanneer na de lancering van een nieuwe versie van vSphere het aantal aanvragen bij de technische ondersteuning abrupt toeneemt, omdat gebruikers zich haastig haasten om de nieuwe versie te installeren, en hun backups natuurlijk onmiddellijk niet meer werken. Wij \u2013 de Veeam-ondersteuning \u2013 moeten de gebruikers uitleggen wat ze verkeerd hebben gedaan, hen vragen om terug te rollen (indien mogelijk) of ingewikkelde oplossingen bedenken om uit de impasse te komen. Controleer daarom altijd de compatibiliteit van een belangrijke update met de software die je gebruikt voordat je deze installeert, ik vraag je dat echt!<\/b><\/p>\n

      Alles wat hierboven is gezegd, geldt ook voor de applicaties die je back-upt en waarvan je verwacht deze te herstellen met Veeam. De reeks tools van Veeam Explorers heeft ook een lijst van ondersteunde versies van de bijbehorende applicaties, die met elke release van Veeam Backup & Replication wordt aangevuld. Daarom is het belangrijk om de bijbehorende sectie te lezen v\u00f3\u00f3r de installatie van een nieuwe versie van je applicatie \u2013 of dat nu Exchange, Oracle of SharePoint is. documentatie van Veeam Explorers<\/a><\/noindex>.<\/p>\n

      Onder de tweede categorie, dat wil zeggen kleine updates, reken ik bijvoorbeeld nieuwe versies van VMware Tools, cumulatieve updates van Exchange, beveiligingsupdates van vSphere, enzovoorts. Over het algemeen brengen deze geen ernstige wijzigingen met zich mee, en in de meeste gevallen ondervindt Veeam Backup & Replication hier geen problemen mee. (Daarom zijn er geen publieke aankondigingen over offici\u00eble ondersteuning in het product voor dergelijke updates.) Echter, in onze praktijk waren er gevallen waarin zulke updates de gang van zaken zo aanzienlijk veranderden dat dit leidde tot fouten in de werking van Veeam Backup & Replication. In zulke situaties proberen de ingenieurs van Veeam, na bevestiging van het probleem, snel een hotfix uit te brengen.<\/p>\n

      Voor degenen die technische Engels beheersen<\/b>Als je op de hoogte wilt blijven van waar de ingenieurs aan werken en met welke problemen systeemarchitecten en technische ondersteuning mee te maken krijgen, raad ik aan je aan te melden voor onze forums<\/a><\/noindex>. Wekelijks verschijnt er een nieuwsbrief voor abonnees met de titel \u201cWord from Gostev\u201d, geschreven door TheRealGostev<\/a><\/noindex>. Hierin vertelt Anton Gostev, die het product management-team leidt, over recent ontdekte problemen (en niet alleen aan de kant van Veeam), plannen voor nieuwe versies en nieuws uit de IT-wereld. Als je meer informatie nodig hebt, kun je de onderwerpen op het forum doorlezen \u2013 als er bij een klant een probleem wordt ontdekt met het product na een update, heeft hij dat waarschijnlijk al op het forum geschreven.<\/p>\n

      Zoals je weet, kunnen patches en updates niet alleen problemen met back-ups veroorzaken, maar ook met de applicaties waarvoor deze back-ups zijn gemaakt. Hier komen virtuele laboratoria van pas \u2014 Veeam DataLabs. Je hebt vast wel gehoord van de functionaliteit SureBackup, die bedoeld is voor de verificatie van back-ups. Dit is gebaseerd op het gebruik van DataLabs, waarbij een ge\u00efsoleerde omgeving wordt gecre\u00eberd waarin je onder andere updates kunt testen voordat je ze in productie neemt. Ik raad ten zeerste aan dit te doen \u2014 je bespaart jezelf veel zenuwcellen. En als iemand nog niet weet over SureBackup, raad ik aan om het te lezen. documentatie<\/a><\/noindex>.<\/p>\n

      Dat is het voor vandaag, bedankt voor je aandacht!<\/p>\n

      Wat nog meer te lezen<\/h1>\n

      \nArtikelen op Habr:<\/p>\n