Automatische back-ups in Azure SQL Database

Van toepassing op: Azure SQL database

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

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

Wat is een databaseback-up?

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

Voor andere servicelagen dan Hyperscale maakt Azure SQL Database gebruik van SQL Server-enginetechnologie om back-ups te maken van gegevens en gegevens te herstellen. Hyperscale-databases maken gebruik van back-ups 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 Hyperscale-back-ups voor meer informatie.

Back-upfrequentie

Azure SQL Database maakt:

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 Hyperscale-back-ups voor meer informatie.

Opslagredundantie voor back-ups

Standaard slaat Azure SQL Database back-ups op in geografisch redundante opslagblobs die worden gerepliceerd naar een gekoppelde regio. Geo-redundantie beschermt tegen storingen die van invloed zijn op back-upopslag in de primaire regio. U kunt hiermee ook uw databases in een andere regio herstellen in het geval van een regionale storing.

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

Om ervoor te zorgen dat uw back-ups binnen dezelfde regio blijven waarin uw database is geïmplementeerd, kunt u redundantie voor back-upopslag wijzigen van de standaard geografisch redundante opslag in andere typen opslag die uw gegevens binnen de regio houden. De geconfigureerde redundantie voor back-upopslag wordt toegepast op back-ups met kortetermijnretentie (STR) en LTR-back-ups. Zie Gegevensredundantie voor meer informatie over opslagredundantie.

U kunt redundantie voor back-upopslag configureren wanneer u uw database maakt en u kunt deze op een later tijdstip bijwerken. De wijzigingen die u aanbrengt in een bestaande database, 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 drie keer synchroon binnen één fysieke locatie in de primaire regio. LRS is de goedkoopste opslagoptie, maar we raden het niet aan voor toepassingen die tolerantie voor regionale storingen of een garantie voor hoge duurzaamheid van gegevens vereisen.

    Diagram met de optie lokaal redundante opslag (LRS).

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

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

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

    Het resultaat is:

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

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

Waarschuwing

  • Geo-herstel wordt uitgeschakeld zodra een database wordt bijgewerkt voor lokaal redundante of zone-redundante opslag.
  • De opslagredundantiediagrammen tonen allemaal regio's met meerdere beschikbaarheidszones (multi-az). Er zijn echter enkele regio's die slechts één beschikbaarheidszone bieden en geen ondersteuning bieden voor ZRS.
  • 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 de redundantie-instellingen voor back-upopslag voor een bestaande Hyperscale-database met minimale downtime wilt bijwerken, gebruikt u actieve geo-replicatie. U kunt ook databasekopie gebruiken. Meer informatie in Hyperscale-back-ups en opslagredundantie.

Back-upgebruik

U kunt automatisch gemaakte back-ups gebruiken in de volgende scenario's:

  • Herstel een bestaande database naar een bepaald tijdstip binnen de retentieperiode met behulp van de Azure Portal, Azure PowerShell, de Azure CLI of de REST API. Met deze bewerking wordt een nieuwe database gemaakt 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 naam van de oorspronkelijke database. U kunt ook in plaats van de oorspronkelijke database te verwijderen, de naam ervan wijzigen en vervolgens de naam van de herstelde database wijzigen in de oorspronkelijke databasenaam.

  • Een verwijderde database herstellen naar een bepaald tijdstip binnen de retentieperiode, 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 een bestaande server in een Azure-regio.

    Belangrijk

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

  • 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 de 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. Gerepliceerde kopieën van PITR-back-ups. Alleen de volledige back-ups.
Recovery Point Objective (RPO)  10 minuten, op basis van de rekenkracht en de hoeveelheid databaseactiviteit.   Maximaal 1 uur, op basis van geo-replicatie.*  Eén week (of het beleid van de gebruiker).
Beoogde hersteltijd (RTO) Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Herstel Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Herstel. Herstellen duurt meestal minder dan 12 uur, maar kan langer duren, afhankelijk van de grootte en activiteit. Zie Herstel.
Retentie Standaard 7 dagen, configureerbaar tot 35 dagen.  Standaard ingeschakeld, hetzelfde als de bron.** Niet standaard ingeschakeld. Retentie is maximaal 10 jaar.
Azure Storage   Geografisch redundant standaard. 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.
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 groepen voor automatische failover voor bedrijfskritieke toepassingen waarvoor grote databases nodig zijn en die de bedrijfscontinuïteit moeten garanderen.

** Alle PITR-back-ups worden standaard opgeslagen in geografisch redundante opslag, dus geo-herstel is standaard 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.

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

Back-upplanning

