Automatische back-ups in Azure SQL Managed Instance

Van toepassing op: Azure SQL Managed Instance

In dit artikel wordt de functie voor automatische back-up voor Azure SQL Managed Instance beschreven.

Zie Instellingen wijzigen als u de back-upinstellingen wilt wijzigen. Zie Herstellen met behulp van geautomatiseerde databaseback-ups als u een back-up wilt herstellen.

Wat is een databaseback-up?

Databaseback-ups zijn een essentieel onderdeel van elke strategie voor bedrijfscontinuïteit en herstel na noodgevallen, omdat ze uw gegevens beschermen tegen beschadiging of verwijdering. Met deze back-ups kunt u de database herstellen naar een bepaald tijdstip binnen de geconfigureerde retentieperiode. Als uw regels voor gegevensbescherming vereisen dat uw back-ups gedurende een langere periode (maximaal 10 jaar) beschikbaar zijn, kunt u langetermijnretentie (LTR) configureren voor individuele databases en pooldatabases.

Databases in Azure SQL Managed Instance SQL Server-enginetechnologie gebruiken voor het maken van back-ups en het herstellen van gegevens.

Back-upfrequentie

Azure SQL Managed Instance maakt:

De frequentie van de back-ups van het transactielogboek is gebaseerd op de rekenkracht en de hoeveelheid databaseactiviteit. Wanneer u een database herstelt, bepaalt de service welke volledige back-ups, differentiële back-ups en transactielogboekback-ups moeten worden hersteld.

Opslagredundantie voor back-ups

Standaard slaat Azure SQL Managed Instance gegevens op in geografisch redundante opslagblobs die worden gerepliceerd naar een gekoppelde regio. Geo-redundantie beschermt tegen storingen die van invloed zijn op back-upopslag in de primaire regio. U kunt uw exemplaar ook herstellen naar een andere regio in het geval van een noodgeval.

Het opslagredundantiemechanisme slaat meerdere kopieën van uw gegevens op, zodat deze worden beschermd tegen geplande en ongeplande gebeurtenissen. Deze gebeurtenissen kunnen tijdelijke hardwarestoringen, netwerk- of stroomstoringen of grootschalige natuurrampen zijn.

Om ervoor te zorgen dat uw back-ups binnen dezelfde regio blijven waarin uw database is geïmplementeerd, kunt u redundantie voor back-upopslag wijzigen van de standaard geografisch redundante opslag in andere typen opslag die uw gegevens binnen de regio houden. Zie Gegevensredundantie voor meer informatie over opslagredundantie.

U kunt redundantie voor back-upopslag configureren wanneer u uw exemplaar maakt en u kunt deze op een later tijdstip op exemplaarniveau bijwerken. De wijzigingen die u aanbrengt in een bestaand exemplaar, zijn alleen van toepassing op toekomstige back-ups. Nadat u de redundantie van back-upopslag van een bestaand exemplaar hebt bijgewerkt, kan het tot 24 uur duren voordat de wijzigingen zijn toegepast. Wijzigingen in redundantie van back-upopslag zijn alleen van toepassing op kortetermijnback-ups. Langetermijnretentiebeleid neemt de redundantieoptie van kortetermijnback-ups over wanneer het beleid wordt gemaakt. De redundantieoptie blijft behouden voor langetermijnback-ups, zelfs als de redundantieoptie voor kortetermijnback-ups vervolgens wordt gewijzigd.

Notitie

Houd er rekening mee dat de redundantiewijziging back-up een upgradestap veroorzaakt die een failover initieert.

