Vragen over het maken back-ups van Azure-bestanden

Raadpleeg de ondersteuningsmatrix voor back-ups van Azure-bestandsshares om ervoor te zorgen dat het opslagaccount deel uitmaakt van een van de ondersteunde opslagaccounttypen. Het is ook mogelijk dat het opslagaccount dat u zoekt, al is beveiligd of geregistreerd bij een andere kluis. Maak de registratie van het opslagaccount van de kluis ongedaan om het opslagaccount in andere kluizen te detecteren voor beveiliging.

Controleer of de Azure-bestandsshare al in dezelfde Recovery Services-kluis wordt beveiligd en of de bestandsshare onlangs wellicht is verwijderd.

De huidige back-upoplossing van Azure Files bewaart momentopnamen in hetzelfde opslagaccount als de back-upbestandsshare. Als het opslagaccount wordt verwijderd, gaan al uw momentopnamen verloren. Om uw account te beschermen tegen onbedoeld verwijderen, wordt in Azure Backup een verwijderingsvergrendeling voor het opslagaccount gebruikt. Dit betekent dat geautoriseerde gebruikers een resource nog steeds kunnen lezen en wijzigen, maar dat ze deze niet kunnen verwijderen. De vergrendeling beperkt ook het verwijderen van bestandsshares onder het opslagaccount. Daarom krijgt u bescherming tegen het onbedoeld verwijderen van zowel het opslagaccount als de bestandsshares.

Ja. Beveiliging van Azure-bestandsshares die zijn verbonden met synchronisatiegroepen is ingeschakeld.

Wanneer u een back-up probeert te maken, selecteert u een opslagaccount om bestandsshares in het account te detecteren, wordt het opslagaccount geregistreerd bij de kluis waaruit dit gebeurt. Als u ervoor kiest om de bestandsshares met een andere kluis te beveiligen, moet u de registratie van het gekozen opslagaccount bij deze kluis ongedaan maken.

Als het opslagaccount al is geregistreerd bij een kluis of andere bestandsshares in het opslagaccount, wordt beveiligd met behulp van een kluis, krijgt u geen optie om het te wijzigen. Alle bestandsshares in een opslagaccount kunnen alleen worden beveiligd door dezelfde kluis. Als u de kluis wilt wijzigen, moet u de beveiliging stoppen voor alle bestandsshares in het opslagaccount vanuit de verbonden kluis, de registratie van het opslagaccount opheffen en vervolgens een andere kluis kiezen voor beveiliging.

Ja. U moet de beveiliging op de bestandsshare echter stoppen vanuit de verbonden kluis, de registratie van dit opslagaccount opheffen en vervolgens beveiligen tegen een andere kluis.

Nee Alle bestandsshares in een opslagaccount kunnen alleen in dezelfde kluis worden beveiligd.

U kunt op elk moment maximaal 200 momentopnamen voor een bestandsshare hebben. Deze limiet is inclusief momentopnamen die zijn gemaakt met Azure Backup zoals gedefinieerd in uw beleid. Als uw back-ups mislukken nadat de limiet is bereikt, verwijdert u momentopnamen op aanvraag voor succesvolle toekomstige back-ups.

In de volgende tabel wordt het aantal momentopnamen uitgelegd volgens de configuratie van het back-upbeleid:

Als de bestandsshare de status Voorlopig verwijderd heeft, moet u eerst de bestandsshare ongedaan maken om de herstelbewerking uit te voeren. Met de ongedaan makende bewerking wordt de bestandsshare in de actieve status gebracht, waar u naar elk gewenst moment kunt herstellen. Als u wilt weten hoe u de bestandsshare ongedaan kunt maken, gaat u naar deze koppeling of raadpleegt u het script Bestandsshare ongedaan maken. Als de bestandsshare definitief wordt verwijderd, kunt u de inhoud en momentopnamen niet meer herstellen.

Ja. Als u Back-upgegevens behouden hebt gekozen toen u met de beveiliging stopte, kunt u vanaf alle bestaande herstelpunten iets terugzetten.

Als een doorlopende hersteltaak wordt geannuleerd, stopt het herstelproces en worden alle bestanden hersteld vóór de annulering, blijft u op de geconfigureerde bestemming (oorspronkelijke of alternatieve locatie) zonder terugdraaiacties.

