Automatische back-ups in Azure SQL Database

Van toepassing op: Azure SQL Database

• Azure SQL-database
• Azure SQL Managed Instance

In dit artikel wordt de functie voor automatische back-up voor Azure SQL Database 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 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 database herstellen naar een bepaald tijdstip binnen de geconfigureerde bewaarperiode. Als uw regels voor gegevensbeveiliging vereisen dat uw back-ups gedurende een langere periode (maximaal 10 jaar) beschikbaar zijn, kunt u langetermijnretentie (LTR) configureren voor zowel individuele als pooldatabases.

Voor andere servicelagen dan Hyperscale maakt Azure SQL Database gebruik van SQL Server-enginetechnologie om een back-up te maken van gegevens en deze te herstellen. Hyperscale-databases maken gebruik van back-up en herstel op basis van momentopnamen van opslag. Met traditionele SQL Server-back-uptechnologie hebben grotere databases lange back-up- en hersteltijden. Met het gebruik van momentopnamen biedt Hyperscale directe back-up- en snelle herstelmogelijkheden, ongeacht de grootte van de database. Zie Back-ups van Hyperscale voor meer informatie.

Back-upfrequentie

Azure SQL Database maakt:

• Volledige back-ups elke week.
• Differentiële back-ups elke 12 of 24 uur.
• Back-ups van transactielogboeken worden ongeveer elke 10 minuten uitgevoerd.

De exacte frequentie van back-ups van transactielogboeken 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.

Voor de Hyperscale-architectuur zijn geen volledige, differentiële of logboekback-ups vereist. Zie Back-ups van Hyperscale voor meer informatie.

Opslagredundantie voor back-ups

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 enorme natuurrampen omvatten.

Standaard slaan nieuwe databases in Azure SQL Database back-ups 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 databases in een andere regio herstellen in het geval van een regionale storing.

Azure Portal biedt een workloadomgevingsoptie waarmee u bepaalde configuratie-instellingen kunt instellen. Deze instellingen kunnen worden overschreven. Deze optie is alleen van toepassing op de pagina SQL Database-portal maken.

• Als u de ontwikkelworkloadomgeving kiest, wordt de optie Back-upopslagredundantie ingesteld om lokaal redundante opslag te gebruiken. Lokaal redundante opslag kost minder kosten en is geschikt voor preproductieomgevingen waarvoor geen redundantie van zone- of geo-gerepliceerde opslag is vereist.
• Als u de productieworkloadomgeving kiest, wordt de redundantie van back-upopslag ingesteld op geografisch redundante opslag, de standaardinstelling.
• De optie Workloadomgeving wijzigt ook de eerste instelling voor rekenkracht, hoewel dit kan worden overschreven. Anders heeft de optie Workloadomgeving geen invloed op licenties of andere databaseconfiguratie-instellingen.

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. De geconfigureerde back-upopslagredundantie wordt toegepast op back-ups van korte termijnretentie (STR) en LTR-back-ups. Zie Gegevensredundantie voor meer informatie over opslagredundantie.

U kunt redundantie van back-upopslag configureren wanneer u uw database maakt en u kunt deze op een later tijdstip bijwerken. De wijzigingen die u in een bestaande database aanbrengt, zijn alleen van toepassing op toekomstige back-ups. Nadat u de redundantie van de back-upopslag van een bestaande database hebt bijgewerkt, kan het tot 48 uur duren voordat de wijzigingen zijn toegepast.

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 opslagoptie, maar we raden het niet aan voor toepassingen waarvoor tolerantie is vereist voor regionale storingen of een garantie voor een hoge duurzaamheid van gegevens.

  

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

  

• 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.
  • Drie synchrone kopieën in de gekoppelde regio die asynchroon zijn gekopieerd van de primaire regio naar de secundaire regio.

  

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.
• Redundantie van back-upopslag voor Hyperscale-databases kan alleen worden ingesteld tijdens het maken. U kunt deze instelling niet wijzigen nadat de resource is ingericht. Als u redundantie-instellingen voor back-upopslag wilt bijwerken voor een bestaande Hyperscale-database met minimale downtime, gebruikt u actieve geo-replicatie. U kunt ook databasekopie gebruiken. Meer informatie over Hyperscale-back-ups en opslagredundantie.

Back-upgebruik

In de volgende scenario's kunt u automatisch gemaakte back-ups gebruiken:

• Herstel een bestaande database naar een bepaald tijdstip 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 dezelfde server als de oorspronkelijke database, maar er wordt een andere naam gebruikt om te voorkomen dat de oorspronkelijke database wordt overschreven.

  Nadat het herstellen is voltooid, kunt u desgewenst de oorspronkelijke database verwijderen en de naam van de herstelde database wijzigen in de oorspronkelijke databasenaam. In plaats van de oorspronkelijke database te verwijderen, kunt u de naam ervan wijzigen en vervolgens de herstelde database wijzigen in de oorspronkelijke databasenaam.

• Herstel een verwijderde database naar een bepaald tijdstip binnen de bewaarperiode, inclusief het tijdstip van verwijdering. De verwijderde database kan alleen worden hersteld op dezelfde server waarop u de oorspronkelijke database hebt gemaakt. 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 regionale storing wanneer u geen toegang hebt tot uw database of back-ups in de primaire regio. Er wordt een nieuwe database gemaakt op elke bestaande server 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 specifieke langetermijnback-up van een individuele of pooldatabase als de database is geconfigureerd met een LTR-beleid. 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 oudere 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 (PITR), geo-herstel en langetermijnretentie.

Back-upeigenschap	PITR	Geo-herstel	LTR
Typen back-ups van SQL	Volledig, differentieel, logboek.	Meest recente geo-gerepliceerde kopieën van PITR-back-ups.	Alleen de volledige back-ups.
Recovery Point Objective (RPO)	10 minuten, op basis van de rekengrootte 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	7 dagen standaard, configureerbaar tussen 1 en 35 dagen (behalve Basisdatabases, die kunnen worden geconfigureerd tussen 1 en 7 dagen).	Standaard ingeschakeld, hetzelfde als de bron.**	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	Niet ondersteund	Niet ondersteund**	Niet ondersteund**
Herstellen via Azure Portal	Ja	Ja	Ja
Herstellen via PowerShell	Ja	Ja	Ja
Herstellen via Azure CLI	Ja	Ja	Ja

* Gebruik failovergroepen voor bedrijfskritieke toepassingen die grote databases vereisen en moeten zorgen voor bedrijfscontinuïteit.

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

De tijdelijke oplossing is om te herstellen naar een nieuwe server en resourceverplaatsing te gebruiken om de server naar een ander abonnement te verplaatsen of een databasekopie voor meerdere abonnementen te gebruiken.

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

Back-upplanning

De eerste volledige back-up wordt gepland direct nadat een nieuwe database is gemaakt of hersteld. Deze back-up wordt meestal binnen 30 minuten voltooid, maar het kan langer duren wanneer de database groot is. 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 Database-service, omdat deze de algehele werkbelasting van het systeem evenredig verdeelt. U kunt het schema van back-uptaken niet wijzigen of uitschakelen.

Belangrijk

• Voor een nieuwe, herstelde of gekopieerde database is de functie voor herstel naar een bepaald tijdstip beschikbaar wanneer de eerste back-up van het transactielogboek na de eerste volledige back-up wordt gemaakt.
• Hyperscale-databases worden onmiddellijk na het maken beveiligd, in tegenstelling tot andere databases waarbij de eerste back-up tijd kost. De beveiliging is onmiddellijk, zelfs als de Hyperscale-database is gemaakt met een grote hoeveelheid gegevens via kopiëren of herstellen. Raadpleeg automatische back-ups van Hyperscale voor meer informatie.

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.

Azure SQL Database plant 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.

Hyperscale-databases maken gebruik van een ander mechanisme voor back-upplanning. Zie Back-upplanning van Hyperscale voor meer informatie.

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 Database 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 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, kunnen de back-upopslagkosten worden verhoogd. De reden hiervoor is dat de service back-ups bewaart voor elke verwijderde database, telkens wanneer deze wordt verwijderd.

Verbruik bewaken

Voor vCore-databases in Azure SQL Database wordt de opslag die elk type back-up (volledig, differentieel en logboek) verbruikt, gerapporteerd in het deelvenster databasebewaking als afzonderlijke metrische gegevens. In de volgende schermopname ziet u hoe u het verbruik van de back-upopslag voor één database bewaakt.

Zie Hyperscale-back-upverbruik bewaken voor instructies over het bewaken van verbruik in Hyperscale.

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 back-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 Database 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 Database voldoende back-ups om pitr in de afgelopen 7 dagen standaard toe te staan. De service maakt regelmatig gebruik van volledige, differentiële en logboekback-ups om ervoor te zorgen dat databases kunnen worden overgeslagen op een bepaald tijdstip binnen de retentieperiode die is gedefinieerd voor de database.

