Delen via

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 wijzigenals u de back-upinstellingen wilt wijzigen. Zie Herstellen met behulp van geautomatiseerde databaseback-upsals u een back-up wilt herstellen.

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. Met Azure SQL Managed Instance worden back-ups van SQL Server-database-engine automatisch beheerd door Microsoft en opgeslagen in door Microsoft beheerde Azure-opslagaccounts.

Gebruik deze back-ups om uw database te 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 langetermijnretentiebeleid (LTR) configureren beleidsregels per database.

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.

Voorzichtigheid

Automatische volledige back-ups worden eenmaal per week gestart op basis van een schema dat door Microsoft wordt bepaald. door de gebruiker geïnitieerde back-ups prioriteit hebben ten opzichte van automatische volledige back-ups, zodat een langlopende back-up alleen-kopiëren van invloed kan zijn op de timing van de volgende automatische volledige back-up.

Backup redundantie van opslag

In Azure SQL Managed Instance worden standaard back-ups opgeslagen 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. U kunt ook uw instantie herstellen naar een andere regio in geval van een ramp.

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 Gegevensredundantievoor 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

Het wijzigen van back-upredundantie is een updatebeheerbewerking waarmee een failover wordt gestart.

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

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

Waarschuwing

  • Geo-herstel is uitgeschakeld zodra een database is 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 sommige regio's die slechts één beschikbaarheidszone bieden en geen ondersteuning bieden voor ZRS of GZRS.

Backupgebruik

U kunt deze back-ups gebruiken om:

  • een bestaande database herstellen 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 ook de Azure portal gebruiken om een point-in-time-herstel van uw database-back-up uit te voeren naar een exemplaar in een ander abonnement dan uw bronexemplaar.

    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.

  • een verwijderde database herstellen 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 naar een ander exemplaar binnen hetzelfde, of een ander abonnement dan het bronexemplaar. Voordat u een database verwijdert, maakt de service een laatste back-up van het transactielogboek om gegevensverlies te voorkomen.

  • Een database herstellen in een andere geografische regio. Met geo-herstel kunt u herstellen na een geografische 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 dit wijzigen door redundantie van back-upopslag te configureren.

  • een database herstellen vanuit een back-up op lange termijn 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 het overzicht van langetermijnretentie pagina 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-herstelen langetermijnretentie.

Backup-eigenschappen PITR Geo-herstel LTR
Typen SQL-backup Volledige back-ups, differentiële back-ups en transactielogboek-back-ups. Gerepliceerde kopieën van PITR-back-ups. Alleen volledige back-ups.
Herstelpuntdoelstelling (RPO) Ongeveer 10 minuten, op basis van de rekenkracht en de hoeveelheid databaseactiviteit. Tot maximaal 1 uur, afhankelijk van geo-replicatie. 1 Eén week (of het beleid van de gebruiker).
Hersteltijddoelstelling (RTO) Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Recovery. Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Recovery. Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Recovery.
retentie 1 tot 35 dagen. Standaard ingeschakeld, hetzelfde als de bron. 2 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 de redundantie van PITR-back-upopslag is ingesteld op georedundante. Niet beschikbaar wanneer PITR-back-upopslag zone-redundant of lokaal redundant is. Standaard geografisch redundant. U kunt zone-redundante of lokaal redundante opslag configureren.
back-ups instellen als onveranderbaar Niet ondersteund Niet ondersteund Niet ondersteund
Beleid bijwerken3 Moet overeenstemmen, of bijwerken Moet overeenstemmen, of bijwerken Moet overeenstemmen, of bijwerken
een nieuwe database herstellen in dezelfde regio 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 4 Niet ondersteund 4
herstellen via Azure Portal Ja Ja Ja
Herstellen via PowerShell Ja Ja Ja
herstellen via Azure CLI Ja Ja Ja

1 Voor bedrijfskritieke toepassingen waarvoor grote databases nodig zijn en die bedrijfscontinuïteit moeten garanderen, raadpleegt u failovergroepen.
2 Alle PITR-back-ups worden standaard opgeslagen in geografisch redundante opslag, wat betekent dat geo-herstel standaard is ingeschakeld.
3 Database-back-ups die zijn gemaakt van exemplaren die zijn geconfigureerd met het update beleid van SQL Server 2022 kunnen worden hersteld naar exemplaren die zijn geconfigureerd met het SQL Server 2022- of Always-up-to-datumupdatebeleid. Databaseback-ups die zijn gemaakt van exemplaren die zijn geconfigureerd met het beleid always-up-to-date update, kunnen alleen worden hersteld naar exemplaren die ook zijn geconfigureerd met het beleid always-up-to-date-update.
4 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-upsom een herstelbewerking uit te voeren. U kunt back-upconfiguratie- en herstelbewerkingen proberen met behulp van de volgende voorbeelden.

Operatie 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 reservekopie

Meteen nadat een database is gemaakt, hersteld of wijzigingen in back-upredundantie ondergaat, wordt de eerste volledige back-up gestart. Deze back-up wordt doorgaans binnen 30 minuten voltooid, hoewel het langer kan duren. De duur van de eerste back-up voor herstelde databases varieert en is afhankelijk van de grootte van de database. Voor grotere herstelde databases of databasekopieën is mogelijk meer tijd nodig voor de eerste back-up.

Belangrijk