Als een herstelpunt niet wordt vermeld, moet het zijn verlopen. U wordt aangeraden de retentie te controleren die is geconfigureerd in het back-upbeleid om inzicht te hebben in de retentieduur voor herstelpunten van uw back-upbestandsshare.

Ja. Raadpleeg de gedetailleerde documentatie hier.

In de huidige back-upoplossing voor Azure Files worden er geen gegevens overgebracht naar de kluis en worden momentopnamen bewaard in hetzelfde opslagaccount als de back-upbestandsshare. De gegevens die in MB worden overgedragen, zijn dus 0.

De instelling Opslagreplicatie van de kluis is niet relevant voor Back-up van Azure Files. Dit komt doordat de huidige oplossing is gebaseerd op momentopnamen en er geen gegevens naar de kluis worden overgebracht. Momentopnamen worden opgeslagen in hetzelfde opslagaccount als de back-upbestandsshare en worden daarom gerepliceerd volgens de replicatie-instelling van het opslagaccount.

Alle momentopnamen die door Azure Backup zijn gemaakt, kunnen worden geopend door momentopnamen te bekijken in de portal, PowerShell of CLI. Zie Overzicht van momentopnamen van shares voor Azure Files voor meer informatie over momentopnamen van Azure Files.

Zodra een bestandsshare naar een ander abonnement is verplaatst, wordt deze beschouwd als een nieuwe bestandsshare door Azure Backup. Dit zijn de aanbevolen stappen:

Scenario: Stel dat u een bestandsshare FS1 in abonnement S1 hebt en dat deze is beveiligd met behulp van de V1-kluis . Nu wilt u uw bestandsshare verplaatsen naar abonnement S2.

1. Verplaats het gewenste opslagaccount en de bestandsshare (FS1) naar het andere abonnement (S2).
2. Activeer in de V1-kluis de stopbeveiliging met verwijdergegevensbewerking voor FS1.
3. Hef de registratie van het opslagaccount op dat als host fungeert voor FS1 vanuit de V1-kluis.
4. Configureer de back-up voor FS1, nu verplaatst naar S2, met een kluis (V2) in het S2-abonnement.

Houd er rekening mee dat na het opnieuw configureren van de back-up met V2 de momentopnamen die zijn gemaakt met V1 niet meer worden beheerd door Azure Backup. U moet deze momentopnamen dus handmatig verwijderen op basis van uw vereisten.

Ja, u kunt uw back-upbestandsshare verplaatsen naar een andere resourcegroep. U moet de back-up voor de bestandsshare echter opnieuw configureren, omdat deze wordt behandeld als een nieuwe resource door Azure Backup. Ook worden de momentopnamen die zijn gemaakt voordat de verplaatsing van de resourcegroep is gemaakt, niet meer beheerd door Azure Backup. U moet deze momentopnamen dus handmatig verwijderen op basis van uw vereisten.

Raadpleeg de ondersteuningsmatrix voor meer informatie over maximale retentie. Azure Backup voert een realtime berekening uit van het aantal momentopnamen wanneer u de retentiewaarden invoert tijdens het configureren van back-upbeleid. Zodra het aantal momentopnamen dat overeenkomt met uw gedefinieerde retentiewaarden groter is dan 200, wordt in de portal een waarschuwing weergegeven waarin u wordt verzocht uw retentiewaarden aan te passen. Dit is dus dat u niet de limiet overschrijdt van het maximum aantal momentopnamen dat door Azure Files wordt ondersteund voor een bestandsshare op elk moment.

Wanneer u een dagelijks back-upbeleid wijzigt in GFS-beleid (wekelijks/maandelijks/jaarlijks bewaren), is het gedrag als volgt:

• Bewaarperiode: Als u wekelijkse/maandelijkse/jaarlijkse retentie toevoegt als onderdeel van het wijzigen van het beleid, worden alle toekomstige herstelpunten die zijn gemaakt als onderdeel van de geplande back-up, gelabeld volgens het nieuwe beleid. Alle bestaande herstelpunten worden nog steeds beschouwd als dagelijkse herstelpunten en worden dus niet gelabeld als wekelijks/maandelijks/jaarlijks.

