Herstel naar een bepaald tijdstip voor blok-blobs
Herstel naar een bepaald tijdstip biedt bescherming tegen onbedoelde verwijdering of beschadiging door u in staat te stellen blok-blobgegevens te herstellen naar een eerdere status. Herstel naar een bepaald tijdstip is handig in scenario's waarin een gebruiker of toepassing per ongeluk gegevens verwijdert of wanneer een toepassingsfout gegevens beschadigd. Met herstel naar een bepaald tijdstip kunnen ook testscenario's worden uitgevoerd waarvoor een gegevensset moet worden teruggezet naar een bekende status voordat verdere tests worden uitgevoerd.
Herstel naar een bepaald tijdstip wordt alleen ondersteund voor v2-opslagaccounts voor algemeen gebruik in de standard-prestatielaag. Alleen gegevens in de dynamische en statische toegangslagen kunnen worden hersteld met herstel naar een bepaald tijdstip. Herstel naar een bepaald tijdstip wordt nog niet ondersteund in accounts met een hiërarchische naamruimte.
Zie Een herstel naar een bepaald tijdstip uitvoeren op blok-blobgegevens voor informatie over het inschakelen van herstel naar een bepaald tijdstip voor een opslagaccount.
Hoe herstel naar een bepaald tijdstip werkt
Als u herstel naar een bepaald tijdstip wilt inschakelen, maakt u een beheerbeleid voor het opslagaccount en geeft u een bewaarperiode op. Tijdens de bewaarperiode kunt u blok-blobs herstellen van de huidige status naar een status op een eerder tijdstip.
Als u een herstel naar een bepaald tijdstip wilt initiëren, roept u de bewerking Blobbereiken herstellen aan en geeft u een herstelpunt op in UTC-tijd. U kunt lexicografische bereiken van container- en blobnamen opgeven om te herstellen of het bereik weglaten om alle containers in het opslagaccount te herstellen. Per herstelbewerking worden maximaal 10 lexicografische bereiken ondersteund.
Azure Storage analyseert alle wijzigingen die zijn aangebracht in de opgegeven blobs tussen het aangevraagde herstelpunt, opgegeven in utc-tijd en het huidige moment. De herstelbewerking is atomisch, dus het herstel slaagt volledig in het herstellen van alle wijzigingen of mislukt. Als er blobs zijn die niet kunnen worden hersteld, mislukt de bewerking en worden lees- en schrijfbewerkingen naar de betrokken containers hervat.
In het volgende diagram ziet u hoe herstel naar een bepaald tijdstip werkt. Een of meer containers of blobbereiken worden hersteld naar de status n dagen geleden, waarbij n kleiner is dan of gelijk is aan de bewaarperiode die is gedefinieerd voor herstel naar een bepaald tijdstip. Het effect is het terugzetten van schrijf- en verwijderbewerkingen die zijn opgetreden tijdens de bewaarperiode.
Er kan slechts één herstelbewerking tegelijk worden uitgevoerd op een opslagaccount. Een herstelbewerking kan niet worden geannuleerd zodra deze wordt uitgevoerd, maar een tweede herstelbewerking kan worden uitgevoerd om de eerste bewerking ongedaan te maken.
De bewerking BlobBereiken herstellen retourneert een herstel-id die de bewerking uniek identificeert. Als u de status van een herstel naar een bepaald tijdstip wilt controleren, roept u de bewerking Herstelstatus ophalen aan met de herstel-id die is geretourneerd vanuit de bewerking Blobbereiken herstellen.
Belangrijk
Wanneer u een herstelbewerking uitvoert, blokkeert Azure Storage gegevensbewerkingen op de blobs in de bereiken die worden hersteld voor de duur van de bewerking. Lees-, schrijf- en verwijderbewerkingen worden geblokkeerd op de primaire locatie. Daarom worden bewerkingen zoals het weergeven van containers in Azure Portal mogelijk niet zoals verwacht uitgevoerd terwijl de herstelbewerking wordt uitgevoerd.
Leesbewerkingen vanaf de secundaire locatie kunnen doorgaan tijdens de herstelbewerking als het opslagaccount geo-replicatie heeft.
Let op
Herstel naar een bepaald tijdstip biedt ondersteuning voor het herstellen van bewerkingen die alleen op blok-blobs hebben gereageerd. Bewerkingen die op containers zijn uitgevoerd, kunnen niet worden hersteld. Als u bijvoorbeeld een container uit het opslagaccount verwijdert door de bewerking Container verwijderen aan te roepen, kan die container niet worden hersteld met een herstelbewerking naar een bepaald tijdstip. In plaats van een hele container te verwijderen, verwijdert u afzonderlijke blobs als u ze later mogelijk wilt herstellen.
Vereisten voor herstel naar een bepaald tijdstip
Herstel naar een bepaald tijdstip vereist dat de volgende Azure Storage-functies zijn ingeschakeld voordat u herstel naar een bepaald tijdstip kunt inschakelen:
Zie het overzicht van gegevensbescherming voor meer informatie over de aanbevelingen van Microsoft voor gegevensbescherming.
Let op
Nadat u blobversiebeheer voor een opslagaccount hebt ingeschakeld, resulteert elke schrijfbewerking in een blob in dat account in het maken van een nieuwe versie. Daarom kan het inschakelen van blobversiebeheer leiden tot extra kosten. Als u kosten wilt minimaliseren, gebruikt u een levenscyclusbeheerbeleid om oude versies automatisch te verwijderen. Zie Kosten optimaliseren door azure Blob Storage-toegangslagen te automatiseren voor meer informatie over levenscyclusbeheer.
Bewaarperiode voor herstel naar een bepaald tijdstip
Wanneer u herstel naar een bepaald tijdstip voor een opslagaccount inschakelt, geeft u een bewaarperiode op. Blok-blobs in uw opslagaccount kunnen tijdens de bewaarperiode worden hersteld.
De bewaarperiode begint een paar minuten nadat u herstel naar een bepaald tijdstip hebt ingeschakeld. Houd er rekening mee dat u blobs niet kunt herstellen naar een status vóór het begin van de bewaarperiode. Als u bijvoorbeeld herstel naar een bepaald tijdstip hebt ingeschakeld op 1 mei met een bewaarperiode van 30 dagen, kunt u op 15 mei herstellen tot een maximum van 15 dagen. Op 1 juni kunt u gegevens tussen 1 en 30 dagen herstellen.
De bewaarperiode voor herstel naar een bepaald tijdstip moet ten minste één dag korter zijn dan de retentieperiode die is opgegeven voor voorlopig verwijderen. Als de bewaarperiode voor voorlopig verwijderen bijvoorbeeld is ingesteld op zeven dagen, kan de bewaarperiode voor herstel naar een bepaald tijdstip tussen 1 en 6 dagen duren.
Notitie
De retentieperiode die u opgeeft voor herstel naar een bepaald tijdstip heeft geen invloed op de retentie van blobversies. Blob-versies worden bewaard totdat ze expliciet worden verwijderd. Als u de kosten wilt optimaliseren door oudere versies te verwijderen of te tieren, maakt u een levenscyclusbeheerbeleid. Zie Kosten optimaliseren door de levenscyclus van gegevens automatisch te beheren voor meer informatie.
De tijd die nodig is om een set gegevens te herstellen, is gebaseerd op het aantal schrijf- en verwijderbewerkingen die tijdens de herstelperiode zijn uitgevoerd. Een account met één miljoen blobs met 3000 blobs per dag en 1000 blobs die per dag zijn verwijderd, vereist bijvoorbeeld ongeveer twee uur om te herstellen naar een punt van 30 dagen in het verleden. Een bewaarperiode en herstel meer dan 90 dagen in het verleden worden niet aanbevolen voor een account met dit wijzigingspercentage.
Machtigingen voor herstel naar een bepaald tijdstip
Als u een herstelbewerking wilt starten, moet een client schrijfmachtigingen hebben voor alle containers in het opslagaccount. Als u machtigingen wilt verlenen voor het autoriseren van een herstelbewerking met Microsoft Entra-id, wijst u de rol Inzender voor opslagaccounts toe aan de beveiligingsprincipaal op het niveau van het opslagaccount, de resourcegroep of het abonnement.
Beperkingen en bekende problemen
Herstel naar een bepaald tijdstip voor blok-blobs heeft de volgende beperkingen en bekende problemen:
- Alleen blok-blobs in een standaard v2-opslagaccount voor algemeen gebruik kunnen worden hersteld als onderdeel van een herstelbewerking naar een bepaald tijdstip. Toevoeg-blobs, pagina-blobs en premium blok-blobs worden niet hersteld.
- Als u een container tijdens de bewaarperiode hebt verwijderd, wordt die container niet hersteld met de herstelbewerking naar een bepaald tijdstip. Als u probeert een bereik van blobs te herstellen dat blobs bevat in een verwijderde container, mislukt de herstelbewerking naar een bepaald tijdstip. Zie Voorlopig verwijderen voor containers voor meer informatie over het beveiligen van containers tegen verwijdering.
- Als u permanent verwijderen gebruikt om voorlopig verwijderde versies van een blob te verwijderen tijdens de bewaarperiode voor herstel naar een bepaald tijdstip, kan een herstelbewerking deze blob mogelijk niet correct herstellen.
- Als een blob tussen de dynamische en statische lagen in de periode tussen het huidige moment en het herstelpunt is verplaatst, wordt de blob teruggezet naar de vorige laag.
- Het herstellen van blok-blobs in de archieflaag wordt niet ondersteund. Als een blob in de dynamische laag bijvoorbeeld twee dagen geleden naar de archieflaag is verplaatst en een herstelbewerking drie dagen geleden wordt hersteld naar een punt, wordt de blob niet hersteld naar de dynamische laag. Als u een gearchiveerde blob wilt herstellen, verplaatst u deze eerst uit de archieflaag. Zie Overzicht van rehydratatie van blobs vanuit de archieflaag voor meer informatie.
- Gedeeltelijke herstelbewerkingen worden niet ondersteund. Als er daarom blobs in een container zijn gearchiveerd, mislukt de hele herstelbewerking omdat het herstellen van blok-blobs in de archieflaag niet wordt ondersteund.
- Als een beleid voor onveranderbaarheid is geconfigureerd, kan een herstelbewerking worden gestart, maar eventuele blobs die worden beveiligd door het beleid voor onveranderbaarheid, worden niet gewijzigd. Een herstelbewerking in dit geval leidt niet tot het herstellen van een consistente status tot de gegeven datum en tijd.
- Een blok dat is geüpload via Put Block of Put Block from URL, maar niet doorgevoerd via Put Block List, maakt geen deel uit van een blob en wordt dus niet hersteld als onderdeel van een herstelbewerking.
- Als een blob met een actieve lease is opgenomen in het bereik om te herstellen en als de huidige versie van de geleasede blob verschilt van de vorige versie in de tijdstempel die is opgegeven voor PITR, mislukt de herstelbewerking atomisch. U wordt aangeraden actieve leases te verbreken voordat u de herstelbewerking start.
- Als u een door de klant beheerde failover uitvoert op een opslagaccount, wordt het vroegst mogelijke herstelpunt voor het opslagaccount opnieuw ingesteld. Zie Herstel naar een bepaald tijdstip voor meer informatie.
- Momentopnamen worden niet gemaakt of verwijderd als onderdeel van een herstelbewerking. Alleen de basis-blob wordt hersteld naar de vorige status.
- Herstel naar een bepaald tijdstip wordt niet ondersteund voor hiërarchische naamruimten of bewerkingen via Azure Data Lake Storage Gen2.
- Herstel naar een bepaald tijdstip wordt niet ondersteund wanneer de eigenschap AllowedCopyScope van het opslagaccount is ingesteld om het kopieerbereik te beperken tot dezelfde Microsoft Entra-tenant of hetzelfde virtuele netwerk. Zie Over toegestaan bereik voor kopieerbewerkingen (preview) voor meer informatie.
- Herstel naar een bepaald tijdstip wordt niet ondersteund wanneer onveranderbaarheid op versieniveau is ingeschakeld voor een opslagaccount of een container in een account. Zie Onveranderbaarheidsbeleid op versieniveau configureren voor blobversies voor meer informatie over onveranderbaarheidsbeleid op versieniveau.
Belangrijk
Als u blok-blobs herstelt naar een eerder punt dan 22 september 2020, zijn preview-beperkingen voor herstel naar een bepaald tijdstip van kracht. Microsoft raadt u aan een herstelpunt te kiezen dat gelijk is aan of hoger is dan 22 september 2020 om te profiteren van de algemeen beschikbare functie voor herstel naar een bepaald tijdstip.
Functieondersteuning
Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u de ondersteuning voor Blob Storage-functies in Azure Storage-accounts om ondersteuning voor deze functie te beoordelen.
Prijzen en facturering
Er worden geen kosten in rekening gebracht om herstel naar een bepaald tijdstip in te schakelen. Als u herstel naar een bepaald tijdstip inschakelt, worden echter ook blobversiebeheer, voorlopig verwijderen en wijzigingenfeed ingeschakeld, die elk kunnen leiden tot extra kosten.
Facturering voor het uitvoeren van herstelbewerkingen naar een bepaald tijdstip is gebaseerd op de hoeveelheid wijzigingenfeedgegevens die voor de herstelbewerking zijn verwerkt. U wordt ook gefactureerd voor alle opslagtransacties die betrokken zijn bij het herstelproces.
Zie prijzen voor blok-blobs voor meer informatie over prijzen voor herstel naar een bepaald tijdstip.