Geautomatiseerde back-ups in Azure SQL Managed Instance

  • Artikel

Van toepassing op: Azure SQL Managed Instance

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

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

Wat zijn geautomatiseerde databaseback-ups?

Databaseback-ups zijn een essentieel onderdeel van elke strategie voor bedrijfscontinuïteit en herstel na noodgevallen, omdat ze uw gegevens helpen beschermen tegen beschadiging of verwijdering. Azure SQL Managed Instance biedt volledig beheerde en geautomatiseerde back-ups van SQL Server-database-engine. Met deze back-ups kunt u database herstellen naar een bepaald tijdstip binnen de geconfigureerde bewaarperiode, tot 35 dagen. Als uw regels voor gegevensbeveiliging echter vereisen dat uw back-ups gedurende een langere periode (maximaal 10 jaar) beschikbaar zijn, kunt u beleidsregels voor langetermijnretentie (LTR) per database configureren.

Back-upfrequentie

Azure SQL Managed Instance maakt:

De frequentie van back-ups van transactielogboeken is afhankelijk van de rekenkracht en de hoeveelheid databaseactiviteit. Transactielogboeken worden ongeveer om de 10 minuten genomen, maar kunnen variëren. Wanneer u een database herstelt, bepaalt de service in hun respectieve volgorde welke volledige, differentiële en transactielogboekback-ups moeten worden hersteld.

Opslagredundantie voor back-ups

Azure SQL Managed Instance slaat standaard gegevens op in geografisch redundante opslagblobs die worden gerepliceerd naar een gekoppelde regio. Met georedundantie kunt u bescherming bieden tegen storingen die van invloed zijn op back-upopslag in de primaire regio. Ook kunt u uw exemplaar 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 hardwarefouten, netwerk- of stroomstoringen of enorme natuurrampen omvatten.

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

U kunt redundantie van back-upopslag configureren wanneer u uw exemplaar maakt en u kunt deze op een later tijdstip bijwerken op exemplaarniveau. De wijzigingen die u aanbrengt in een bestaand exemplaar, zijn alleen van toepassing op toekomstige back-ups. Nadat u de redundantie van de 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. Beleidsregels voor langetermijnretentie nemen de redundantieoptie van back-ups op korte termijn over wanneer het beleid wordt gemaakt. De redundantieoptie blijft behouden voor back-ups op lange termijn, zelfs als de redundantieoptie voor back-ups op korte termijn vervolgens wordt gewijzigd.

Notitie

Houd er rekening mee dat de wijziging van de back-upredundantie 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 synchroon drie keer 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 showing the locally redundant storage (LRS) option.

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

    Diagram showing the zone-redundant storage (ZRS) option.

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

    Het resultaat is:

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

    Diagram showing the geo-redundant storage (GRS) option.

  • 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 in één beschikbaarheidszone die asynchroon zijn gekopieerd van de primaire regio naar de secundaire regio.

    Diagram showing the geo-zone-redundant storage (GZRS) option.

Waarschuwing

  • Geo-herstel is uitgeschakeld zodra een database wordt bijgewerkt om lokaal redundante of zone-redundante opslag te gebruiken.
  • De opslagredundantiediagrammen geven allemaal regio's weer 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 bewaarperiode met behulp van 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 azure Portal ook gebruiken om de back-up van uw 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 oorspronkelijke databasenaam.

  • Herstel een verwijderde database naar een bepaald tijdstip binnen de bewaarperiode, inclusief het tijdstip van verwijdering. U kunt de verwijderde database herstellen naar hetzelfde beheerde exemplaar waar 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 een bestaand beheerd exemplaar in elke 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.

  • Herstel een database vanuit een langetermijnback-up van een database als de database een geconfigureerd LTR-beleid heeft. Met LTR kunt u een oudere versie van de database herstellen met behulp van 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. Raadpleeg de overzichtspagina voor langetermijnretentie voor meer informatie.

Mogelijkheden en functies herstellen

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