• Momentopnamen en herstelpunten opschonen:

  • Als de dagelijkse bewaarperiode wordt verlengd, wordt de vervaldatum van de bestaande herstelpunten bijgewerkt op basis van de dagelijkse bewaarwaarde die is geconfigureerd in het nieuwe beleid.
  • Als de dagelijkse retentie wordt verminderd, worden de bestaande herstelpunten en momentopnamen gemarkeerd voor verwijdering in de volgende opschoontaak volgens de dagelijkse bewaarwaarde die is geconfigureerd in het nieuwe beleid en vervolgens verwijderd.

Hier volgt een voorbeeld van hoe dit werkt:

Bestaand beleid [P1]

Nieuw beleid [Gewijzigd P1]

Impact

1. De vervaldatum van bestaande herstelpunten wordt aangepast op basis van de dagelijkse bewaarwaarde van het nieuwe beleid: dat wil wel 50 dagen. Elk herstelpunt dat ouder is dan 50 dagen, wordt dus gemarkeerd voor verwijdering.

2. De bestaande herstelpunten worden niet gelabeld als wekelijks/maandelijks/jaarlijks op basis van nieuw beleid.

3. Alle toekomstige back-ups worden geactiveerd volgens het nieuwe schema: dat wil gezegd om 19:00 uur.

4. De vervaldatum van alle toekomstige herstelpunten wordt afgestemd op het nieuwe beleid.

Wanneer een nieuw beleid wordt toegepast op bestandsshares, worden alle toekomstige geplande back-ups gemaakt volgens de planning die is geconfigureerd in het gewijzigde beleid. De retentie van alle bestaande herstelpunten wordt uitgelijnd op basis van de nieuwe retentiewaarden die zijn geconfigureerd. Dus als de retentie is verlengd, worden bestaande herstelpunten gemarkeerd om te worden bewaard volgens het nieuwe beleid. Als de retentie is verminderd, worden ze gemarkeerd voor opschoning in de volgende opschoontaak en vervolgens verwijderd.

Hier volgt een voorbeeld van hoe dit werkt:

Bestaand beleid [P2]

Nieuw beleid [Gewijzigd P2]

Gevolgen van wijziging

1. De vervaldatum van bestaande dagelijkse herstelpunten wordt afgestemd op de nieuwe dagelijkse bewaarwaarde (10 dagen). Elk dagelijks herstelpunt dat ouder is dan 10 dagen, wordt dus verwijderd.

2. De vervaldatum van bestaande wekelijkse herstelpunten wordt afgestemd op de nieuwe wekelijkse bewaarwaarde (twee weken). Elk wekelijks herstelpunt dat ouder is dan twee weken, wordt dus verwijderd.

3. De maandelijkse herstelpunten worden alleen gemaakt als onderdeel van toekomstige back-ups op basis van de nieuwe beleidsconfiguratie.

4. De vervaldatum van alle toekomstige herstelpunten wordt afgestemd op het nieuwe beleid.

Het duurkenmerk helpt bij het bepalen van de tijdstempel voor de laatste back-up van de dag.

Als de begintijd bijvoorbeeld 'x AM' is en de duur 'y uur' is, worden de back-ups gepland tussen 'x AM' en (x AM + y uur) op basis van het schemakenmerk dat in het beleid is gedefinieerd. Met dit kenmerk kunt u ervoor zorgen dat back-ups alleen worden geactiveerd tijdens uw werkuren wanneer er regelmatig updatebewerkingen zijn op de inhoud van de bestandsshare; Als u dus meerdere momentopnamen maakt, worden gegevens beschermd tegen onbedoelde wijzigingen.

U hebt bijvoorbeeld een beleid gemaakt met de volgende configuratie:

• Begintijd: 9:00 uur
• Schema: om de 4 uur
• Duur: 12 uur

Op basis van deze waarden wordt het back-upvenster berekend als 9:00 – (9:00 uur + 12 uur), dat wil gezegd 09:00 tot 19:00 uur. Daarom worden alle back-ups gepland in dit venster.