De eerste volledige back-up wordt gepland direct nadat een nieuwe database is gemaakt of hersteld. Deze back-up is 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 de planning van back-uptaken niet wijzigen of uitschakelen.

Belangrijk

  • Voor een nieuwe, herstelde of gekopieerde database wordt de mogelijkheid 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 direct na het maken beveiligd, in tegenstelling tot andere databases waar 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.

Verbruik van back-upopslag

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

Azure SQL Database plant elke week één volledige back-up. Om PITR binnen de volledige retentieperiode te bieden, moet het systeem aanvullende volledige, differentiële en transactielogboekback-ups opslaan voor maximaal een week langer dan de geconfigureerde retentieperiode.

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

Hyperscale-databases gebruiken een ander mechanisme voor back-upplanning. Zie Hyperscale-back-upplanning 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 vereisen dat een eerdere volledige back-up kan worden hersteld, worden alle drie de back-uptypen samen opgeschoond in wekelijkse sets.

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

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

Belangrijk

Back-ups van een database worden bewaard om PITR te bieden, zelfs als de database is verwijderd. Hoewel het verwijderen en opnieuw maken van een database opslag- en rekenkosten kan besparen, kan dit de kosten voor back-upopslag verhogen. De reden hiervoor is dat de service back-ups bewaart voor elke verwijderde database, telkens wanneer deze wordt verwijderd.

Verbruik bewaken

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

Schermopname van selecties voor het bewaken van het verbruik van databaseback-ups in de Azure Portal.

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

Gebruik van back-upopslag afstemmen

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

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

Back-upretentie

Azure SQL Database biedt zowel kortetermijn- als langetermijnretentie van back-ups. Kortetermijnretentie staat PITR toe binnen de retentieperiode voor de database. Langetermijnretentie biedt back-ups voor verschillende nalevingsvereisten.

Retentie voor de korte termijn

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

Kortetermijnretentie van 1 tot 35 dagen voor Hyperscale-databases is nu in preview. Zie Back-upretentie beheren in Hyperscale voor meer informatie.

Differentiële back-ups kunnen worden geconfigureerd om één keer in 12 uur of eenmaal in 24 uur te worden uitgevoerd. Een differentiële back-upfrequentie van 24 uur kan de tijd die nodig is om de database te herstellen, verhogen in vergelijking met de 12-uursfrequentie. 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 vervolgens op een later tijdstip wijzigen. Als u de optie voor back-upredundantie wijzigt nadat de database is gemaakt, wordt de nieuwe redundantieoptie gebruikt voor nieuwe back-ups. Back-upkopieën die zijn gemaakt met de vorige OPTIE VOOR STR-redundantie, worden niet verplaatst of gekopieerd. Ze blijven in het oorspronkelijke opslagaccount totdat de retentieperiode is verstreken, die 1 tot 35 dagen kan zijn.

Met uitzondering van Basic-databases kunt u de bewaarperiode voor back-ups voor elke actieve database wijzigen in het bereik van 1 tot 35 dagen. Zoals beschreven in Verbruik van back-upopslag, kunnen back-ups die zijn opgeslagen om PITR in te schakelen, ouder zijn dan de retentieperiode. Als u back-ups langer wilt bewaren dan de maximale kortetermijnretentieperiode 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 alle databases op die server ook 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. U kunt deze back-ups vervolgens gebruiken om databases op een andere server in hetzelfde abonnement te herstellen naar een tijdstip waarop een LTR-back-up is gemaakt. Zie Back-up op lange termijn herstellen voor meer informatie.

Lange bewaartermijn

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

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.

Bij het bijwerken van de redundantie van de back-upopslag voor een bestaande database wordt de wijziging alleen toegepast op volgende back-ups die in de toekomst worden gemaakt en niet op bestaande back-ups. Alle bestaande LTR-back-ups voor de database blijven aanwezig in de bestaande opslagblob. Nieuwe back-ups worden gerepliceerd op basis van de geconfigureerde redundantie voor 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.

Kosten voor back-upopslag

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

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

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

Zie de pagina met prijzen voor Azure SQL Database voor prijzen.

Notitie

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

DTU-model

In het DTU-model worden er geen extra kosten in rekening gebracht voor back-upopslag voor databases en elastische pools. De prijs van back-upopslag maakt deel uit van de prijs van de database of groep.

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 aggregeert dit gebruik per uur om aan het einde van elke maand uw verbruik van back-upopslag op te halen.

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

De kosten voor back-upopslag worden anders berekend voor Hyperscale-databases. Zie Kosten voor hyperscale-back-upopslag voor meer informatie.

