Vragen over het maken back-ups van Azure-bestanden

Raadpleeg de ondersteuningsmatrix voor back-ups van Azure-bestands shares om te controleren of het opslagaccount tot een van de ondersteunde typen opslagaccounts behoort. Het is ook mogelijk dat Storage account dat u zoekt al is beveiligd of is geregistreerd bij een andere kluis. Maak de registratie van het opslagaccount bij de kluis ongedaan om het Storage in andere kluizen te vinden voor beveiliging.

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

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

Wanneer u een back-up probeert te maken, wordt Storage Storage account voor het ontdekken van bestands shares in het account geregistreerd bij de kluis van waaruit dit wordt gedaan. Als u ervoor kiest om de bestands shares met een andere kluis te beveiligen, moet u de registratie van het Storage account bij deze kluis ongedaan maken.

Als het opslagaccount al is geregistreerd bij een kluis of als andere bestands shares in het opslagaccount zijn beveiligd met behulp van een kluis, krijgt u geen optie om dit te wijzigen. Alle bestands shares in een opslagaccount kunnen alleen worden beveiligd door dezelfde kluis. Als u de kluis wilt wijzigen, moet u de beveiliging voor alle bestands shares in het opslagaccount vanuit de verbonden kluis stoppen, de registratie van het Storage-account ongedaan maken en vervolgens een andere kluis kiezen voor beveiliging.

Ja. U moet echter de beveiliging van de bestands share vanuit de verbonden kluis stoppen, de registratie van dit Storage-account ongedaan maken en deze vervolgens beveiligen vanuit 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 geslaagde toekomstige back-ups.

Als de bestands share de status 'soft deleted' heeft, moet u eerst het verwijderen van de bestands share verwijderen om de herstelbewerking uit te voeren. De bewerking voor het verwijderen van het verwijderen wordt de bestands share in de actieve status waar u kunt herstellen naar elk moment in de tijd. Als u wilt weten hoe u het verwijderen van uw bestands share kunt verwijderen, gaat u naar deze koppeling of bekijkt u Het script voor bestands delen verwijderen verwijderen. Als de bestands share permanent wordt verwijderd, kunt u de inhoud en momentopnamen niet 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 lopende herstelklus wordt geannuleerd, stopt het herstelproces en blijven alle bestanden die vóór de annulering zijn hersteld, op de geconfigureerde bestemming (oorspronkelijke of alternatieve locatie) zonder terugdraaien.

Ja. Raadpleeg hier de gedetailleerde documentatie.

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 bestands share met back-ups. De gegevens die in MB worden overgedragen, zijn dus 0.

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

Alle momentopnamen die door Azure Backup zijn gemaakt, zijn toegankelijk door momentopnamen te bekijken in de portal, PowerShell of CLI. Zie Overzicht van momentopnamen van Azure Files delen voor meer informatie over het maken van momentopnamen van Azure Files.

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

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

1. Verplaats het gewenste opslagaccount en de gewenste bestands share (FS1) naar het andere abonnement (S2).
2. Activeer in de V1-kluis de stopbeveiliging met de bewerking gegevens verwijderen voor FS1.
3. De registratie van het opslagaccount dat als host voor FS1 wordt gebruikt bij de V1-kluis ongedaan maken.
4. Configureer de back-up voor FS1 opnieuw, nu verplaatst naar S2, met een kluis (V2) in het S2-abonnement.

Nadat u de back-up opnieuw hebt geconfigureerd met V2, worden de momentopnamen die zijn gemaakt met V1 niet meer beheerd door Azure Backup. U moet deze momentopnamen dus handmatig verwijderen op basis van uw vereisten.