Back-up-eigenschappen  PITR Geo-herstel LTR
Typen back-ups van SQL Volledige, differentiële en back-ups van transactielogboeken. Gerepliceerde kopieën van PITR-back-ups. Alleen volledige back-ups.
Recovery Point Objective (RPO)  Ongeveer 10 minuten, op basis van de rekenkracht en de hoeveelheid databaseactiviteit.   Maximaal 1 uur, op basis van geo-replicatie. 1    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. 2 Hoge beschikbaarheid is standaard niet 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 zone-redundant of lokaal redundant is.  Geografisch redundant standaard. U kunt zone-redundante of lokaal redundante opslag configureren.
Back-ups configureren als onveranderbaar Niet ondersteund Niet ondersteund Niet ondersteund
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 3 Niet ondersteund 3
Herstellen via Azure Portal Ja Ja Ja
Herstellen via PowerShell Ja Ja Ja
Herstellen via Azure CLI Ja Ja Ja

1 Voor bedrijfskritieke toepassingen die grote databases vereisen en bedrijfscontinuïteit moeten garanderen, raadpleegt u failovergroepen.

2 Alle PITR-back-ups worden standaard opgeslagen op geografisch redundante opslag, wat betekent dat geo-herstel standaard is ingeschakeld.

3 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 om een herstelbewerking uit te voeren. U kunt back-upconfiguratie- en herstelbewerkingen proberen met behulp van de volgende voorbeelden.

Operation 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 vanuit Azure Blob Storage SQL Managed Instance

Schema voor automatische back-ups

Met Azure SQL Managed Instance worden back-ups automatisch beheerd door volledige back-ups, differentiële back-ups en transactielogboeken te maken. Dit proces wordt beheerd door een interne planning.

Eerste back-up

  • Nieuwe databases: Onmiddellijk nadat een database is gemaakt, hersteld of back-upredundantiewijzigingen ondergaat, wordt de eerste volledige back-up gestart. Deze back-up wordt doorgaans binnen 30 minuten voltooid, hoewel het langer kan duren voor grotere databases.

  • Herstelde databases: de duur van de eerste back-up voor herstelde databases varieert en is afhankelijk van de grootte van de database. Herstelde databases of databasekopieën, die vaak groter zijn, vereisen mogelijk meer tijd voor de eerste back-up.

Geplande volledige back-ups

  • Wekelijks schema: Het systeem stelt een wekelijks volledig back-upvenster in voor het hele exemplaar.
  • Volledig back-upvenster: dit is een aangewezen periode waarin volledige back-ups worden uitgevoerd. Hoewel het systeem is gericht op het voltooien van volledige back-ups in dit venster, kan de back-up, indien nodig, verdergaan dan de geplande tijd totdat deze is voltooid.
  • Adaptieve planning: het back-upalgoritmen evalueren de impact van het back-upvenster op de werkbelasting ongeveer één keer per week, met behulp van CPU-gebruik en I/O-doorvoer als indicatoren. Afhankelijk van de workload van de vorige week kan het volledige back-upvenster worden aangepast.
  • Gebruikersconfiguratie: het is van cruciaal belang dat gebruikers het back-upschema niet kunnen wijzigen of uitschakelen.

Belangrijk

Voor een nieuwe, herstelde of gekopieerde database is de mogelijkheid voor herstel naar een bepaald tijdstip (PITR) beschikbaar wanneer de eerste back-up van het transactielogboek na de eerste volledige back-up wordt gemaakt.

Back-upopslagverbruik

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

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

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

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 worden hersteld, worden alle drie de back-uptypen samen in wekelijkse sets opgeschoond.

Voor alle databases, inclusief met TDE versleutelde databases, worden alle volledige en differentiële back-ups gecomprimeerd om de compressie en kosten van back-upopslag te verminderen. De gemiddelde verhouding voor back-upcompressie 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.

Belangrijk

Voor met TDE versleutelde databases worden logboekback-upsbestanden niet gecomprimeerd om prestatieredenen. Logboekback-ups voor niet-TDE-versleutelde databases worden gecomprimeerd.

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 uurgebruik 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 voor een verwijderde database worden bewaard voor herstel naar een bepaald tijdstip (PITR), waardoor de opslagkosten kunnen worden verhoogd naarmate back-ups worden bewaard, ook al wordt de database verwijderd. Als u de kosten wilt verlagen, kunt u de bewaarperiode voor back-ups instellen op 0 dagen, maar alleen voor verwijderde databases. Voor reguliere databases is de minimale bewaarperiode 1 dag.