Voor individuele databases wordt zonder extra kosten een back-upopslag geboden die gelijk is aan 100 procent van de maximale grootte van de gegevensopslag voor de database. De volgende vergelijking wordt gebruikt om het totale factureerbare gebruik van back-upopslag 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 wordt een hoeveelheid back-upopslag die gelijk is aan 100 procent van de maximale gegevensopslag voor de opslaggrootte van de pool zonder extra kosten opgegeven. Voor pooldatabases wordt de totale grootte van factureerbare back-upopslag geaggregeerd op groepsniveau en 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 aanwezig, wordt in gigabytes per maand in rekening gebracht op basis van het tarief van de redundantie van de back-upopslag die u hebt gebruikt. Dit verbruik van back-upopslag is afhankelijk van de workload en grootte van afzonderlijke databases, elastische pools en beheerde exemplaren. Sterk gewijzigde databases hebben grotere differentiële back-ups en logboekback-ups, omdat de grootte van deze back-ups evenredig is met de hoeveelheid gewijzigde gegevens. Daarom zullen dergelijke databases hogere back-upkosten hebben.

Als vereenvoudigd voorbeeld wordt ervan uitgegaan dat een database 744 GB aan back-upopslag heeft verzameld en dat deze hoeveelheid gedurende een hele maand constant blijft omdat de database volledig inactief is. Als u dit cumulatieve opslagverbruik wilt converteren naar gebruik per uur, deelt u het 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 constant tarief. Met Azure-facturering wordt dit verbruik geaggregeerd en wordt een gebruik van 744 GB voor de hele maand weergegeven. De kosten zijn gebaseerd op het tarief voor gigabytes per maand in uw regio.

Hier volgt nog een voorbeeld. Stel dat de retentie van dezelfde niet-actieve database is verhoogd van 7 dagen naar 14 dagen in het midden van de maand. Door deze toename verdubbelt de totale back-upopslag tot 1488 GB. SQL Database rapporteert 1 GB gebruik voor de uren 1 tot en met 372 (de eerste helft van de maand). Het zou het gebruik rapporteren als 2 GB voor de uren 373 tot en met 744 (de tweede helft van de maand). Dit gebruik wordt geaggregeerd tot een eindfactuur van 1116 GB per maand.

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

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

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

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

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

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 de kosten voor back-upopslag wilt begrijpen, gaat u naar Kostenbeheer en facturering in de Azure Portal. Selecteer Cost Management en selecteer vervolgens Kostenanalyse. Selecteer het gewenste abonnement voor Bereik en filter vervolgens als volgt op de periode en service waarin u geïnteresseerd bent:

  1. Voeg een filter toe voor Servicenaam.

  2. Selecteer in de vervolgkeuzelijst SQL-database voor één database of een pool voor elastische databases.

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

  4. Als u de kosten voor pitr-back-ups wilt bewaken, selecteert u in de vervolgkeuzelijst pitropslag voor één/elastische pool voor back-upopslag voor één database of een elastische databasepool. Meters worden alleen weergegeven als er een verbruik van back-upopslag bestaat.

    Als u de kosten voor LTR-back-ups wilt bewaken, selecteert u in de vervolgkeuzelijst ltr-back-upopslag voor één database of een pool voor elastische databases. Meters worden alleen weergegeven als er een verbruik van back-upopslag bestaat.

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

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

Belangrijk

Meters zijn alleen zichtbaar voor tellers die momenteel in gebruik zijn. Als er geen teller beschikbaar is, wordt de categorie waarschijnlijk momenteel niet gebruikt. Opslagitems zijn bijvoorbeeld niet zichtbaar voor resources die geen opslag gebruiken. Als er geen verbruik van pitr- of LTR-back-upopslag is, zijn deze meters niet zichtbaar.

Zie kostenbeheer van 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 Transparent data encryption with SQL Database (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 gevonden, 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 retentieperiode voor de PITR wijzigen. Zie De retentieperiode voor pitr-back-ups wijzigen voor meer informatie.

Notitie

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

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

Als u vereisten voor gegevenslocatie hebt die vereisen dat u al uw gegevens in één Azure-regio bewaart, 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 waarmee regels worden toegepast op Azure-resources. Azure Policy helpt u deze resources in overeenstemming te houden met uw bedrijfsstandaarden en serviceovereenkomsten. Zie Overzicht van Azure Policy voor meer informatie.

Ingebouwd redundantiebeleid voor back-upopslag

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

Raadpleeg de beleidsreferentie 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.

Volgende stappen