De eerste volledige back-up voor een nieuwe database heeft voorrang op andere databaseback-ups, dus dit is de eerste back-up die tijdens het eerste volledige back-upvenster is gemaakt. Als het volledige back-upvenster al actief is en er een back-up van andere databases wordt gemaakt, wordt de eerste volledige back-up voor de nieuwe database gemaakt direct nadat de volledige back-up van een andere database is voltooid.

Geplande volledige back-ups

  • Wekelijkse planning: Het systeem stelt een wekelijks volledig back-upvenster in voor de gehele instantie.
  • volledige 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 nadat de eerste back-up van het transactielogboek is voltooid na de eerste volledige back-up.

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 zijn van differentiële en transactielogboekback-ups 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 logback-ups een eerdere volledige back-up vereisen om herstelbaar te zijn, worden alle drie de back-uptypen samen in wekelijkse sets verwijderd.

Voor alle databases, waaronder 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 compressieverhouding voor back-ups is 3:1 tot 4:1. Het kan echter aanzienlijk lager of hoger zijn, afhankelijk van de aard van de gegevens en of gegevenscompressie wordt gebruikt in de database.

Belangrijk

Om prestatieredenen worden de logboekback-ups bestanden van met TDE versleutelde databases niet gecomprimeerd. 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.

Verbruik van back-upopslag verfijnen

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 optimalisatietechnieken om het verbruik van uw back-upopslag te verminderen.

  • Verminder de opslagperiode van de database back-up 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 geclusterde columnstore-indexen te gebruiken en de volgende gerelateerde beste praktijken. 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).

Backupretentie

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

Kortetermijnretentie

Voor alle nieuwe, herstelde en gekopieerde databases behoudt Azure SQL Managed Instance standaard voldoende back-ups om PITR mogelijk te maken binnen de laatste 7 dagen. 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 back-upopslagverbruik, zijn back-ups die zijn opgeslagen om PITR in te schakelen mogelijk ouder dan de bewaarperiode om nauwkeurige gegevensherstel te garanderen.

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, raadpleeg Back-up voor de 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. Als u bijvoorbeeld W=0, M=1, Y=0 instelt, wordt er een maandelijkse LTR-kopie gemaakt. Zie langetermijnretentievoor 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.

Opslagverbruik is afhankelijk van de geselecteerde frequentie en retentieperioden van LTR-back-ups. 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 voegt deze gebruiksgegevens per uur samen om het verbruik van de back-upopslag aan het eind van iedere maand in kaart te brengen.

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 logback-ups een eerdere volledige back-up vereisen om herstelbaar te zijn, worden alle drie de back-uptypen samen in wekelijkse sets verwijderd. 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 voor prijsinformatie de pagina Azure SQL Managed Instance tarieven.

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-up factureringsscenario'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 sterk nadat een oudere set volledige, differentiële en logboekback-ups ongebruikt raakt.

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

  • Tijdens de herbouwing gemaakte back-ups van het transactielogboek.
  • Bij de volgende differentiële back-up.
  • Bij elke differentiële back-up die wordt gemaakt totdat de volgende volledige back-up wordt uitgevoerd.

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 tot 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 Bereiken 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 de metersubcategorievan .

  4. Als u de PITR-back-upkosten wilt controleren, selecteert u in de vervolgkeuzelijst back-upopslag van beheerde exemplaren. Meters worden alleen weergegeven als er verbruik van back-upopslag is.

    Als u de LTR-back-upkosten wilt bewaken, selecteert u in de vervolgkeuzelijst SQL Managed Instance - LTR-back-upopslag. Meters worden alleen weergegeven als er verbruik van back-upopslag is.

De Storage en compute- subcategorieën zijn mogelijk ook interessant voor u, maar deze zijn niet gekoppeld aan de kosten voor back-upopslag.

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

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. Beheertellers zullen bijvoorbeeld niet aanwezig zijn voor klanten die geen beheerd exemplaar hebben ingezet. Op dezelfde manier zijn opslagtellers niet zichtbaar voor resources die geen opslag gebruiken. Als er geen verbruik van PITR- of LTR-backupopslag is, zijn deze meters niet zichtbaar.

Versleutelde back-ups

Als uw database is versleuteld met TDE, worden back-ups automatisch versleuteld 'in rust', inclusief LTR-back-ups. Alle nieuwe databases in Azure SQL zijn standaard geconfigureerd met TDE ingeschakeld. Zie Transparent Data Encryption met SQL Managed Instancevoor meer informatie over TDE.

Microsoft is volledig verantwoordelijk voor het bewaren en roteren van sleutels voor databases met door de service beheerde sleutels (SMK). Back-ups, pitr of LTR, die afkomstig zijn van exemplaren waarvoor TDE met SMK is ingeschakeld, kunnen worden hersteld door Microsoft.

Automatische back-ups die zijn opgeslagen in door Azure beheerde opslagaccounts, worden automatisch versleuteld door Azure Storage. Meer informatie over Azure Storage-versleuteling voor gegevens in rust.

Backup-integriteit

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 Policyvoor meer informatie.

Beleid voor ingebouwde redundantie van back-upopslag

Als u vereisten voor gegevenslocatie op organisatieniveau wilt afdwingen, kunt u beleid toewijzen aan een abonnement via 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 maken met geografisch redundante back-upopslag via Azure Portal of Azure PowerShell: SQL Managed Instances moeten voorkomen dat GRS-back-upredundantiewordt gebruikt.

Raadpleeg de -beleidsverwijzingvoor 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, LOCAL of ZONE gebruiken 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 Wijzig de bewaarperiode voor PITR-back-upvoor meer informatie.

Notitie

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

Volgende stappen