U kunt een van de volgende opslagredundantie voor back-ups kiezen:

  • Lokaal redundante opslag (LRS): kopieert uw back-ups drie keer synchroon binnen één fysieke locatie in de primaire regio. LRS is de goedkoopste replicatieoptie, maar we raden het niet aan voor toepassingen die hoge beschikbaarheid of duurzaamheid vereisen.

    Diagram met de optie lokaal redundante opslag (LRS).

  • Zone-redundante opslag (ZRS): kopieert uw back-ups synchroon in drie Azure-beschikbaarheidszones in de primaire regio. Het is momenteel beschikbaar in bepaalde regio's.

    Diagram met de optie zone-redundante opslag (ZRS).

  • Geografisch redundante opslag (GRS): kopieert uw back-ups drie keer synchroon binnen één fysieke locatie in de primaire regio met behulp van LRS. Vervolgens worden uw gegevens drie keer asynchroon gekopieerd naar één fysieke locatie in de gekoppelde secundaire regio.

    Het resultaat is:

    • Drie synchrone kopieën in de primaire regio.
    • Drie synchrone kopieën in de gekoppelde regio die asynchroon zijn gekopieerd van de primaire regio naar de secundaire regio.

    Diagram met de optie voor geografisch redundante opslag (GRS).

  • Geografisch zone-redundante opslag (GZRS): combineert de hoge beschikbaarheid die wordt geboden door redundantie in beschikbaarheidszones met bescherming tegen regionale storingen die worden geboden door geo-replicatie. Gegevens in een GZRS-account worden gekopieerd naar drie Azure-beschikbaarheidszones in de primaire regio. De gegevens worden ook gerepliceerd naar een secundaire geografische regio voor bescherming tegen regionale rampen. In die regio hebt u ook drie synchrone kopieën die asynchroon van de primaire regio naar de secundaire regio zijn gekopieerd.

    Diagram met de optie geografisch zone-redundante opslag (GZRS).

Waarschuwing

  • Geo-herstel wordt uitgeschakeld zodra een database wordt bijgewerkt voor lokaal redundante of zone-redundante opslag.
  • De opslagredundantiediagrammen tonen allemaal regio's met meerdere beschikbaarheidszones (multi-az). Er zijn echter enkele regio's die slechts één beschikbaarheidszone bieden en geen ondersteuning bieden voor ZRS of GZRS.

Back-upgebruik

U kunt deze back-ups gebruiken om:

  • Herstel een bestaande database naar een bepaald tijdstip in het verleden binnen de retentieperiode met behulp van de Azure Portal, Azure PowerShell, de Azure CLI of de REST API. Met deze bewerking maakt u een nieuwe database op hetzelfde exemplaar als de oorspronkelijke database of een ander exemplaar in hetzelfde abonnement en dezelfde regio. Er wordt een andere naam gebruikt om te voorkomen dat de oorspronkelijke database wordt overschreven. U kunt de Azure Portal ook gebruiken om uw back-up van de database naar een bepaald tijdstip te herstellen naar een exemplaar in een ander abonnement dan uw bronexemplaren.

    Nadat het herstellen is voltooid, kunt u de oorspronkelijke database verwijderen. U kunt ook zowel de naam van de oorspronkelijke database wijzigen als de naam van de herstelde database wijzigen in de naam van de oorspronkelijke database.

  • Een verwijderde database herstellen naar een bepaald tijdstip binnen de retentieperiode, inclusief het tijdstip van verwijdering. U kunt de verwijderde database herstellen naar hetzelfde beheerde exemplaar waarin de back-up is gemaakt, of een ander exemplaar in hetzelfde of een ander abonnement op het bronexemplaren. Voordat u een database verwijdert, maakt de service een laatste back-up van het transactielogboek om gegevensverlies te voorkomen.

  • Een database herstellen naar een andere geografische regio. Met geo-herstel kunt u herstellen na een geografisch noodgeval wanneer u geen toegang hebt tot uw database of back-ups in de primaire regio. Er wordt een nieuwe database gemaakt op elk bestaand beheerd exemplaar in een Azure-regio.

    Belangrijk

    Geo-herstel is alleen beschikbaar voor databases die zijn geconfigureerd met geografisch redundante back-upopslag. Als u momenteel geen geo-gerepliceerde back-ups voor een database gebruikt, kunt u dat wijzigen door redundantie van back-upopslag te configureren.

  • Een database herstellen vanuit een specifieke langetermijnback-up van een database, als de database is geconfigureerd met een LTR-beleid. Met LTR kunt u een oude versie van de database herstellen met behulp van de Azure Portal, de Azure CLI of Azure PowerShell om te voldoen aan een nalevingsaanvraag of om een oude versie van de toepassing uit te voeren. Zie Langetermijnretentie voor meer informatie.

