Best practices voor herstel na noodgevallen met Azure File Sync

Voor Azure File Sync zijn er drie belangrijke aandachtspunten voor herstel na noodgevallen: hoge beschikbaarheid, gegevensbescherming/back-up en gegevensredundantie. In dit artikel wordt elk gebied behandeld en kunt u bepalen welke configuratie u moet gebruiken voor uw eigen oplossing voor herstel na noodgevallen.

In een Azure File Sync-implementatie bevat het cloudeindpunt altijd een volledige kopie van uw gegevens, terwijl de on-premises server kan worden weergegeven als wegwerpcache van uw gegevens. In het geval van een noodgeval aan de serverzijde kunt u herstellen door een nieuwe server in te richten, de Azure File Sync-agent erop te installeren en deze in te stellen als een nieuw servereindpunt.

Vanwege de hybride aard werken sommige traditionele strategieën voor serverback-up en herstel na noodgevallen niet met Azure File Sync. Voor een geregistreerde server biedt Azure File Sync geen ondersteuning voor:

Waarschuwing

Het uitvoeren van een van deze acties kan leiden tot problemen met gesynchroniseerde of verbroken gelaagde bestanden die uiteindelijk leiden tot gegevensverlies. Als u een van deze acties hebt uitgevoerd, neemt u contact op met ondersteuning voor Azure om ervoor te zorgen dat uw implementatie in orde is.

• Schijfstations (volume) overdragen/klonen van de ene server naar de andere terwijl het servereindpunt nog steeds actief is
• Herstellen vanuit een back-up van een besturingssysteem
• Het besturingssysteem van een server klonen naar een andere server
• Terugkeren naar een eerder controlepunt voor virtuele machines
• Gelaagde bestanden herstellen van een on-premises back-up (van derden) naar het servereindpunt

Hoge beschikbaarheid

Er zijn twee verschillende strategieën die u kunt gebruiken om hoge beschikbaarheid voor uw on-premises server te bereiken. U kunt een failovercluster configureren of een stand-byserver configureren. De beslissingsfactor tussen beide configuraties is hoeveel u bereid bent te investeren in uw systeem, en als het minimaliseren van de tijdsduur van uw systeem uitvalt in het geval van een noodgeval, is die extra kosten waard.

Voor een failovercluster hoeft u geen speciale stappen uit te voeren om Azure File Sync te gebruiken. Voor een stand-byserver moet u de volgende configuraties maken:

Gebruik een secundaire server met verschillende servereindpunten die worden gesynchroniseerd met dezelfde synchronisatiegroep als uw primaire server, maar schakel de toegang van eindgebruikers tot de server niet in. Hierdoor kunnen alle bestanden vanaf de primaire server worden gesynchroniseerd met de stand-byserver. U kunt overwegen om alleen lagen voor naamruimten in te schakelen, zodat alleen de naamruimte in eerste instantie wordt gedownload. Als uw primaire server mislukt, kunt u DFS-N gebruiken om de toegang van eindgebruikers tot uw stand-byserver snel opnieuw te configureren.

Gegevensbeveiliging/back-up

Het beveiligen van uw gegevens is een belangrijk onderdeel van een noodhersteloplossing. U kunt dit op twee manieren doen met uw Azure-bestandsshares: u kunt een back-up maken van uw gegevens in de cloud of on-premises. We raden u ten zeerste aan een back-up te maken van uw gegevens in de cloud, omdat uw cloudeindpunt een volledige kopie van uw gegevens bevat, terwijl servereindpunten mogelijk alleen een subset van uw gegevens bevatten.

Een back-up maken van uw gegevens in de cloud

U moet Azure Backup gebruiken als uw cloudback-upoplossing. Azure Backup verwerkt onder andere back-upplanning, retentie en herstelbewerkingen. Als u wilt, kunt u handmatig momentopnamen van shares maken en uw eigen plannings- en bewaaroplossing configureren, maar dit is niet ideaal. U kunt ook oplossingen van derden gebruiken om rechtstreeks een back-up te maken van uw Azure-bestandsshares.

Als er zich een noodgeval voordoet, kunt u herstellen vanuit een momentopname van een share. Dit is een tijdstip, een alleen-lezen kopie van uw bestandsshare. Omdat deze momentopnamen alleen-lezen zijn, worden ze niet beïnvloed door ransomware. Voor grote gegevenssets waarin herstelbewerkingen voor volledige shares lang duren, kunt u directe gebruikerstoegang tot de momentopname inschakelen, zodat gebruikers de gegevens die ze nodig hebben, naar hun lokale station kunnen kopiëren terwijl het herstellen is voltooid.

Momentopnamen worden rechtstreeks opgeslagen in uw Azure-bestandsshare, ongeacht of u ze handmatig maakt of als Azure Backup ze voor u neemt. U moet dus voorlopig verwijderen inschakelen om uw momentopnamen te beveiligen tegen onbedoeld verwijderen van uw bestandsshare.

Zie Back-up van Azure-bestandsshares voor meer informatie of neem contact op met uw back-upprovider om te zien of ze ondersteuning bieden voor het maken van back-ups van Azure-bestandsshares.

Een back-up maken van uw gegevens on-premises

Als u cloudlagen inschakelt, implementeert u geen on-premises back-upoplossing. Als opslag in cloudlagen is ingeschakeld, worden alleen een subset van uw gegevens lokaal op uw server opgeslagen en worden de rest van uw gegevens opgeslagen in uw cloudeindpunt. Afhankelijk van de back-upoplossing die u gebruikt voor een lokale back-up, zijn gelaagde bestanden:

• overgeslagen en geen back-up gemaakt (vanwege hun FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS kenmerk) of
• alleen een back-up als een gelaagd bestand en is mogelijk niet toegankelijk bij het herstellen vanwege wijzigingen in de liveshare of
• teruggehaald naar uw schijf, wat resulteert in hoge uitgaande kosten.

Als u besluit om een on-premises back-upoplossing te gebruiken, moet u back-ups uitvoeren op een server in de synchronisatiegroep met uitgeschakelde cloudlagen. Wanneer u een herstelbewerking uitvoert, gebruikt u de herstelopties op volume- of bestandsniveau. Bestanden die zijn hersteld met behulp van de optie herstellen op bestandsniveau, worden gesynchroniseerd met alle eindpunten in de synchronisatiegroep en bestaande bestanden worden vervangen door de versie die vanuit de back-up wordt hersteld. Herstelbewerkingen op volumeniveau vervangen geen nieuwere bestandsversies in het cloudeindpunt of andere servereindpunten.

Momentopnamen van Volume Shadow Copy Service (VSS), inclusief het tabblad Vorige versies , worden ondersteund op volumes waarvoor cloudlagen zijn ingeschakeld. Hiermee kunt u selfserviceherstel uitvoeren in plaats van te vertrouwen op een beheerder om herstelbewerkingen voor u uit te voeren. U moet echter eerdere versiecompatibiliteit inschakelen via PowerShell, waardoor de opslagkosten voor momentopnamen worden verhoogd. VSS-momentopnamen beschermen niet tegen rampen op het servereindpunt zelf, dus ze moeten alleen worden gebruikt naast back-ups aan de cloudzijde. Zie selfserviceherstel via vorige versies en VSS voor meer informatie.

Gegevensredundantie

Voeg een vorm van gegevensredundantie toe aan uw infrastructuur om een robuuste oplossing voor herstel na noodgevallen te garanderen. Er zijn vier redundantieaanbiedingen voor Azure Files: Lokaal redundante opslag (LRS), zone-redundante opslag (ZRS), geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS).

• Lokaal redundante opslag (LRS):met LRS wordt elk bestand drie keer opgeslagen in een Azure-opslagcluster. Zo wordt u beschermd tegen gegevensverlies door hardwarefouten, zoals een beschadigd schijfstation. Als een noodgeval, zoals brand of overstromingen, zich echter in het datacenter voordoet, kunnen alle replica's van een opslagaccount met LRS verloren gaan of onherstelbaar zijn.
• Zone-redundante opslag (ZRS):met ZRS worden drie kopieën van elk bestand opgeslagen, maar deze kopieën worden fysiek geïsoleerd in drie afzonderlijke opslagclusters in verschillende Azure-beschikbaarheidszones. Beschikbaarheidszones zijn unieke, fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Een schrijfbewerking naar opslag wordt pas geaccepteerd als deze naar de opslagclusters in alle drie de beschikbaarheidszones wordt geschreven.
• Geografisch redundante opslag (GRS):met GRS hebt u twee regio's: een primaire en secundaire regio. Bestanden worden drie keer opgeslagen in een Azure-opslagcluster in de primaire regio. Schrijfbewerkingen worden asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. GRS biedt zes kopieën van uw gegevens verspreid over twee Azure-regio's.
• Geografisch zone-redundante opslag (GZRS): Denk aan GZRS als ZRS, maar met geo-redundantie. Met GZRS worden bestanden drie keer opgeslagen in drie afzonderlijke opslagclusters in de primaire regio. Alle schrijfbewerkingen worden vervolgens asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio.

Voor een robuuste oplossing voor herstel na noodgevallen moeten de meeste klanten ZRS overwegen. ZRS voegt de minste extra kosten toe voor de extra voordelen van gegevensredundantie en is ook het naadloosst in het geval van een storing. Als het beleid of de wettelijke vereisten van uw organisatie georedundantie voor uw gegevens vereisen, kunt u GRS of GZRS overwegen.

Geografische redundantie

Als uw opslagaccount is geconfigureerd met GRS- of GZRS-replicatie, start Microsoft de failover van de opslagsynchronisatieservice als wordt beoordeeld dat de primaire regio gedurende lange tijd permanent onherstelbaar of niet beschikbaar is. Er is geen actie van u vereist in het geval van een noodgeval.

Hoewel u handmatig een failover van uw opslagsynchronisatieservice kunt aanvragen naar uw gekoppelde GRS- of GZRS-regio, raden we u aan dit niet buiten grootschalige regionale storingen uit te voeren, omdat het proces niet naadloos is en mogelijk extra kosten in rekening worden gebracht. Als u het proces wilt initiëren, opent u een ondersteuningsticket en vraagt u aan dat zowel uw Azure-opslagaccounts die uw Azure-bestandsshare bevatten als uw Opslagsynchronisatieservice een failover uitvoeren.

Waarschuwing

Neem contact op met de ondersteuning om uw opslagsynchronisatieservice aan te vragen, als u dit proces handmatig start. Als u probeert een nieuwe opslagsynchronisatieservice te maken met dezelfde servereindpunten in de secundaire regio, kunnen er extra gegevens in uw opslagaccount blijven, omdat de vorige installatie van Azure File Sync niet wordt opgeschoond.

Zodra er een failover plaatsvindt, schakelen servereindpunten automatisch over naar synchronisatie met het cloudeindpunt in de secundaire regio. De servereindpunten moeten echter worden afgestemd op de cloudeindpunten. Dit kan leiden tot bestandsconflicten, omdat de gegevens in de secundaire regio mogelijk niet worden opgepakt in de primaire regio.

Volgende stap

Meer informatie over back-ups van Azure-bestandsshares