Delen via

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

VAN TOEPASSING OP: NoSQL MongoDB Gremlin Tafel

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, database of 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 de regio beschikbaarheidszones heeft ingeschakeld, wordt de back-up opgeslagen in zone-redundante opslagaccounts.

Diagram waarin wordt geïllustreerd hoe een back-up van een container wordt gemaakt in meerdere regio's.

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 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 of in een bestaand account. De keuze tussen deze twee modi is afhankelijk van de scenario's. In de meeste gevallen heeft het de voorkeur om verwijderde containers en databases te herstellen in een bestaand account. Dit voorkomt de kosten van gegevensoverdracht die nodig zijn bij het herstellen naar een nieuw account. Voor scenario's 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 herstel 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 zone-redundant 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, 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.

Herstelbare tijdstempel voor 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 op de herstelbare database of containers.

Diagram dat de levenscyclusgebeurtenissen met tijdstempels toont voor een herstelbare account.

  • Scenario 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.

    Levenscyclusgebeurtenissen met tijdstempels voor een herstelbare database en container.

  • Scenario 2: herstelgegevens van een account in een bepaalde regio: bijvoorbeeld als Account A bestaat in twee regio's VS - oost en VS - west ten tijde van 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.

  • Scenario 3: herstellen van een onbedoelde schrijf- of verwijderbewerking binnen 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.

  • Scenario 4: herstel een account 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.

  • Scenario 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 Machtigingen beheren voor het herstellen van een Azure Cosmos DB-account voor meer informatie.

Inzicht in het herstellen van accounts met schrijfbevoegheden in meerdere regio’s

Schrijfbewerkingen die in de hubregio worden uitgevoerd, worden onmiddellijk binnen 100 seconden asynchroon bevestigd en er wordt een back-up van gemaakt. In accounts met meerdere schrijfbewerkingen worden alle mutaties die in de satellietregio worden uitgevoerd, ter bevestiging naar de hubregio verzonden. De hubregio controleert of er conflictoplossing nodig is, wijst een tijdstempel voor conflictoplossing toe na het oplossen van de conflicten en stuurt het document terug naar de satellietregio. De satellietregio maakt alleen een back-up van de documenten nadat de bevestiging is ontvangen van de hub. Kortom, het herstelproces herstelt alleen de documenten die door de hubregio zijn bevestigd op het herstelpunt in de tijd.

Wat gebeurt er voor herstel voor schrijfaccounts voor meerdere regio's?

  • De mutaties die nog moeten worden bevestigd door de hersteltijdstempel worden niet hersteld.
  • De verzamelingen met een aangepast conflictoplossingsbeleid worden opnieuw ingesteld op basis van het "laatste schrijver wint"-principe met behulp van het tijdstempel.

Notitie

Herstellen vanuit satellietregio is langzamer in vergelijking met herstel in de hubregio voor een multi-regio account om lokale voorlopige schrijfbewerkingen op te lossen door ze als bevestigd te verklaren of een actie te ondernemen om ze terug te draaien.

Zie Uitleg van tijdstempels voor meer informatie over het begrijpen van tijdstempels in een account met meerdere schrijfbewerkingen.

Voorbeeldscenario: Gezien een account voor meerdere schrijfregio's met twee regio's VS - oost en VS - west, waarvan VS - oost de hubregio is, moet u rekening houden met de volgende reeks gebeurtenissen:

  • T1: Client schrijft een document doc1 naar VS - oost (omdat VS - oost de hubregio is, wordt de schrijfbewerking onmiddellijk bevestigd)

  • T2: Client schrijft een document Doc2 naar West-Amerika.

  • T3: VS - west stuurt Doc2 naar VS - oost ter bevestiging

  • T4: VS - oost heeft Doc2 ontvangen, bevestigt het document en stuurt Doc2 terug naar VS - west

  • T5: Het westen van de VS heeft Doc2 ontvangen.

Als in dit scenario de opgegeven hersteltijdstempel T3 is voor de hubregio als bron, wordt alleen Doc1 hersteld. Doc2 is niet bevestigd door hub door T3. Alleen als de hersteltijdstempel groter is dan T4, wordt doc2 hersteld, omdat het herstel op T4 in de satelliet alleen doc1 bevat, aangezien doc2 nog niet is bevestigd.

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:

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

  • Kosten voor herstel worden berekend als 1000 * 0,15 = $ 150 per herstel

Aanbeveling

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 laag van 7 dagen

  • De bewaarperiode voor één laag is 30 dagen in vergelijking met 7 dagen voor een andere laag.
  • Er worden 30 dagen retentielaag in rekening gebracht voor back-upopslag. Voor de retentielaag van zeven dagen worden geen kosten gerekend.
  • Herstellen wordt altijd in rekening gebracht in beide lagen

Tijd om te leven

  • Met het standaardherstelproces worden alle eigenschappen van een container hersteld, inclusief de TTL-configuratie. Dit kan leiden tot het verwijderen van gegevens als herstel wordt uitgevoerd zonder de TTL uit te schakelen. Als u verwijdering wilt voorkomen, geeft u een parameter door om TTL uit te schakelen in PowerShell (-DisableTtl $true) of cli (--disable-ttl True) tijdens het herstellen.

Door klant beheerde sleutels

Zie Hoe kunnen 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.

  • Azure Synapse Link voor database-accounts die gebruik maken van de modus voor continue back-up is algemeen beschikbaar. De omgekeerde situatie, de modus voor continue back-up voor Synapse Link-accounts, bevindt zich in openbare preview. Momenteel kunnen klanten die Synapse Link van containers hebben uitgeschakeld, niet migreren naar continue back-up. Analytische opslag is niet opgenomen in back-ups. Voor meer informatie, zie back-up van 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. Deze beleidsregels verlenen de machtigingen voor het account om een virtueel netwerk, 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 worden gemaakt, samen met het maken van de verzameling. Dit moet en kan alleen worden gedaan met behulp van de opdrachten voor het maken van de verzamelingsextensie.

  • 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 .

  • Unieke indexen in API voor MongoDB kunnen niet worden toegevoegd, bijgewerkt of verwijderd 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 is mogelijk dat de doorvoerinstelling bij het herstellen in continue modus niet de instelling is zoals die was op het herstelpunt.

Volgende stappen