Mogelijkheden en functies herstellen

Deze tabel bevat een overzicht van de mogelijkheden en functies van herstel naar een bepaald tijdstip, geo-herstel en langetermijnretentie.

Back-upeigenschappen  PITR Geo-herstel LTR
Typen back-ups van SQL Volledig, differentieel, logboek. Gerepliceerde kopieën van PITR-back-ups. Alleen de volledige back-ups.
Recovery Point Objective (RPO)  10 minuten, op basis van de rekenkracht en de hoeveelheid databaseactiviteit.   Maximaal 1 uur, op basis van geo-replicatie.*  Eén week (of het beleid van de gebruiker).
Beoogde hersteltijd (RTO) Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Herstel Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Herstel. Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Herstel.
Retentie 1 tot 35 dagen.  Standaard ingeschakeld, hetzelfde als de bron.** Niet standaard ingeschakeld. Retentie is maximaal 10 jaar.
Azure Storage   Standaard geografisch redundant. U kunt eventueel zone-redundante of lokaal redundante opslag configureren. Beschikbaar wanneer PITR-opslagredundantie is ingesteld op geografisch redundant. Niet beschikbaar wanneer PITR-back-upopslag zoneredundant of lokaal redundant is.  Standaard geografisch redundant. U kunt zone-redundante of lokaal redundante opslag configureren.
Een nieuwe database in dezelfde regio herstellen Ondersteund Ondersteund  Ondersteund
Een nieuwe database herstellen in een andere regio Niet ondersteund Ondersteund in elke Azure-regio Ondersteund in elke Azure-regio
Een nieuwe database herstellen in een ander abonnement Ondersteund Niet ondersteund*** Niet ondersteund***
Herstellen via Azure Portal Ja Ja Ja
Herstellen via PowerShell Ja Ja Ja
Herstellen via Azure CLI Ja Nee Ja

* Gebruik groepen voor automatische failover voor bedrijfskritieke toepassingen waarvoor grote databases nodig zijn en die de bedrijfscontinuïteit moeten garanderen.

** Alle PITR-back-ups worden standaard opgeslagen op geografisch redundante opslag, dus geo-herstel is standaard ingeschakeld.

De tijdelijke oplossing is om te herstellen naar een nieuwe server en resource verplaatsen te gebruiken om de server naar een ander abonnement te verplaatsen.

Een database herstellen vanuit een back-up

Zie Een database herstellen vanuit back-ups als u een herstelbewerking wilt uitvoeren. U kunt back-upconfiguratie en herstelbewerkingen proberen met behulp van de volgende voorbeelden.

Bewerking Azure Portal Azure CLI Azure PowerShell
Back-upretentie wijzigen SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Langetermijnretentie van back-ups wijzigen SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Een database herstellen vanaf een bepaald tijdstip SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Een verwijderde database herstellen SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
SQL Database
SQL Managed Instance
Een database herstellen vanaf Azure Blob Storage
SQL Managed Instance

Back-upplanning

De eerste volledige back-up wordt gepland onmiddellijk nadat een nieuwe database is gemaakt of hersteld, of nadat de redundantie van de back-up is gewijzigd. Deze back-up wordt meestal binnen 30 minuten voltooid, maar het kan langer duren wanneer de database groot is.

Voor een nieuwe database is de back-up snel. De back-uptijd kan echter variëren voor een herstelde database en is afhankelijk van de grootte van de database. De eerste back-up kan bijvoorbeeld langer duren voor een herstelde database of een databasekopie, die doorgaans groter is dan een nieuwe database.

Na de eerste volledige back-up worden alle verdere back-ups automatisch gepland en beheerd. De exacte timing van alle databaseback-ups wordt bepaald door de SQL Managed Instance service, omdat deze de algehele systeemworkload in balans houdt. U kunt de planning van back-uptaken niet wijzigen of uitschakelen.

Belangrijk

Voor een nieuwe, herstelde of gekopieerde database wordt de herstelmogelijkheid naar een bepaald tijdstip beschikbaar wanneer de eerste back-up van het transactielogboek na de eerste volledige back-up wordt gemaakt.

