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 wijzigenals u de back-upinstellingen wilt wijzigen. Zie Herstellen met behulp van geautomatiseerde databaseback-upsals 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 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 opslag-snapshots. 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-upsvoor meer informatie.

Back-upfrequentie

Azure SQL Database maakt:

• wekelijkse volledige back-ups
• differentiële back-ups elke 12 of 24 uur.
• backups van transactielogboeken ongeveer om de 10 minuten.

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, differentiële en transactielogboekback-ups moeten worden hersteld.

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

Redundantie van backupopslag

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 workloadomgeving optie waarmee u bepaalde configuratie-instellingen kunt instellen. Deze instellingen kunnen worden overschreven. Deze optie is alleen van toepassing op de pagina SQL Database maken portal.

• Bij het kiezen van de ontwikkelingswerkbelastingomgeving wordt de optie back-up opslagredundantie 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 omgeving Productie workload kiest, wordt de redundantie van Back-upopslag ingesteld op geografisch redundante opslag, de standaardinstelling.
• De werkbelastingomgeving optie wijzigt ook de eerste instelling voor rekenkracht, hoewel deze kan worden overschreven. Anders heeft de werkbelastingomgeving-optie geen invloed op licenties of andere instellingen voor databaseconfiguratie.

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 Gegevensredundantievoor 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 drie keer synchroon 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 over drie Azure-beschikbaarheidszones in de primaire regio. Het is momenteel alleen beschikbaar in bepaalde regio's.

  

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

  

• Geo-Zone redundante opslag (GZRS): Geografisch zone-redundante opslag (GZRS) combineert de hoge beschikbaarheid die wordt geboden door redundantie in beschikbaarheidszones (ZRS) met bescherming tegen regionale storingen die worden geboden door geo-replicatie (GRS). Kopieert uw back-ups synchroon over drie Azure-beschikbaarheidszones in de primaire regio en asynchroon drie keer naar één fysieke locatie in de gekoppelde secundaire regio.

  Microsoft raadt het gebruik van GZRS aan voor toepassingen die maximale consistentie, duurzaamheid en beschikbaarheid, uitstekende prestaties en tolerantie vereisen voor herstel na noodgevallen.

  Het resultaat is:

  • Drie synchrone kopieën over beschikbaarheidszones, in de primaire regio.

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

    In het volgende diagram ziet u hoe uw gegevens worden gerepliceerd met GZRS of RA-GZRS:

  

Waarschuwing

• Geo-restore is uitgeschakeld zodra een database wordt geüpdatet naar lokaal redundante of zone-redundante opslag.
• 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 vindt u in Hyperscale-back-ups en opslagredundantie.

Backupgebruik

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

• een bestaande database herstellen 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 deze ook hernoemen en vervolgens de herstelde database hernoemen naar de oorspronkelijke databasenaam.

• een verwijderde database herstellen 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 in 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 dit wijzigen door redundantie van back-upopslag te configureren.

• een database herstellen vanuit een specifieke langetermijnback-up van één 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 langetermijnretentievoor meer informatie.

Waarschuwing

Wanneer u een database herstelt en de redundantie van de bronback-upopslag is geconfigureerd als Geo-Zone Redundant Storage (GZRS), wordt de configuratie van de bronback-upopslag overgenomen door de nieuwe database als de redundantieconfiguratie voor back-upopslag voor de doeldatabase niet expliciet is opgegeven. Dit omvat alle herstelbewerkingen, zoals herstel naar een bepaald tijdstip, databasekopie, geo-herstel, herstel vanuit een back-up op lange termijn. Als de Azure-doelregio tijdens deze bewerking geen ondersteuning biedt voor de specifieke redundantie van back-upopslag, mislukt de herstelbewerking met het juiste foutbericht. Dit kan worden verzacht door expliciet de beschikbare opslagopties voor de regio op te geven.

Automatische back-ups op secundaire replica's

