Continue back-up met herstel naar een bepaald tijdstip in Azure Cosmos DB

VAN TOEPASSING OP: Nosql MongoDB Gremlin Tabel

De functie voor herstel naar een bepaald tijdstip van Azure Cosmos DB helpt in meerdere scenario's, waaronder:

• Herstellen van een onbedoelde schrijf- of verwijderbewerking binnen een container.
• Een verwijderd account, een database of een container herstellen.
• Herstellen naar een regio (waar back-ups bestonden) op het herstelpunt.

Azure Cosmos DB voert gegevensback-ups op de achtergrond uit zonder extra ingerichte doorvoer (RU's) te gebruiken of de prestaties en beschikbaarheid van uw database te beïnvloeden. Continue back-ups worden gemaakt in elke regio waar het account bestaat. Een account kan bijvoorbeeld een schrijfregio hebben in VS - west en leesregio's in VS - oost en VS - oost 2. Deze replicaregio's kunnen vervolgens worden geback-upt naar een extern Azure Storage-account in elke respectieve regio. Standaard slaat elke regio de back-up op in lokaal redundante opslagaccounts. Als voor de regio beschikbaarheidszones zijn ingeschakeld, wordt de back-up opgeslagen in zone-redundante opslagaccounts.

Diagram waarin wordt geïllustreerd hoe een container met een schrijfregio in VS - west en leesregio's in VS - oost en VS - oost 2 wordt geback-upt. Er wordt een back-up gemaakt van de container naar een extern Azure Blob Storage-account in elke respectieve schrijf- en leesregio.

Het tijdvenster dat beschikbaar is voor herstel (ook wel bewaarperiode genoemd) is de lagere waarde van de volgende twee opties: 30 dagen en 7 dagen.

De geselecteerde optie is afhankelijk van de gekozen laag van continue back-up. Het tijdstip voor herstel kan elke tijdstempel binnen de bewaarperiode zijn, niet verder terug dan het punt waarop de resource is gemaakt. In de modus voor sterke consistentie zijn back-ups die in de schrijfregio worden gemaakt, up-to-date in vergelijking met de leesregio's. Leesregio's kunnen achterblijven vanwege netwerkproblemen of andere tijdelijke problemen. Tijdens het herstellen kunt u de meest recente herstelbare tijdstempel voor een bepaalde resource in een specifieke regio ophalen. Als u verwijst naar de meest recente herstelbare tijdstempel, kunt u controleren of back-ups van resources tot de opgegeven tijdstempel behoren en in die regio kunnen worden hersteld.

Op dit moment kunt u een Azure Cosmos DB-account (API voor NoSQL of MongoDB, API voor Table, API voor Gremlin) op een bepaald moment herstellen naar een ander account. U kunt deze herstelbewerking uitvoeren via Azure Portal, de Azure CLI (Azure CLI), Azure PowerShell of Azure Resource Manager-sjablonen.

Opslagredundantie voor back-ups

Standaard worden in Azure Cosmos DB back-upgegevens in continue modus opgeslagen in lokaal redundante opslagblobs. Voor de regio's waarvoor zoneredundantie is geconfigureerd, wordt de back-up opgeslagen in zone-redundante opslagblobs. In de modus voor continue back-up kunt u de redundantie van de back-upopslag niet bijwerken.

Verschillende manieren om te herstellen

De modus Continue back-up ondersteunt twee manieren om verwijderde containers en databases te herstellen. Ze kunnen worden hersteld in een nieuw account, zoals hier wordt beschreven of kunnen worden hersteld in een bestaand account, zoals hier wordt beschreven. De keuze tussen deze twee modi is afhankelijk van de scenario's. In de meeste gevallen is het de voorkeur om verwijderde containers en databases te herstellen in een bestaand account. Dit voorkomt de kosten van gegevensoverdracht die vereist is voor het geval ze worden hersteld naar een nieuw account. Voor scenario waarin onbedoelde gegevenswijziging is uitgevoerd, kan het herstellen naar een nieuw account de voorkeursoptie zijn.

Wat wordt er hersteld in een nieuw account?

In een stabiele toestand worden alle mutaties die worden uitgevoerd op het bronaccount (waaronder databases, containers en items) asynchroon binnen 100 seconden een back-up gemaakt. Als de Back-upmedia van Azure Storage niet beschikbaar of offline zijn, worden de mutaties lokaal bewaard totdat de media beschikbaar zijn. Vervolgens worden de mutaties weggespoeld om verlies van betrouwbaarheid van bewerkingen te voorkomen die kunnen worden hersteld.

U kunt ervoor kiezen om een combinatie van ingerichte doorvoercontainers, een gedeelde doorvoer database of het hele account te herstellen. Met de herstelactie worden alle gegevens en de bijbehorende indexeigenschappen in een nieuw account hersteld. Het herstelproces zorgt ervoor dat alle gegevens die in een account, database of container zijn teruggezet, gegarandeerd consistent zijn met de opgegeven hersteltijd. De duur van het terugzetten is afhankelijk van de hoeveelheid gegevens die moet worden hersteld. De consistentie-instelling van het herstelde databaseaccount is hetzelfde als de consistentie-instellingen van het brondatabaseaccount.

Notitie

Met de modus continue back-up worden de back-ups gemaakt in elke regio waar uw Azure Cosmos DB-account beschikbaar is. Back-ups die voor elk regioaccount worden gemaakt, zijn standaard lokaal redundant en zoneredundant als voor uw account de functie beschikbaarheidszone is ingeschakeld voor die regio. De herstelactie herstelt altijd gegevens in een nieuw account.

Wat is er niet hersteld?

De volgende configuraties worden niet hersteld na het herstel naar een bepaald tijdstip:

• Een subset van containers onder een gedeelde doorvoerdatabase kan niet worden hersteld. De hele database kan als geheel worden hersteld.
• Firewall, VNET van virtueel netwerk, op rollen gebaseerd toegangsbeheer op basis van gegevensvlak of instellingen voor privé-eindpunten.
• Alle regio's uit het bronaccount.
• Opgeslagen procedures, triggers, UDF's.
• Toewijzingen voor op rollen gebaseerd toegangsbeheer.

U kunt deze configuraties toevoegen aan het herstelde account nadat het herstellen is voltooid.

Restorable timestamp for live accounts

Als u Live-accounts van Azure Cosmos DB wilt herstellen die niet worden verwijderd, is het raadzaam altijd de meest recente herstelbare tijdstempel voor de container te identificeren. Vervolgens kunt u deze tijdstempel gebruiken om het account te herstellen naar de nieuwste versie.

Herstelscenario's

De functie Voor herstel naar een bepaald tijdstip ondersteunt de volgende scenario's. Scenario's [1] tot en met [3] laten zien hoe u een herstel activeert als de tijdstempel van herstel vooraf bekend is. Er kunnen echter scenario's zijn waarin u niet weet hoe lang het per ongeluk verwijderen of beschadigd is. Scenario's [4] en [5] laten zien hoe u de hersteltijdstempel kunt detecteren met behulp van de nieuwe gebeurtenisfeed-API's in de herstelbare database of containers.

1. Verwijderd account herstellen: alle verwijderde accounts die u kunt herstellen, zijn zichtbaar in het deelvenster Herstellen . Als account A bijvoorbeeld wordt verwijderd op tijdstempel T3. In dit geval is de tijdstempel net vóór T3, locatie, doelaccountnaam, resourcegroep en doelaccountnaam voldoende om te herstellen vanuit Azure Portal, PowerShell of CLI.

   

2. Herstel gegevens van een account in een bepaalde regio , bijvoorbeeld als Account A bestaat in twee regio's VS - oost en VS - west bij tijdstempel T3. Als u een kopie van account A in VS - west nodig hebt, kunt u een herstel naar een bepaald tijdstip uitvoeren vanuit Azure Portal, PowerShell of CLI met VS - west als doellocatie.

3. Herstel na een onbedoelde schrijf- of verwijderbewerking in een container met een bekend tijdstempel voor herstel . Als u bijvoorbeeld weet dat de inhoud van Container 1 in Database 1 per ongeluk is gewijzigd bij tijdstempel T3. U kunt een herstel naar een bepaald tijdstip uitvoeren vanuit Azure Portal, PowerShell of CLI in een ander account op tijdstempel T3 om de gewenste status van de container te herstellen.

4. Een account herstellen naar een eerder tijdstip voordat de database per ongeluk wordt verwijderd. In Azure Portal kunt u het deelvenster gebeurtenisfeed gebruiken om te bepalen wanneer een database is verwijderd en de hersteltijd te vinden. Op dezelfde manier kunt u met Azure CLI en PowerShell de gebeurtenis voor het verwijderen van de database detecteren door de feed voor database-gebeurtenissen op te sommen en vervolgens de herstelopdracht te activeren met de vereiste parameters.

5. Herstel een account naar een eerder tijdstip voordat de containereigenschappen per ongeluk worden verwijderd of gewijzigd. - In Azure Portal kunt u het deelvenster gebeurtenisfeed gebruiken om te bepalen wanneer een container is gemaakt, gewijzigd of verwijderd om de hersteltijd te vinden. Op dezelfde manier kunt u met Azure CLI en PowerShell alle container gebeurtenissen detecteren door de container gebeurtenissenfeed op te sommen en vervolgens de herstelopdracht met de vereiste parameters te activeren.

Machtigingen

Met Azure Cosmos DB kunt u de herstelmachtigingen voor een doorlopend back-upaccount isoleren en beperken tot een specifieke rol of principal. Zie het artikel Machtigingen voor meer informatie.

Prijzen

Azure Cosmos DB-account met continue back-up van 30 dagen heeft een extra maandelijkse kosten voor het opslaan van de back-up. Zowel de 30-daagse als de 7-daagse laag van continue back brengt kosten in rekening om uw gegevens te herstellen. De herstelkosten worden toegevoegd telkens wanneer de herstelbewerking wordt gestart. Als u een account met continue back-up configureert maar de gegevens niet herstelt, worden alleen de kosten voor back-upopslag opgenomen in uw factuur.

Het volgende voorbeeld is gebaseerd op de prijs voor een Azure Cosmos DB-account dat is geïmplementeerd in VS - west. De prijzen en berekeningen kunnen variëren, afhankelijk van de regio die u gebruikt. Zie de pagina met prijzen van Azure Cosmos DB voor de meest recente prijsinformatie.

• Voor alle accounts die zijn ingeschakeld met beleid voor continue back-up met 30 dagen, worden maandelijkse kosten in rekening gebracht voor back-upopslag die als volgt wordt berekend:

  $ 0,20/GB * Gegevensgrootte in GB in rekening * Aantal regio's

• Bij elke aanroep van de HERSTEL-API worden eenmalige kosten in rekening gebracht. De kosten zijn een functie van de hoeveelheid herstelde gegevens:

  $0,15/GB * Gegevensgrootte in GB.

Als u bijvoorbeeld 1 TB aan gegevens in twee regio's hebt, gaat u als volgt te werk:

• Kosten voor back-upopslag worden berekend als (1000 * 0,20 * 2) = $ 400 per maand

• Herstelkosten worden berekend als (1000 * 0,15) = $ 150 per herstel

Tip

Zie Azure Monitor Azure Cosmos DB-inzichten verkennen voor meer informatie over het meten van het huidige gegevensgebruik van uw Azure Cosmos DB-account. Voor de continue laag van 7 dagen worden geen kosten in rekening gebracht voor het maken van back-ups van de gegevens.

Doorlopende laag van 30 dagen versus continue laag van 7 dagen

• De bewaarperiode voor één laag is 30 dagen versus 7 dagen voor een andere laag.
• Er worden 30 dagen retentielaag in rekening gebracht voor back-upopslag. 7 dagen retentielaag wordt niet in rekening gebracht.
• Herstellen wordt altijd in rekening gebracht in beide lagen

Door klant beheerde sleutels

Zie hoe door de klant beheerde sleutels van invloed zijn op continue back-ups? Voor meer informatie:

• Uw Azure Cosmos DB-account configureren bij het gebruik van door de klant beheerde sleutels met continue back-ups.
• Hoe beïnvloeden door de klant beheerde sleutels herstelbewerkingen?

Huidige beperkingen

Momenteel heeft de functionaliteit voor herstel naar een bepaald tijdstip de volgende beperkingen:

• Azure Cosmos DB-API's voor SQL, MongoDB, Gremlin en Table die worden ondersteund voor continue back-up. API voor Cassandra wordt nu niet ondersteund.

• Schrijfaccounts voor meerdere regio's worden niet ondersteund.

• Momenteel kan Azure Synapse Link worden ingeschakeld in databaseaccounts voor continue back-up. Maar de omgekeerde situatie wordt nog niet ondersteund, het is niet mogelijk om continue back-up in te schakelen in databaseaccounts met Synapse Link. Analytische opslag is niet opgenomen in back-ups. Zie back-up van analytische opslag voor meer informatie over back-up en analytische opslag.

• Het herstelde account wordt gemaakt in dezelfde regio waarin zich uw bronaccount bevindt. U kunt een account niet herstellen in een regio waarin het bronaccount niet bestond.

• Het herstelvenster is slechts 30 dagen voor continue laag van 30 dagen en zeven dagen voor een continue laag van 7 dagen. Deze lagen kunnen worden gewijzigd, maar de werkelijke hoeveelheden (7 of 30) kunnen niet worden gewijzigd. Als u overschakelt van laag van 30 dagen naar een laag van 7 dagen, is er bovendien het potentieel voor gegevensverlies op dagen na de zevende.

• De back-ups zijn niet automatisch geografisch noodherstelbestendig. Er moet expliciet een andere regio worden toegevoegd voor tolerantie van het account en de back-up.

• Terwijl een herstelbewerking wordt uitgevoerd, moet u het IAM-beleid (Identity and Access Management) niet wijzigen of verwijderen. Met deze beleidsregels worden de machtigingen voor het account verleend om een VNET, firewallconfiguratie te wijzigen.

• Azure Cosmos DB voor MongoDB-accounts met continue back-up bieden geen ondersteuning voor het maken van een unieke index voor een bestaande verzameling. Voor een dergelijk account moeten unieke indexen samen met hun verzameling worden gemaakt; U kunt dit doen met behulp van de opdrachten voor het maken van verzamelingsuitbreidingen.

• De herstelfunctionaliteit naar een bepaald tijdstip herstelt altijd naar een nieuw Azure Cosmos DB-account. Het herstellen naar een bestaand account wordt momenteel niet ondersteund. Als u feedback wilt geven over in-place herstel, neemt u contact op met het Azure Cosmos DB-team via uw accountvertegenwoordiger.

• Na het herstellen is het mogelijk dat voor bepaalde verzamelingen de consistente index opnieuw kan worden opgebouwd. U kunt de status van de herbouwbewerking controleren via de eigenschap IndexTransformationProgress .

• Tijdens het herstelproces worden alle eigenschappen van een container, inclusief de TTL-configuratie, standaard hersteld. U kunt de parameter doorgeven om TTL uit te schakelen tijdens het herstellen. Als gevolg hiervan is het mogelijk dat de herstelde gegevens onmiddellijk worden verwijderd als u die manier hebt geconfigureerd. U kunt deze situatie voorkomen als u ervoor zorgt dat het tijdstempel van de herstelbewerking eerder is dan het moment waarop de TTL-eigenschappen aan de container worden toegevoegd.

• Unieke indexen in API voor MongoDB kunnen niet worden toegevoegd of bijgewerkt wanneer u een account voor continue back-upmodus maakt. Ze kunnen ook niet worden gewijzigd wanneer u een account migreert van periodieke naar continue modus.

• Het herstellen van de continue modus kan de doorvoerinstelling die geldig is vanaf het herstelpunt, niet herstellen.

Volgende stappen

• Schakel continue back-ups in met behulp van Azure Portal, PowerShell, CLI of Azure Resource Manager.
• Haal de meest recente herorable timestamp op voor SQL- en MongoDB-accounts.
• Herstel een doorlopend back-upaccount met behulp van Azure Portal, PowerShell, CLI of Azure Resource Manager.
• Migreren naar een account van periodieke back-up naar continue back-up.
• Machtigingen beheren die nodig zijn om gegevens te herstellen met de modus voor continue back-up.
• Resourcemodel van continue back-upmodus