Verbruik van back-upopslag

Met SQL Server back-up- en hersteltechnologie vereist het herstellen van een database naar een bepaald tijdstip een ononderbroken back-upketen. Deze keten bestaat uit één volledige back-up, optioneel één differentiële back-up en een of meer back-ups van transactielogboeken.

Azure SQL Managed Instance back-upschema's bevatten elke week één volledige back-up. Om pitr binnen de gehele retentieperiode te bieden, moet het systeem aanvullende volledige, differentiële en transactielogboekback-ups opslaan voor maximaal een week langer dan de geconfigureerde bewaarperiode.

Met andere woorden, voor elk tijdstip tijdens de retentieperiode moet er een volledige back-up zijn die ouder is dan de oudste tijd van de retentieperiode. Er moet ook een ononderbroken keten van differentiële en transactielogboekback-ups zijn vanaf die volledige back-up tot de volgende volledige back-up.

Back-ups die niet meer nodig zijn om pitr-functionaliteit te bieden, worden automatisch verwijderd. Omdat differentiële back-ups en logboekback-ups een eerdere volledige back-up moeten herstellen, worden alle drie de back-uptypen samen opgeschoond in wekelijkse sets.

Voor alle databases, inclusief met TDE versleutelde databases, worden back-ups gecomprimeerd om de compressie en kosten van back-upopslag te verminderen. De gemiddelde back-upcompressieverhouding is 3 tot 4 keer. Het kan echter aanzienlijk lager of hoger zijn, afhankelijk van de aard van de gegevens en of gegevenscompressie wordt gebruikt in de database.

Azure SQL Managed Instance berekent uw totale gebruikte back-upopslag als een cumulatieve waarde. Elk uur wordt deze waarde gerapporteerd aan de Azure-factureringspijplijn. De pijplijn is verantwoordelijk voor het aggregeren van dit gebruik per uur om uw verbruik aan het einde van elke maand te berekenen. Nadat de database is verwijderd, neemt het verbruik af naarmate back-ups ouder worden en worden verwijderd. Nadat alle back-ups zijn verwijderd en pitr niet meer mogelijk is, stopt de facturering.

Belangrijk

Back-ups van een database worden bewaard om pitr te bieden, zelfs als de database is verwijderd. Hoewel het verwijderen en opnieuw maken van een database opslag- en rekenkosten kan besparen, kan dit de kosten voor back-upopslag verhogen. De reden hiervoor is dat de service back-ups bewaart voor elke verwijderde database, telkens wanneer deze wordt verwijderd. Als u de back-upkosten wilt verlagen, kunt u de bewaarperiode wijzigen in 0 dagen, maar dit is alleen mogelijk voor verwijderde databases.

Gebruik van back-upopslag afstemmen

Er worden geen kosten in rekening gebracht voor het gebruik van back-upopslag tot de maximale gegevensgrootte voor de database. Overtollig opslagverbruik van back-ups is afhankelijk van de workload en de maximale grootte van de afzonderlijke databases. Overweeg enkele van de volgende afstemmingstechnieken om het verbruik van back-upopslag te verminderen:

  • Beperk de bewaarperiode voor back-ups tot het minimum voor uw behoeften.
  • Vermijd het vaker uitvoeren van grote schrijfbewerkingen, zoals herbouwen van indexen, dan nodig is.
  • Voor het laden van grote gegevens kunt u overwegen geclusterde columnstore-indexen te gebruiken en verwante aanbevolen procedures te volgen. Overweeg ook het aantal niet-geclusterde indexen te verminderen.
  • In de Algemeen servicelaag is de ingerichte gegevensopslag goedkoper dan de prijs van de back-upopslag. Als u voortdurend hoge overtollige kosten voor back-upopslag hebt, kunt u overwegen om de gegevensopslag te verhogen om te besparen op de back-upopslag.
  • Gebruik tempdb in plaats van permanente tabellen in uw toepassingslogica voor het opslaan van tijdelijke resultaten of tijdelijke gegevens.
  • Gebruik waar mogelijk lokaal redundante back-upopslag (bijvoorbeeld ontwikkel-/testomgevingen).