Automatische back-ups worden nu gemaakt van een secundaire replica in de servicecategorie Bedrijfskritiek. Omdat gegevens worden gerepliceerd tussen SQL Server-processen op elk knooppunt, maakt de back-upservice de back-up van de niet-leesbare secundaire replica's. Dit ontwerp zorgt ervoor dat de primaire replica gewijd blijft aan uw hoofdworkload en dat de leesbare secundaire replica gewijd is aan lees-enkel workloads. Automatische back-ups bij de servicelaag Bedrijfskritiek worden meestal gemaakt van een secundaire replica. Als een automatische back-up mislukt op een secundaire replica, maakt de back-upservice de back-up van de primaire replica.

Automatische back-ups bij secundaire replica's:

• Zijn standaard ingeschakeld.
• Zijn zonder extra kosten inbegrepen binnen de prijs van het serviceniveau.
• Breng verbeterde prestaties en voorspelbaarheid naar de servicelaag Bedrijfskritiek.

Notitie

• Maak een Microsoft-ondersteuningsticket om de functie voor uw exemplaar uit te schakelen.

Mogelijkheden en functies herstellen

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

Zie RTO- en RPO-voor meer informatie over hersteltijden.

Eigenschap voor reservekopie	PITR	Geo-herstel	LTR
typen SQL-back-up	Volledig, differentieel, logboek.	Meest recente geo-gerepliceerde kopieën van PITR-back-ups.	Alleen de volledige back-ups.
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.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-up opslag is ingesteld op geografisch redundant. Niet beschikbaar wanneer de PITR-back-upopslag zone-redundant of lokaal redundant is.	Standaard geografisch redundant. U kunt zone-redundante of lokaal redundante opslag configureren.
back-ups configureren als onveranderbaar	Niet ondersteund	Niet ondersteund	Niet ondersteund
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	Niet ondersteund	Niet ondersteund3	Niet ondersteund3
herstellen via Azure Portal	Ja	Ja	Ja
Herstellen via PowerShell	Ja	Ja	Ja
Herstellen via Azure CLI	Ja	Ja	Ja

¹ Voor bedrijfskritieke toepassingen waarvoor grote databases nodig zijn en die bedrijfscontinuïteit moeten garanderen, moet u failovergroepengebruiken.
² Alle PITR-back-ups worden standaard opgeslagen op 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 database voor meerdere abonnementen te kopiëren.

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 verkennen met behulp van de volgende voorbeelden.

Operatie	Azure Portal	Azure CLI	Azure PowerShell
Back-up bewaarperiode 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 exporteren

Automatische back-ups die door de Azure-service worden gemaakt, zijn niet beschikbaar om rechtstreeks te downloaden of te openen. Ze kunnen alleen worden gebruikt voor herstelbewerkingen via Azure.

Er zijn alternatieven voor het exporteren van een Azure SQL Database. Wanneer u een database wilt exporteren voor archivering of voor verplaatsing naar een ander platform, kunt u het databaseschema en de gegevens exporteren naar een BACPAC--bestand. Een BACPAC-bestand is een ZIP-bestand met de extensie BACPAC met de metagegevens en gegevens uit de database. Een BACPAC-bestand kan worden opgeslagen in Azure Blob Storage of in lokale opslag op een on-premises locatie en later weer worden geïmporteerd in Azure SQL Database, Azure SQL Managed Instanceof een SQL Server-exemplaar.

U kunt een Azure SQL Database ook importeren of exporteren met behulp van een private link of importeren of exporteren zonder dat Azure-services toegang krijgen tot de server.

Backupschema

De eerste volledige back-up wordt onmiddellijk gepland 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 systeemworkload in balans brengt. 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 Hyperscalevoor 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 zijn van differentiële- en transactielogboekback-ups, vanaf die volledige back-up tot de volgende volledige back-up.

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

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 nodig hebben om herstelbaar te zijn, worden alle drie de back-uptypen samen in wekelijkse sets ontstopt.

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 verhouding voor back-upcompressie is 3 tot 4 maal. Het kan echter 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-ups bestanden niet gecomprimeerd om prestatie redenen. 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 Point-In-Time Recovery (PITR) te bieden, zelfs wanneer 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 Monitor het verbruik van Hyperscale-back-upsvoor instructies over het bewaken van het back-upverbruik in Hyperscale.

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 backupopslag 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 dataladenbewerkingen kunt u overwegen geclusterde columnstore-indexen te gebruiken en de bijbehorende best practices. 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 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.