Differentiële back-ups kunnen worden geconfigureerd voor één keer in 12 uur of eenmaal in 24 uur. Een differentiële back-upfrequentie van 24 uur kan de tijd verhogen die nodig is om de database te herstellen, vergeleken met de frequentie van 12 uur. In het vCore-model is de standaardfrequentie voor differentiële back-ups eenmaal in 12 uur. In het DTU-model is de standaardfrequentie eenmaal in 24 uur.

U kunt de redundantieoptie voor back-upopslag voor STR opgeven wanneer u uw database maakt en deze op een later tijdstip wijzigen. Als u de optie voor back-upredundantie wijzigt nadat uw database 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, wat 1 tot 35 dagen kan duren.

U kunt de bewaarperiode voor back-ups voor elke actieve database in het bereik van 1 tot 35 dagen wijzigen, met uitzondering van Basic-databases, die kunnen worden geconfigureerd van 1 tot 7 dagen. Zoals beschreven in het verbruik van back-upopslag, zijn back-ups die zijn opgeslagen om PITR in te schakelen mogelijk ouder dan de bewaarperiode. Als u back-ups langer wilt bewaren dan de maximale korte bewaarperiode van 35 dagen, kunt u langetermijnretentie inschakelen.

Als u een database verwijdert, bewaart het systeem back-ups op dezelfde manier als voor een onlinedatabase met de specifieke bewaarperiode. U kunt de bewaarperiode voor back-ups voor een verwijderde database niet wijzigen.

Belangrijk

Als u een server verwijdert, worden ook alle databases op die server verwijderd en kunnen ze niet worden hersteld. U kunt een verwijderde server niet herstellen. Maar als u langetermijnretentie voor een database hebt geconfigureerd, worden LTR-back-ups niet verwijderd. Vervolgens kunt u deze back-ups gebruiken om databases op een andere server in hetzelfde abonnement te herstellen naar een bepaald tijdstip waarop een LTR-back-up is gemaakt. Voor meer informatie raadpleegt u Back-up op lange termijn herstellen.

Langetermijnretentie

Voor SQL Database kunt u back-ups voor langetermijnretentie (LTR) tot 10 jaar configureren in Azure Blob Storage. Nadat het LTR-beleid is geconfigureerd, worden volledige back-ups wekelijks 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 wordt bijvoorbeeld maandelijks een LTR-kopie gemaakt. Zie Langetermijnretentie voor meer informatie over LTR.

Wanneer u de redundantie van de back-upopslag voor een bestaande database bijwerkt, wordt de wijziging alleen toegepast op volgende back-ups die in de toekomst zijn gemaakt en niet voor bestaande back-ups. Alle bestaande LTR-back-ups voor de database blijven zich in de bestaande opslagblob bevinden. Nieuwe back-ups worden gerepliceerd op basis van de geconfigureerde redundantie van back-upopslag.

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.

Wanneer u een Hyperscale-database herstelt vanuit een LTR-back-up, is de eigenschap leesschaal uitgeschakeld. Als u de database wilt inschakelen, moet u de database bijwerken nadat deze is gemaakt. U moet de doelserviceniveaudoelstelling opgeven bij het herstellen vanuit een LTR-back-up.

Langetermijnretentie kan worden ingeschakeld voor Hyperscale-databases die zijn gemaakt of gemigreerd vanuit andere servicelagen. Als u LTR wilt inschakelen voor een Hyperscale-database waarvoor deze nog niet wordt ondersteund, ontvangt u de volgende fout: 'Er is een fout opgetreden tijdens het inschakelen van langetermijnretentie van back-ups voor deze database. Neem contact op met microsoft-ondersteuning om langetermijnretentie van back-ups mogelijk te maken. Neem in dit geval contact op met Microsoft Ondersteuning en maak een ondersteuningsticket om dit op te lossen.

Kosten voor opslag van back-ups

De prijs voor back-upopslag varieert en is afhankelijk van uw aankoopmodel (DTU of vCore), gekozen optie voor redundantie van back-upopslag en 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

Zie de pagina met prijzen voor Azure SQL Database.

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.

DTU-model

In het DTU-model worden voor databases en elastische pools geen extra kosten in rekening gebracht voor de standaardretentie van 7 dagen en langer. De prijs van pitr-back-upopslag maakt deel uit van de database- of poolprijs.

Belangrijk