Back-upretentie

Azure SQL Managed Instance biedt zowel kortetermijn- als langetermijnretentie van back-ups. Kortetermijnretentie maakt pitr mogelijk binnen de retentieperiode voor de database. Langetermijnretentie biedt back-ups voor verschillende nalevingsvereisten.

Retentie voor de korte termijn

Voor alle nieuwe, herstelde en gekopieerde databases behoudt Azure SQL Managed Instance standaard voldoende back-ups om pitr in de afgelopen 7 dagen toe te staan. De service maakt regelmatig volledige, differentiële en logboekback-ups om ervoor te zorgen dat databases herstelbaar zijn op elk tijdstip binnen de retentieperiode die is gedefinieerd voor de database of het beheerde exemplaar.

U kunt de redundantieoptie voor back-upopslag voor STR opgeven wanneer u uw exemplaar maakt en deze vervolgens op een later tijdstip wijzigen. Als u de optie voor back-upredundantie wijzigt nadat uw exemplaar is gemaakt, wordt de nieuwe redundantieoptie gebruikt voor nieuwe back-ups. Back-ups die zijn gemaakt met de vorige optie str-redundantie, worden niet verplaatst of gekopieerd. Ze blijven in het oorspronkelijke opslagaccount staan totdat de bewaarperiode is verstreken, wat 1 tot 35 dagen kan zijn.

U kunt de bewaarperiode voor back-ups wijzigen voor elke actieve database in het bereik van 1 tot 35 dagen. Zoals beschreven in Verbruik van back-upopslag, kunnen back-ups die zijn opgeslagen om PITR in te schakelen, ouder zijn dan de retentieperiode.

Als u een database verwijdert, bewaart het systeem back-ups op dezelfde manier als voor een onlinedatabase met de specifieke bewaarperiode. Voor een verwijderde database wordt de bewaarperiode echter bijgewerkt van 1-35 dagen naar 0-35 dagen, waardoor het mogelijk is om back-ups handmatig te verwijderen. Als u back-ups langer wilt bewaren dan de maximale kortetermijnretentieperiode van 35 dagen, kunt u langetermijnretentie inschakelen.

Belangrijk

Als u een beheerd exemplaar verwijdert, worden alle databases op dat beheerde exemplaar ook verwijderd en kunnen ze niet worden hersteld. U kunt een verwijderd beheerd exemplaar niet herstellen. Maar als u langetermijnretentie hebt geconfigureerd voor een beheerd exemplaar, worden LTR-back-ups niet verwijderd. U kunt deze back-ups vervolgens gebruiken om databases te herstellen naar een ander beheerd exemplaar in hetzelfde abonnement, naar een tijdstip waarop een LTR-back-up is gemaakt. Zie Back-up op lange termijn herstellen voor meer informatie.

Lange bewaartermijn

Met SQL Managed Instance kunt u volledige LTR-back-ups configureren voor maximaal 10 jaar in Azure Blob Storage. Nadat het LTR-beleid is geconfigureerd, worden volledige back-ups wekelijks automatisch gekopieerd naar een andere opslagcontainer.

Om te voldoen aan verschillende nalevingsvereisten, kunt u verschillende bewaarperioden selecteren voor wekelijkse, maandelijkse en/of jaarlijkse volledige back-ups. De frequentie is afhankelijk van het beleid. Met de instelling W=0, M=1 wordt bijvoorbeeld maandelijks een LTR-kopie gemaakt. Zie Langetermijnretentie voor meer informatie over LTR.

Redundantie van LTR-back-upopslag in Azure SQL Managed Instance wordt overgenomen van de redundantie van back-upopslag die door STR wordt gebruikt op het moment dat het LTR-beleid wordt gedefinieerd. U kunt deze niet wijzigen, zelfs niet als de redundantie van de STR-back-upopslag in de toekomst verandert.

Gebruik van opslag is afhankelijk van de frequentie waarmee LTR-back-ups worden gemaakt en de retentieperioden ervan. U kunt de LTR-prijscalculator gebruiken om de kosten van LTR-opslag te schatten.