Gebruik van back-upopslag afstemmen

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

  • Verminder de bewaarperiode voor databaseback-ups tot het minimum voor uw behoeften.
  • Vermijd het uitvoeren van grote schrijfbewerkingen, zoals het opnieuw opbouwen van indexen, vaker dan nodig is.
  • Voor grote bewerkingen voor het laden van gegevens kunt u overwegen om geclusterde columnstore-indexen te gebruiken en de volgende gerelateerde aanbevolen procedures te volgen. Overweeg ook het aantal niet-geclusterde indexen te verminderen.
  • In de servicelaag Algemeen gebruik is de ingerichte gegevensopslag goedkoper dan de prijs van de back-upopslag. Als u voortdurend hoge kosten voor overtollige back-upopslag hebt, kunt u overwegen om de gegevensopslag te verhogen om op de back-upopslag te besparen.
  • 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 staat PITR toe binnen de bewaarperiode 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 voldoende back-ups om pitr in de afgelopen 7 dagen standaard toe te staan. Deze configuratie kan worden gewijzigd in het bereik van 1 tot 35 dagen. De service maakt regelmatig gebruik van volledige, differentiële en logboekback-ups om ervoor te zorgen dat databases kunnen worden overgeslagen naar een bepaald 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 later wijzigen. Als u de optie voor back-upredundantie wijzigt nadat uw exemplaar is gemaakt, gebruiken nieuwe back-ups de nieuwe redundantieoptie. Back-ups die zijn gemaakt met de vorige str-redundantieoptie, worden niet verplaatst of gekopieerd. Ze blijven in het oorspronkelijke opslagaccount staan totdat de bewaarperiode verloopt. Zoals beschreven in het verbruik van back-upopslag, zijn back-ups die zijn opgeslagen om PITR in te schakelen mogelijk ouder dan de bewaarperiode om ervoor te zorgen dat gegevens nauwkeurig worden hersteld.

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 tot 0-35 dagen, zodat back-ups handmatig kunnen worden verwijderd. Als u back-ups langer wilt bewaren dan de maximale korte bewaarperiode 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 voor een beheerd exemplaar hebt geconfigureerd, worden LTR-back-ups niet verwijderd. Vervolgens kunt u deze back-ups gebruiken om databases te herstellen naar een ander beheerd exemplaar in hetzelfde abonnement, naar een tijdstip waarop een LTR-back-up is gemaakt. Voor meer informatie raadpleegt u Back-up op lange termijn herstellen.

Langetermijnretentie (LTR)

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

Als u wilt 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, Y=0 wordt bijvoorbeeld een maandelijkse 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 is 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 opslag van back-ups

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 voegt dit gebruik per uur samen om het verbruik van de back-upopslag aan het einde van elke maand te verkrijgen.

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 worden hersteld, worden alle drie de back-uptypen samen in wekelijkse sets opgeschoond. 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, met hetzelfde tarief voor alle back-ups.

Redundantie van back-upopslag is op de volgende manier van invloed op de back-upkosten:

  • 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 met prijzen voor Azure SQL Managed Instance.

Notitie

Een Azure-factuur toont alleen het verbruik van overtollige 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 opslagruimte voor back-ups gebruikt, wordt in 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 wordt deze 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. Dergelijke databases hebben daarom hogere back-upkosten.

Als vereenvoudigd voorbeeld wordt ervan uitgegaan dat een database 744 GB aan back-upopslag heeft verzameld en dat dit bedrag gedurende een hele maand constant blijft omdat de database volledig inactief is. Als u dit cumulatieve opslagverbruik wilt converteren naar het 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 pitr-back-up heeft verbruikt, met een constante snelheid. Azure-facturering voegt dit verbruik samen en toont een gebruik van 744 GB voor de hele maand. 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 tot 14 dagen midden in de maand. Deze toename resulteert in een verdubbeling van de totale back-upopslag tot 1488 GB. Sql Managed Instance rapporteert 1 GB aan gebruik voor uren 1 tot en met 372 (de eerste helft van de maand). Het zou het gebruik rapporteren als 2 GB voor uren 373 tot en met 744 (de tweede helft van de maand). Dit gebruik wordt samengevoegd tot een definitieve factuur van 1116 GB per maand. Retentiekosten nemen niet onmiddellijk toe. Ze nemen elke dag geleidelijk toe, omdat de back-ups toenemen totdat ze de maximale bewaarperiode van 14 dagen bereiken.