Ja, u kunt uw back-upbestands share verplaatsen naar een andere resourcegroep. U moet de back-up voor de bestands share echter opnieuw configureren, omdat deze wordt behandeld als een nieuwe resource door Azure Backup. Daarnaast worden de momentopnamen die zijn gemaakt voordat de resourcegroep werd verplaatst, 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 maakt een realtime berekening van het aantal momentopnamen wanneer u de retentiewaarden op geeft tijdens het configureren van het back-upbeleid. Zodra het aantal momentopnamen dat overeenkomt met uw gedefinieerde retentiewaarden groter is dan 200, wordt in de portal een waarschuwing weer gegeven waarin u wordt gevraagd uw retentiewaarden aan te passen. Dit is zodat u de limiet voor het maximum aantal momentopnamen dat door een Azure Files voor een bestands share op enig moment wordt ondersteund, niet overschrijdt.

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

• Retentie: 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 retentie wordt verlengd, wordt de vervaldatum van de bestaande herstelpunten bijgewerkt volgens 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 opschoonactie volgens de dagelijkse bewaarwaarde die is geconfigureerd in het nieuwe beleid en vervolgens verwijderd.

Hier is 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: 50 dagen. Elk herstelpunt dat ouder is dan 50 dagen wordt dus gemarkeerd voor verwijdering.

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

3. Alle toekomstige back-ups worden geactiveerd volgens het nieuwe schema: dat wil zeggen, om 21:00 uur.

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

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

Hier is een voorbeeld van hoe dit werkt:

Bestaand beleid [P2]

Nieuw beleid [gewijzigd P2]

Gevolgen van wijziging

1. De vervaldatum van bestaande dagelijkse herstelpunten wordt uitgelijnd op basis van de nieuwe dagelijkse bewaarwaarde, die 10 dagen is. Elk dagelijks herstelpunt dat ouder is dan tien dagen wordt dus verwijderd.

2. De vervaldatum van bestaande wekelijkse herstelpunten wordt uitgelijnd op basis van de nieuwe wekelijkse bewaarwaarde, die twee weken is. 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 kenmerk duration 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 tijdens uw werkuren worden geactiveerd wanneer er regelmatig updatebewerkingen worden uitgevoerd op de inhoud van de bestands share; Het maken van meerdere momentopnamen beschermt gegevens daarom tegen onbedoelde wijzigingen.

U hebt bijvoorbeeld een beleid gemaakt met de volgende configuratie:

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

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

De eerste back-up van de dag wordt geactiveerd op de starttijd die wordt vermeld in het beleid, dat wil zeggen, 9:00 uur, en de planning bepaalt het tijdsverschil tussen opeenvolgende back-ups, dat wil zeggen, 4 uur. Met deze berekening is uw back-upschema: 9:00 uur, 13:00 uur (9:00 + 4 uur), 17:00 uur (13:00 uur + 4 uur), 17:00 uur (13:00 + 4 uur) en 21:00 uur (17:00 uur + 4 uur).

Omdat de eindtijd van het back-upvenster dat we hebben berekend 21: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-up job kan worden getriggerd 9:00 uur, omdat de volgende back-uptijd van 15:00 uur (9:00 + 6 uur) buiten het back-upvenster valt: 9:00 – 13:00 uur (9:00 + 4 uur).

Om dit op te lossen, raden we u aan uw planning of duur aan te passen, of selecteert u Dagelijkse frequentie in plaats van Per uur.

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

U hebt bijvoorbeeld een beleid geconfigureerd met de volgende parameters:

• Planning: om de 4 uur
• Begintijd: 23: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 begintijd of duur aan te passen om ervoor te zorgen dat ze op dezelfde dag zijn.

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

Wanneer u overschakelt van de frequentie Dagelijks naar Elk uur, ziet het gedrag er als volgt uit:

• Retentie: als u wekelijkse/maandelijkse/jaarlijkse retentie toevoegt als onderdeel van het wijzigen van het beleid, worden alle toekomstige herstelpunten die worden 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 getagd als wekelijks/maandelijks/jaarlijks.

• Momentopnamen en herstelpunten opschonen:

  • Als de dagelijkse retentie wordt verlengd, wordt de vervaldatum van de bestaande dagelijkse herstelpunten bijgewerkt volgens 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 opschoonactie volgens de dagelijkse bewaarwaarde die is geconfigureerd in het nieuwe beleid en vervolgens verwijderd.

Volgende stappen

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