Kosten voor back-upopslag

Azure SQL Managed Instance berekent uw totale factureerbare back-upopslag als een cumulatieve waarde voor alle back-upbestanden. Elk uur wordt deze waarde gerapporteerd aan de Azure-factureringspijplijn. De pijplijn aggregeert dit gebruik per uur om uw verbruik van back-upopslag aan het einde van elke maand op te halen.

Als een database wordt verwijderd, neemt het verbruik van back-upopslag geleidelijk af naarmate oudere back-ups ouder worden en worden verwijderd. Omdat differentiële back-ups en logboekback-ups een eerdere volledige back-up moeten herstellen, worden alle drie de back-uptypen samen opgeschoond in wekelijkse sets. Nadat alle back-ups zijn verwijderd, stopt de facturering.

De prijs voor back-upopslag varieert. Dit is afhankelijk van de gekozen redundantieoptie voor back-upopslag en uw regio. Back-upopslag wordt in rekening gebracht op basis van gigabytes die per maand worden verbruikt, tegen hetzelfde tarief voor alle back-ups.

Redundantie van back-upopslag beïnvloedt de back-upkosten op de volgende manier:

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2
  • Geo-zone-redundant price = published price x 3.4

Raadpleeg de pagina Azure SQL Managed Instance prijzen voor prijzen.

Notitie

Een Azure-factuur toont alleen het overtollige verbruik van back-upopslag, niet het volledige verbruik van back-upopslag. Als u bijvoorbeeld in een hypothetisch scenario 4 TB aan gegevensopslag hebt ingericht, krijgt u 4 TB gratis opslagruimte voor back-ups. Als u in totaal 5,8 TB aan back-upopslagruimte gebruikt, wordt op de Azure-factuur slechts 1,8 TB weergegeven, omdat er alleen kosten in rekening worden gebracht voor overtollige back-upopslag die u hebt gebruikt.

Voor beheerde exemplaren wordt de totale grootte van factureerbare back-upopslag geaggregeerd op exemplaarniveau en als volgt berekend:

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage

De totale factureerbare back-upopslag, indien van toepassing, wordt in gigabytes per maand in rekening gebracht voor elke regio, afhankelijk van het tarief van de redundantie van de back-upopslag die u hebt gebruikt. Het verbruik van back-upopslag is afhankelijk van de workload en grootte van afzonderlijke databases en beheerde exemplaren. Sterk gewijzigde databases hebben grotere differentiële en logboekback-ups, omdat de grootte van deze back-ups evenredig is met de hoeveelheid gewijzigde gegevens. Daarom worden voor dergelijke databases hogere back-upkosten in rekening gebracht.

Als vereenvoudigd voorbeeld wordt ervan uitgegaan dat een database 744 GB aan back-upopslag heeft verzameld en dat deze hoeveelheid gedurende een hele maand constant blijft omdat de database volledig inactief is. Als u dit cumulatieve opslagverbruik wilt converteren naar gebruik per uur, deelt u dit door 744,0 (31 dagen per maand keer 24 uur per dag). SQL Managed Instance rapporteert aan de Azure-factureringspijplijn dat de database elk uur 1 GB aan PITR-back-up heeft verbruikt, met een constant tarief. Met Azure-facturering wordt dit verbruik geaggregeerd en wordt een gebruik van 744 GB voor de hele maand weergegeven. De kosten zijn gebaseerd op het tarief voor gigabytes per maand in uw regio.

Hier volgt nog een voorbeeld. Stel dat de retentie van dezelfde niet-actieve database is verhoogd van 7 dagen naar 14 dagen in het midden van de maand. Door deze toename verdubbelt de totale back-upopslag tot 1488 GB. SQL Managed Instance rapporteert 1 GB gebruik voor de uren 1 tot en met 372 (de eerste helft van de maand). Het zou het gebruik rapporteren als 2 GB voor de uren 373 tot en met 744 (de tweede helft van de maand). Dit gebruik wordt geaggregeerd tot een eindfactuur van 1116 GB per maand. Retentiekosten nemen niet onmiddellijk toe. Ze nemen elke dag geleidelijk toe, omdat de back-ups groeien totdat ze de maximale bewaarperiode van 14 dagen bereiken.