Werkelijke back-upfactureringsscenario's 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 gedurende een week. Vervolgens daalt het scherp nadat een oudere set volledige, differentiële en logboekback-ups verouderd is.

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

  • In de back-ups van het transactielogboek zijn de duur van de herbouwing overgenomen.
  • In de volgende differentiële back-up.
  • In elke differentiële back-up die wordt gemaakt totdat de volgende volledige back-up plaatsvindt.

Als u de grootte van alle differentiële back-ups wilt verkleinen, worden grote differentiële back-ups die groter zijn dan 750 GB en gelijk zijn aan 75% van de databasegrootte gepromoveerd naar volledige back-ups, als de laatste volledige back-up meer dan 24 uur geleden is gemaakt.

Kosten bewaken

Als u inzicht wilt in de kosten voor back-upopslag, gaat u naar Kostenbeheer en facturering in Azure Portal. Selecteer Cost Management en selecteer vervolgens Kostenanalyse. Selecteer het gewenste abonnement voor Bereik en filter vervolgens 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 metersubcategorie.

  4. Als u de back-upkosten van pitr wilt bewaken, selecteert u in de vervolgkeuzelijst back-upopslag van beheerde exemplaren. Meters worden alleen weergegeven als het back-upopslagverbruik bestaat.

    Als u de kosten voor LTR-back-ups wilt bewaken, selecteert u in de vervolgkeuzelijst sql Managed Instance - ltr-back-upopslag. Meters worden alleen weergegeven als het back-upopslagverbruik bestaat.

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

Screenshot that shows an analysis of backup storage costs.

Belangrijk

Meters zijn alleen zichtbaar voor tellers die momenteel in gebruik zijn. Als een teller niet beschikbaar is, is het waarschijnlijk dat de categorie momenteel niet wordt gebruikt. Er zijn bijvoorbeeld geen items voor beheerde exemplaren aanwezig voor klanten die geen beheerd exemplaar hebben geïmplementeerd. Op dezelfde manier zijn opslagtellers niet zichtbaar voor resources die geen opslag gebruiken. Als er geen PITR- of LTR-back-upopslagverbruik 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 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. Automatische tests van automatische databaseback-ups door het technische team van Azure SQL zijn momenteel niet beschikbaar voor Azure SQL Managed Instance. Plan herstel van testback-ups en DBCC CHECKDB op uw databases in SQL Managed Instance rond uw workload.

Hoewel het systeem de integriteit van de back-ups niet controleert, is er nog steeds ingebouwde beveiliging van uw back-ups die Microsoft waarschuwen 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 in de SLA staat of als de back-uphardware of software beschadigd is.

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

Als u vereisten voor gegevenslocatie hebt waarvoor u al uw gegevens in één Azure-regio moet bewaren, kunt u zone-redundante of lokaal redundante back-ups afdwingen voor uw met SQL beheerde exemplaar met behulp van Azure Policy.

Azure Policy is een service die u kunt gebruiken om beleidsregels te maken, toe te wijzen en te beheren die regels toepassen op Azure-resources. Azure Policy helpt u om deze resources te laten voldoen aan 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 beleid toewijzen aan een abonnement met behulp van 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 maken met geografisch redundante back-upopslag via Azure Portal of Azure PowerShell: SQL Managed Instances moet voorkomen dat GRS-back-upredundantie wordt gebruikt.

Raadpleeg de beleidsverwijzing 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 bewaarperiode voor de pitr wijzigen. Zie De bewaarperiode voor back-ups van pitr wijzigen voor meer informatie.

Notitie

Het artikel Automatische back-upinstellingen wijzigen bevat stappen over het verwijderen van persoonlijke gegevens van het apparaat of de service en kan worden gebruikt om uw verplichtingen onder de AVG te ondersteunen. Zie voor algemene informatie over AVG de AVG-sectie van het Vertrouwenscentrum van Microsoft en de AVG-sectie van de Service Trust Portal.

Volgende stappen