In het DTU-model worden databases en elastische pools in rekening gebracht voor de LTR-back-upopslag op basis van de werkelijke opslag die wordt verbruikt door LTR-back-ups .

vCore-model

Azure SQL Database 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 kosten voor back-upopslag worden anders berekend voor Hyperscale-databases. Zie de kosten voor back-upopslag van Hyperscale voor meer informatie.

Voor individuele databases is een back-upopslaghoeveelheid gelijk aan 100 procent van de maximale gegevensopslaggrootte voor de database, zonder extra kosten. De volgende vergelijking wordt gebruikt om het totale factureerbare back-upopslaggebruik te berekenen:

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

Voor elastische pools is een back-upopslaghoeveelheid gelijk aan 100 procent van de maximale gegevensopslag voor de poolopslaggrootte, zonder extra kosten. Voor pooldatabases wordt de totale grootte van factureerbare back-upopslag samengevoegd op poolniveau en wordt deze als volgt berekend:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

De totale factureerbare back-upopslag, indien van toepassing, wordt in gigabytes per maand in rekening gebracht volgens het tarief van de redundantie van de back-upopslag die u hebt gebruikt. Dit back-upopslagverbruik is afhankelijk van de workload en grootte van afzonderlijke databases, elastische pools 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 Database 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 Database 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.

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 een index, 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.

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 buitensporig groot zou zijn, anders. Dit vermindert de grootte van alle differentiële back-ups totdat de volgende volledige back-up wordt uitgevoerd.

U kunt het totale verbruik van back-upopslag bewaken voor elk back-uptype (volledig, differentieel, transactielogboek) in de loop van de tijd, zoals beschreven in Verbruik bewaken.

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-database voor één database of een pool voor elastische databases.

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 voor één/elastische pool voor één database of een pool voor elastische databases. Meters worden alleen weergegeven als het back-upopslagverbruik bestaat.

   Als u de kosten voor LTR-back-ups wilt bewaken, selecteert u in de vervolgkeuzelijst back-upopslag voor één database of een pool voor elastische databases. 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.

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. Opslagtellers zijn bijvoorbeeld niet zichtbaar voor resources die geen opslag gebruiken. Als er geen PITR- of LTR-back-upopslagverbruik is, zijn deze meters niet zichtbaar.

Zie Kostenbeheer voor Azure SQL Database voor meer informatie.

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 Transparante gegevensversleuteling met SQL Database voor meer informatie over TDE.

Back-upintegriteit

Op een continue basis, test het Azure SQL engineering team automatisch het herstel van geautomatiseerde database-back-ups. Bij herstel naar een bepaald tijdstip ontvangen databases ook DBCC CHECKDB-integriteitscontroles.

Eventuele problemen die tijdens een integriteitscontrole worden aangetroffen, resulteren in een waarschuwing voor het technische team. Zie Gegevensintegriteit in SQL Database voor meer informatie.

Alle databaseback-ups worden gemaakt met de optie CHECKSUM om extra back-upintegriteit te bieden.

Naleving

Wanneer u uw database migreert van een op DTU gebaseerde servicelaag naar een vCore-servicelaag, blijft deze PITR-retentie behouden om ervoor te zorgen dat het beleid voor gegevensherstel van uw toepassing niet wordt aangetast. 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.

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 voor uw SQL-database afdwingen 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, kunnen gebruikers in het abonnement geen database maken met geografisch redundante back-upopslag via Azure Portal of Azure PowerShell: SQL Database moet voorkomen dat GRS-back-upredundantie wordt gebruikt.

Raadpleeg de beleidsverwijzing voor een volledige lijst met ingebouwde beleidsdefinities voor SQL Database.

Belangrijk

Azure-beleid wordt niet afgedwongen wanneer u een database maakt via T-SQL. Als u gegevenslocatie wilt opgeven 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.

Gerelateerde inhoud

• Zie het overzicht van bedrijfscontinuïteit van SQL Database voor meer informatie over andere oplossingen voor bedrijfscontinuïteit.
• Zie Instellingen wijzigen als u de back-upinstellingen wilt wijzigen.
• Als u een back-up wilt herstellen, raadpleegt u Herstellen met behulp van back-ups of een database herstellen naar een bepaald tijdstip met behulp van PowerShell.
• Zie Langetermijnretentie van back-ups beheren en herstellen voor informatie over het configureren, beheren en herstellen van automatische back-ups in Azure Blob Storage.
• Zie Automatische back-ups voor SQL Managed Instance voor Azure SQL Managed Instance.