Werkelijke factureringsscenario's voor back-ups zijn complexer. Omdat de snelheid van wijzigingen in de database afhankelijk is van de workload en in de loop van de tijd variabel is, varieert de grootte van elke differentiële back-up en logboekback-up ook. Het uurverbruik van back-upopslag fluctueert dienovereenkomstig.

Elke differentiële back-up bevat ook alle wijzigingen in de database sinds de laatste volledige back-up. De totale grootte van alle differentiële back-ups neemt dus geleidelijk toe in de loop van een week. Vervolgens daalt het sterk nadat een oudere set volledige, differentiële en logboekback-ups is verouderd.

Stel dat een zware schrijfactiviteit, zoals het herbouwen van indexen, wordt uitgevoerd net nadat een volledige back-up is voltooid. De wijzigingen die de index opnieuw maakt, worden vervolgens opgenomen:

  • In het transactielogboek worden back-ups gemaakt over de duur van de herbouw.
  • In de volgende differentiële back-up.
  • In elke differentiële back-up die wordt gemaakt totdat de volgende volledige back-up plaatsvindt.

Voor het laatste scenario in grotere databases maakt een optimalisatie in de service een volledige back-up in plaats van een differentiële back-up als een differentiële back-up anders te groot zou zijn. Dit vermindert de grootte van alle differentiële back-ups tot de volgende volledige back-up.

Kosten bewaken

Als u inzicht wilt in de kosten van back-upopslag, gaat u naar Kostenbeheer en facturering in de Azure Portal. Selecteer Cost Management en selecteer vervolgens Kostenanalyse. Selecteer het gewenste abonnement voor Bereik en filter vervolgens als volgt op de periode en service waarin u geïnteresseerd bent:

  1. Voeg een filter toe voor Servicenaam.

  2. Selecteer in de vervolgkeuzelijst sql Managed Instance voor een beheerd exemplaar.

  3. Voeg nog een filter toe voor de subcategorie Meter.

  4. Als u de kosten van PITR-back-ups wilt bewaken, selecteert u in de vervolgkeuzelijst de optie Back-upopslag voor beheerde exemplaren. Meters worden alleen weergegeven als er sprake is van back-upopslagverbruik.

    Als u de kosten voor LTR-back-ups wilt bewaken, selecteert u sql Managed Instance - ltr Backup Storage in de vervolgkeuzelijst. Meters worden alleen weergegeven als er sprake is van back-upopslagverbruik.

De subcategorieën Opslag en rekenkracht kunnen ook interessant voor u zijn, maar deze zijn niet gekoppeld aan de kosten voor back-upopslag.

Schermopname van een analyse van de kosten van back-upopslag.

Belangrijk

Meters zijn alleen zichtbaar voor tellers die momenteel in gebruik zijn. Als er geen teller beschikbaar is, wordt de categorie waarschijnlijk momenteel niet gebruikt. Zo zijn er geen tellers voor beheerde exemplaren beschikbaar voor klanten die geen beheerd exemplaar hebben geïmplementeerd. Opslagitems zijn ook niet zichtbaar voor resources die geen opslag gebruiken. Als er geen verbruik van PITR- of LTR-back-upopslag is, zijn deze meters niet zichtbaar.

Versleutelde back-ups

Als uw database is versleuteld met TDE, worden back-ups automatisch at-rest versleuteld, inclusief de LTR-back-ups. Elke nieuwe database in Azure SQL is standaard geconfigureerd met TDE ingeschakeld. Zie Transparent data encryption with SQL Managed Instance (Transparante gegevensversleuteling met SQL Managed Instance) voor meer informatie over TDE.

Back-upintegriteit

Alle databaseback-ups worden gemaakt met de optie CHECKSUM om extra back-upintegriteit te bieden. Het automatisch testen van automatische databaseback-ups door het technische team van Azure SQL is momenteel niet beschikbaar voor Azure SQL Managed Instance. Plan herstel van testback-ups en DBCC CHECKDB voor uw databases in SQL Managed Instance rond uw workload.