De eerste back-up van de dag wordt geactiveerd op de begintijd die wordt vermeld in het beleid, dat wil gezegd 9:00 uur en het schema bepaalt het tijdsverschil tussen opeenvolgende back-ups, dat wil gezegd 4 uur. Met deze berekening is uw back-upschema: 9:00, 13:00 (9:00 uur), 15:00 (1 PM + 4 uur) en 9:00 (15:00 uur+ 4 uur).

Omdat de eindtijd van het back-upvenster dat we hebben berekend 9:00 uur was, zou er na deze tijd geen back-up worden geactiveerd.

Deze fout treedt op als u een planning hebt opgegeven die groter is dan de duur. U hebt bijvoorbeeld de begintijd geconfigureerd als 9:00 uur, een planning van 6 uur en een duur van 4 uur. In dit scenario is de enige tijd waarop de back-uptaak kan worden geactiveerd 9:00 uur, omdat de volgende back-uptijd van 03:00 (9:00 uur + 6 uur) buiten het back-upvenster valt: 9:00 – 13:00 uur (9:00 uur+ 4 uur).

U kunt dit oplossen door uw planning of duur aan te passen of de dagelijkse frequentie te selecteren in plaats van per uur.

Deze fout treedt op als de begin- en eindtijd van het back-upvenster, bepaald op basis van het back-upschema en de duur, op twee verschillende dagen valt.

U hebt bijvoorbeeld een beleid geconfigureerd met de volgende parameters:

• Schema: om de 4 uur
• Begintijd: 12:00 uur
• Duur: 15 uur

Op basis van deze configuratie is het back-upvenster: 12:00 – 3:00 (12:00 + 15 uur). Omdat de begin- en eindtijden op twee verschillende dagen vallen, raden we u aan de begin- of duur aan te passen om ervoor te zorgen dat ze zich op dezelfde dag bevinden.

Stel dat u de begintijd wijzigt in 6:00 uur in de bovenstaande configuratie. Het back-upvenster is nu 06:00 – 19:00 (06:00 + 15 uur). Dit is een ondersteunde configuratie.

Wanneer u overschakelt van dagelijkse naar uurfrequentie , is het gedrag als volgt:

• Bewaarperiode: Als u wekelijkse/maandelijkse/jaarlijkse retentie toevoegt als onderdeel van het wijzigen van het beleid, worden alle toekomstige herstelpunten die zijn gemaakt als onderdeel van de geplande back-up, gelabeld volgens het nieuwe beleid. Alle bestaande herstelpunten worden nog steeds beschouwd als dagelijkse herstelpunten; Ze worden dus niet gelabeld als wekelijks/maandelijks/jaarlijks.

• Momentopnamen en herstelpunten opschonen:

  • Als de dagelijkse bewaarperiode wordt verlengd, wordt de vervaldatum van de bestaande dagelijkse herstelpunten bijgewerkt op basis van de dagelijkse bewaarwaarde die is geconfigureerd in het nieuwe beleid.
  • Als de dagelijkse retentie wordt verminderd, worden de bestaande dagelijkse herstelpunten en momentopnamen gemarkeerd voor verwijdering in de volgende opschoontaak volgens de dagelijkse bewaarwaarde die is geconfigureerd in het nieuwe beleid en vervolgens verwijderd.

Nee, het verwijderen van het opslagaccount wordt niet geblokkeerd door een lease op momentopnamen.

U wordt aangeraden de beveiliging tegen te houden met het verwijderen van gegevens op de bestandsshare waarvan een back-up is gemaakt.

Na deze bewerking brengt Azure Backup de lease vrij en verwijdert u alle momentopnamen. Vervolgens kunt u de bestandsshare verwijderen.

Nee, Azure Backup neemt alleen een lease op de momentopnamen die worden gemaakt na de release van deze mogelijkheid.

Nee Als u een bestandsshare met geleasede momentopnamen verwijdert, is de lease niet aanwezig wanneer de bestandsshare ongedaan wordt gemaakt.

Ja, u kunt bestandsshares in een opslagaccount in dezelfde Recovery Services-kluis beveiligen met verschillende back-upbeleidsregels.

Volgende stappen

• Problemen oplossen tijdens het maken van back-ups van Azure-bestandsshares