Kortetermijnretentie

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 wijzigen voor elke actieve database in het bereik van 1 tot 35 dagen, met uitzondering van Basic-databases, die kunnen worden geconfigureerd van 1 tot 7 dagen. Zoals beschreven in 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 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, raadpleeg Langetermijnback-up 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. Als u bijvoorbeeld W=0, M=1 instelt, wordt er maandelijks een LTR-kopie gemaakt. Zie langetermijnretentievoor 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.

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.

Wanneer u een Hyperscale-database herstelt vanuit een LTR-back-up, is de eigenschap leesschaal uitgeschakeld. Om de database in te schakelen, leest u de schaal op de herstelde database en werkt u de database bij nadat deze is aangemaakt. U moet de serviceniveaudoelstelling 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 back-upopslag

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.

Zie de Azure SQL Database prijsinformatie op de pagina.

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 PITR-back-upopslag bij de standaardretentie van 7 dagen en langer. De prijs van PITR-back-upopslag is inbegrepen in de database- of poolprijs.

Belangrijk

In het DTU-model worden databases en elasticiteitspools gefactureerd op basis van de LTR-back-up opslag, gebaseerd op de werkelijke opslag die door LTR-back-ups wordt gebruikt.

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 je gebruik van de back-upopslag aan het einde van elke maand te bepalen.

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 nodig hebben om herstelbaar te zijn, 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 kosten voor back-upopslag van Hyperscalevoor 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 wanneer een oudere reeks volledige, differentiële en logboekback-ups is verouderd.

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 herbouw van de index maakt, worden vervolgens opgenomen.

• Tijdens de herbouwing genomen back-ups van het transactielogboek.
• In de volgende differentiële back-up.
• In iedere differentiële back-up die wordt uitgevoerd totdat de volgende volledige back-up plaatsvindt.

Voor het laatste scenario in grotere databases zorgt een optimalisatie in de service ervoor dat er een volledige back-up wordt gemaakt in plaats van een differentiële back-up, indien een differentiële back-up anders buitensporig groot zou zijn. 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 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-database voor één database of een pool voor elastische databases.

3. Voeg nog een filter toe voor subcategorie van meter.

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 er verbruik van back-upopslag is.

   Om de kosten voor LTR-back-ups te monitoren, selecteert u in de vervolgkeuzelijst LTR-back-upopslag voor een enkele database of een pool voor elastische databases. Meters worden alleen weergegeven als er verbruik van de 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.

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 verbruik van PITR- of LTR-back-upopslag is, zijn deze meters niet zichtbaar.

Zie Kostenbeheer van Azure SQL Databasevoor meer informatie.

Versleutelde back-ups

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

Backupintegriteit

Het technische team van Azure SQL test voortdurend automatisch het herstellen van geautomatiseerde databaseback-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 Databasevoor 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 de 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. Voor meer informatie, zie De bewaarperiode voor PITR-back-up wijzigen.

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.

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

Ingebouwd redundantiebeleid voor back-upopslag

Als u vereisten voor dataresidency op organisatieniveau wilt afdwingen, kunt u beleid toewijzen aan een abonnement met behulp van de Azure Portal of Azure PowerShell.

Als u bijvoorbeeld het beleid 'Azure SQL DB moet voorkomen dat GRS-back-up wordt gebruikt' inschakelt, kunnen databases niet worden gemaakt met de standaardopslag als globaal redundante opslag en kunnen gebruikers GEEN GRS gebruiken met het foutbericht 'Back-upopslagtype configureren op 'Standard_RAGRS' is mislukt tijdens het maken of bijwerken van databases.

Raadpleeg de -beleidsverwijzingvoor 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, LOCAL of ZONE gebruiken als invoer voor de parameter BACKUP_STORAGE_REDUNDANCY in de instructie CREATE DATABASE.

Verwante inhoud

• Zie Overzicht van bedrijfscontinuïteit van SQL Databasevoor meer informatie over andere oplossingen voor bedrijfscontinuïteit van SQL Database.
• Zie Instellingen wijzigenals 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 herstellenvoor informatie over het configureren, beheren en herstellen van automatische back-ups in Azure Blob Storage.
• Zie voor Azure SQL Managed Instance Automatische back-ups voor SQL Managed Instance.