Hoewel het systeem de integriteit van de back-ups niet verifieert, is er nog steeds ingebouwde beveiliging van uw back-ups die Microsoft waarschuwt als er een probleem is met de back-upservice. Daarnaast ondersteunt Microsoft u als er een probleem optreedt met een back-up, bijvoorbeeld als er geen volledige back-up wordt gemaakt, de back-upservice vastloopt, een logboekback-up niet meer voldoet aan de SLA of als de back-uphardware of -software beschadigd is.

Gebruik Azure Policy om redundantie van back-upopslag af te dwingen

Als u vereisten voor gegevenslocatie hebt die vereisen dat u al uw gegevens in één Azure-regio bewaart, wilt u mogelijk zone-redundante of lokaal redundante back-ups afdwingen voor uw SQL Managed Instance met behulp van Azure Policy.

Azure Policy is een service die u kunt gebruiken voor het maken, toewijzen en beheren van beleidsregels die regels toepassen op Azure-resources. Azure Policy helpt u deze resources in overeenstemming te houden met uw bedrijfsstandaarden en serviceovereenkomsten. Zie Overzicht van Azure Policy voor meer informatie.

Ingebouwd redundantiebeleid voor back-upopslag

Als u vereisten voor gegevenslocatie op organisatieniveau wilt afdwingen, kunt u beleidsregels toewijzen aan een abonnement met behulp van de Azure Portal of Azure PowerShell. Als u bijvoorbeeld het volgende ingebouwde beleid toewijst op abonnements- of resourcegroepniveau, kunnen gebruikers in het abonnement geen beheerd exemplaar met geografisch redundante back-upopslag maken via de Azure Portal of Azure PowerShell: SQL Managed Instances moet het gebruik van GRS-back-upredundantie vermijden.

Raadpleeg de beleidsreferentie voor een volledige lijst met ingebouwde beleidsdefinities voor SQL Managed Instance.

Belangrijk

Azure-beleid wordt niet afgedwongen wanneer u een database maakt via T-SQL. Als u gegevenslocatie wilt afdwingen wanneer u een database maakt met behulp van T-SQL, gebruikt u LOCAL of ZONE als invoer voor de parameter BACKUP_STORAGE_REDUNDANCY in de instructie CREATE DATABASE.

Naleving

Als de standaardretentie niet voldoet aan uw nalevingsvereisten, kunt u de retentieperiode van de PITR wijzigen. Zie De retentieperiode voor pitr-back-ups wijzigen voor meer informatie.

Notitie

Het artikel Instellingen voor automatische back-up wijzigen bevat stappen voor het verwijderen van persoonsgegevens van het apparaat of de service en kan worden gebruikt ter ondersteuning van uw verplichtingen onder de AVG. Zie de AVG-sectie van het Vertrouwenscentrum van Microsoft en de AVG-sectie van de Service Trust-portal voor algemene informatie over de AVG.

Volgende stappen

  • Zie Overzicht van bedrijfscontinuïteit voor meer informatie over de andere oplossingen voor SQL Managed Instance bedrijfscontinuïteit.
  • Zie Langetermijnretentie van back-ups beheren met behulp van de Azure Portal voor informatie over het configureren, beheren en herstellen van langetermijnretentie van automatische back-ups in Azure Blob Storage met behulp van de Azure Portal.
  • Zie Langetermijnretentie van back-ups beheren met behulp van PowerShell voor informatie over het configureren, beheren en herstellen van langetermijnretentie van automatische back-ups in Azure Blob Storage met behulp van PowerShell.
  • Zie Herstellen met geautomatiseerde databaseback-ups voor meer informatie over het herstellen van een database naar een bepaald tijdstip met behulp van de Azure Portal.
  • Zie Verbruik van back-upopslag op SQL Managed Instance uitgelegd voor meer informatie over het verbruik van back-upopslag op Azure SQL Managed Instance.
  • Zie Kosten voor back-upopslag op SQL Managed Instance afstemmen voor meer informatie over het afstemmen van de retentie van back-upopslag en de kosten voor SQL Managed Instance.