Automatische back-ups - Azure SQL Database & Azure SQL Managed Instance

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Wat is een back-up van een database?

Back-ups van databases zijn essentiële onderdelen van een 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 gegevensbeveiliging vereisen dat uw back-ups voor een langere periode beschikbaar zijn (maximaal tien jaar), kunt u langetermijnretentie configureren voor individuele databases en pooldatabases.

Back-upfrequentie

Zowel SQL Database als SQL Managed Instance gebruiken SQL Server-technologie om elke week volledige back-ups te maken, differentiële back-ups elke 12-24 uur en elke 5 tot 10 minuten back-ups van transactielogboek. De frequentie van de back-ups van het transactielogboek 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.

Redundantie van back-upopslag

Standaard worden SQL Database beheerde SQL opgeslagen in geografisch redundante opslagblobs die worden gerepliceerd naar een gekoppelde regio. Geo-redundantie helpt u te beschermen tegen uitval die van invloed is op back-upopslag in de primaire regio en stelt u in staat om uw server te herstellen naar een andere regio in het geval van een noodlottige situatie.

De optie voor het configureren van redundantie voor back-upopslag biedt de flexibiliteit om te kiezen tussen lokaal redundante, zone-redundante of geografisch redundante opslagblobs. Om ervoor te zorgen dat uw gegevens binnen dezelfde regio blijven waar uw beheerde exemplaar of SQL-database is geïmplementeerd, kunt u de standaard redundante back-upopslag redundantie wijzigen en lokaal redundante of zone-redundante opslagblobs voor back-ups configureren. Storage redundantiemechanismen slaan meerdere kopieën van uw gegevens op, zodat deze worden beschermd tegen geplande en ongeplande gebeurtenissen, waaronder tijdelijke hardwarestoringen, netwerk- of stroomstoringen of grote natuurrampen. De geconfigureerde redundantie voor back-upopslag wordt toegepast op zowel back-upretentie-instellingen voor de korte termijn die worden gebruikt voor herstel naar een bepaald tijdstip (PITR) als back-ups voor langetermijnretentie die worden gebruikt voor back-ups op lange termijn (LTR).

Voor SQL Database kan de redundantie voor back-upopslag worden geconfigureerd op het moment dat de database wordt gemaakt of worden bijgewerkt voor een bestaande database. De wijzigingen die in een bestaande database worden aangebracht, zijn alleen van toepassing op toekomstige back-ups. Nadat de redundantie van de back-upopslag van een bestaande database is bijgewerkt, kan het tot 48 uur duren voordat de wijzigingen zijn toegepast. Geo-herstel wordt uitgeschakeld zodra een database is bijgewerkt voor het gebruik van lokale of zone-redundante opslag.

Back-upgebruik

U kunt deze back-ups gebruiken om:

• Herstel naar een bepaald tijdstip van een bestaande database - Herstel een bestaande database naar een bepaald tijdstip in het verleden binnen de bewaarperiode met behulp van Azure Portal, Azure PowerShell, Azure CLI of REST API. Voor SQL Database maakt deze bewerking een nieuwe database op dezelfde server als de oorspronkelijke database, maar gebruikt een andere naam om te voorkomen dat de oorspronkelijke database wordt overschreven. Nadat het herstellen is voltooid, kunt u de oorspronkelijke database verwijderen. U kunt ook de naam van de oorspronkelijke database wijzigen en vervolgens de naam van de herstelde database wijzigen in de naam van de oorspronkelijke database. Op dezelfde manier maakt SQL Managed Instance een kopie van de database op hetzelfde of een ander beheerd exemplaar in hetzelfde abonnement en dezelfde regio.
• Herstel naar een bepaald tijdstip van verwijderde database - Herstel een verwijderde database naar het tijdstip van verwijdering of naar een bepaald tijdstip binnen de bewaarperiode. De verwijderde database kan alleen worden hersteld op dezelfde server of het beheerde exemplaar waar de oorspronkelijke database is gemaakt. Bij het verwijderen van een database maakt de service een laatste back-up van het transactielogboek voordat deze wordt verwijderd, om gegevensverlies te voorkomen.
• Geo-herstel - Een database herstellen naar een andere geografische regio. Met geo-herstel kunt u herstellen na een geografisch noodherstel 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 of beheerd exemplaar, in elke Azure-regio.

  Belangrijk

  Geo-herstel is alleen beschikbaar voor SQL databases of beheerde exemplaren die zijn geconfigureerd met geografisch redundante back-upopslag.

• Herstellen vanuit back-up op lange termijn - Een database herstellen vanuit een specifieke langetermijnback-up van één database of pooldatabase, als de database is geconfigureerd met een langetermijnretentiebeleid (LTR). Met LTR kunt u een oude versie van de database herstellen met behulp van de Azure Portal, Azure CLI of Azure PowerShell om te voldoen aan een nalevingsaanvraag of om een oude versie van de toepassing uit te voeren. Zie Langetermijnretentie voor meer informatie.

Herstelmogelijkheden en functies van Azure SQL Database Azure SQL Managed Instance

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

* Gebruik automatische failovergroepenvoor bedrijfskritieke toepassingen waarvoor grote databases zijn vereist en bedrijfscontinuïteit moeten worden gegarandeerd.

** Alle back-ups van een pitr worden standaard opgeslagen in geografisch redundante opslag. Geo-herstel is daarom standaard ingeschakeld.

*** Tijdelijke oplossing is om te herstellen naar een nieuwe server en Resource verplaatsen te gebruiken om de server naar een ander abonnement te verplaatsen.

Een database herstellen vanuit back-ups

Zie Database herstellen vanuit back-ups voor het uitvoeren van een herstel. U kunt de back-upconfiguratie en herstelbewerkingen proberen met behulp van de volgende voorbeelden:

Back-upplanning

De eerste volledige back-up wordt gepland direct nadat een nieuwe database is gemaakt of hersteld. Deze back-up wordt doorgaans 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 of SQL Managed Instance-service, omdat deze de algehele werkbelasting van het systeem in balans is. U kunt het schema van back-uptaken niet wijzigen of uitschakelen.

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 die bestaat uit één volledige back-up, optioneel één differentiële back-up en een of meer back-ups van transactielogboek. SQL Database en SQL managed instance-back-upschema bevat één volledige back-up per week. Daarom moet het systeem extra volledige, differentiële en transactielogboekback-ups opslaan voor maximaal een week langer dan de geconfigureerde retentieperiode om een pitr te kunnen bieden binnen de hele bewaarperiode.

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, evenals een ononderbroken keten van differentiële back-ups en transactielogboekback-ups van die volledige back-up tot de volgende volledige back-up.

Back-ups die niet langer nodig zijn om pitr-functionaliteit te bieden, worden automatisch verwijderd. Omdat differentiële back-ups en logboekback-ups een eerdere volledige back-up moeten kunnen worden terugzetten, worden alle drie de back-uptypen samen in wekelijkse sets verwijderd.

Voor alle databases, inclusief versleutelde TDE-databases, worden back-ups gecomprimeerd om compressie en kosten voor back-upopslag te verminderen. De gemiddelde compressieverhouding voor back-ups is 3-4 keer, maar deze kan aanzienlijk lager of hoger zijn, afhankelijk van de aard van de gegevens en of gegevenscompressie wordt gebruikt in de database.

SQL Database en SQL Managed Instance berekent u de totale gebruikte back-upopslag als een cumulatieve waarde. Deze waarde wordt elk uur gerapporteerd aan de Azure-factureringspijplijn, die verantwoordelijk is voor het samenvoegen 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. Zodra alle back-ups zijn verwijderd en pitr niet meer mogelijk is, wordt de facturering gestopt.

Verbruik bewaken

Voor vCore-databases wordt de opslag die wordt gebruikt door elk type back-up (volledig, differentieel en logboek) als afzonderlijke metrische gegevens gerapporteerd in het deelvenster databasebewaking. In het volgende diagram ziet u hoe u het verbruik van back-upopslag voor één database kunt bewaken. Deze functie is momenteel niet beschikbaar voor beheerde exemplaren.

Verbruik van back-upopslag afstemmen

Het verbruik van back-upopslag tot de maximale gegevensgrootte voor een database wordt niet in rekening gebracht. Overtollig gebruik 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:

• Verklein de bewaarperiode voor back-ups tot het minimum dat mogelijk is voor uw behoeften.
• Vermijd het vaker uitvoeren van grote schrijfbewerkingen, zoals het herbouwen van indexen, dan nodig is.
• Voor grote gegevensbelastingsbewerkingen kunt u geclusterde columnstore-indexen gebruiken en de gerelateerde best practicesvolgen en/of het aantal niet-geclusterde indexen verminderen.
• In de Algemeen servicelaag is de inrichtende gegevensopslag minder duur dan de prijs van de back-upopslag. Als de kosten voor back-upopslag voortdurend hoog zijn, kunt u overwegen om de gegevensopslag te vergroten om te besparen op de back-upopslag.
• Gebruik TempDB in plaats van permanente tabellen in uw toepassingslogica voor het opslaan van tijdelijke resultaten en/of tijdelijke gegevens.
• Gebruik waar mogelijk lokaal redundante back-upopslag (bijvoorbeeld dev/test-omgevingen)

Back-upretentie

Azure SQL Database en Azure SQL Managed Instance bieden zowel korte- als langetermijnretentie van back-ups. Met de back-ups voor kortetermijnretentie kunnen herstel naar een bepaald tijdstip (PITR) worden gebruikt met de bewaarperiode voor de database, terwijl de langetermijnretentie back-ups biedt voor verschillende nalevingsvereisten.

Kortetermijnretentie

Voor alle nieuwe, herstelde en gekopieerde databases behouden Azure SQL Database en Azure SQL Managed Instance standaard voldoende back-ups om herstel naar een hersteltijd in de afgelopen zeven dagen toe te staan. Er worden regelmatig volledige, differentiële en logboekback-ups gemaakt om ervoor te zorgen dat databases kunnen worden teruggeplaatst naar een bepaald tijdstip binnen de retentieperiode die is gedefinieerd voor de database of het beheerde exemplaar. Daarnaast kunnen voor Azure SQL Databases differentiële back-ups worden geconfigureerd voor een frequentie van 12 uur of 24 uur.

Met uitzondering van hyperscale- en Basic-laagdatabases kunt u de bewaarperiode voor back-ups per actieve database wijzigen binnen het bereik van 1-35 dagen. Zoals beschreven in Back-upopslagverbruik,kunnen back-ups die zijn opgeslagen om pitr in te stellen ouder zijn dan de bewaarperiode. Alleen voor Azure SQL Managed Instance is het mogelijk om de bewaarperiode voor de back-up van de pitr in te stellen zodra een database binnen het bereik van 0-35 dagen is verwijderd.

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

Back-upretentie voor pitr-doeleinden binnen de afgelopen 1-35 dagen wordt ook wel back-upretentie voor de korte termijn genoemd. Als u back-ups langer wilt bewaren dan de maximale retentieperiode voor de korte termijn van 35 dagen, kunt u langetermijnretentie inschakelen.

Lange bewaartermijn

Voor zowel SQL Database als SQL Managed Instance kunt u langetermijnretentie van volledige back-ups (LTR) configureren voor maximaal tien jaar in Azure Blob Storage. Nadat het LTR-beleid is geconfigureerd, worden volledige back-ups automatisch wekelijks naar een andere opslagcontainer gekopieerd. Als u wilt voldoen aan verschillende nalevingsvereisten, kunt u verschillende bewaarperioden selecteren voor wekelijkse, maandelijkse en/of jaarlijkse volledige back-ups. Storage verbruik is afhankelijk van de geselecteerde frequentie en bewaarperioden van LTR-back-ups. U kunt de LTR-prijscalculator gebruiken om de kosten van LTR-opslag te schatten.

Zie Langetermijnretentie van back-upsvoor meer informatie over LTR.

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 ook van uw regio. Er worden kosten in rekening gebracht voor de back-upopslag per GB/maand die wordt verbruikt. Zie de pagina met prijzen voor Azure SQL Database Azure SQL Managed Instance voor prijzen.

Zie Choose between the vCore and DTU purchasing models (Kiezen tussen de vCore- en DTU-aankoopmodellen) voor meer informatie over het kopen van modellen.

DTU-model

In het DTU-model zijn er geen extra kosten voor back-upopslag voor databases en elastische pools. De prijs van back-upopslag maakt deel uit van de database- of poolprijs.

vCore-model

Voor individuele databases in SQL Database wordt zonder extra kosten een back-upopslagbedrag geboden dat gelijk is aan 100 procent van de maximale gegevensopslaggrootte voor de database. Voor elastische pools en beheerde exemplaren wordt zonder extra kosten een back-upopslagbedrag geboden dat gelijk is aan 100 procent van de maximale gegevensopslag voor de pool of de maximale opslaggrootte van het exemplaar.

Voor individuele databases wordt deze vergelijking gebruikt om het totale gebruik van factureerbare 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 pooldatabases wordt de totale factureerbare back-upopslaggrootte geaggregeerd op groepsniveau 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

Voor beheerde exemplaren wordt de totale factureerbare back-upopslaggrootte geaggregeerd op exemplaarniveau en wordt deze als volgt berekend:

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

De totale factureerbare back-upopslag wordt in GB/maand in rekening gebracht volgens de snelheid van de gebruikte redundantie voor back-upopslag. Het verbruik van deze 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 worden voor dergelijke databases hogere back-upkosten in rekening gebracht.

SQL Database en SQL Managed Instance berekent uw totale factureerbare back-upopslag als een cumulatieve waarde voor alle back-upbestanden. Deze waarde wordt elk uur gerapporteerd aan de Azure-factureringspijplijn, waarmee dit gebruik per uur wordt geaggregeerd om het verbruik van uw back-upopslag aan het einde van elke maand 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 terugzetten, worden alle drie de back-uptypen samen in wekelijkse sets verwijderd. Zodra alle back-ups zijn verwijderd, stopt de facturering.

Een vereenvoudigd voorbeeld: stel 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 dit door 744,0 (31 dagen per maand * 24 uur per dag). SQL Database rapporteert aan de Azure-factureringspijplijn dat de database elk uur 1 GB aan back-up van een pitr heeft verbruikt, tegen een constant tarief. In Azure-facturering wordt dit verbruik geaggregeerd en wordt een gebruik van 744 GB voor de hele maand weer geven. De kosten worden gebaseerd op het bedrag/GB/maand in uw regio.

Nu een complexer voorbeeld. Stel dat de bewaarperiode van dezelfde niet-actieve database is verhoogd van zeven dagen tot 14 dagen in het midden van de maand. Door deze toename is de totale back-upopslag verdubbeld tot 1488 GB. SQL Database zou 1 GB aan gebruik rapporteren voor uren 1 tot en met 372 (de eerste helft van de maand). Het gebruik wordt in uren 373 tot en met 744 (de tweede helft van de maand) als 2 GB rapporteert. Dit gebruik wordt geaggregeerd tot een definitieve factuur van 1116 GB/maand.

Werkelijke back-upfactureringsscenario's zijn complexer. Omdat de snelheid van wijzigingen in de database afhankelijk is van de workload en in de tijd variabel is, varieert ook de grootte van elke differentiële back-up en logboekback-up, waardoor het verbruik van back-upopslag per uur dienovereenkomstig fluctueert. Bovendien bevat elke differentiële back-up alle wijzigingen die zijn aangebracht in de database sinds de laatste volledige back-up, waardoor de totale grootte van alle differentiële back-ups geleidelijk toeneemt in de loop van een week en vervolgens sterk afneemt zodra een oudere set volledige back-ups, differentiële back-ups en logboekback-ups is veroudert. Als bijvoorbeeld een zware schrijfactiviteit, zoals het herbouwen van de index, is uitgevoerd net nadat een volledige back-up is voltooid, worden de wijzigingen die zijn aangebracht door de herbouw van de index opgenomen in de back-ups van transactielogboek die worden gemaakt tijdens de herbouwing, in de volgende differentiële back-up en in elke differentiële back-up die wordt gemaakt tot de volgende volledige back-up. 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 overmatig 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), zoals beschreven in Verbruik bewaken.

Redundantie van back-upopslag

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

• lokaal redundante prijs = x
• zone-redundant price = 1,25x
• geografisch redundante prijs = 2x

Ga voor meer informatie over prijzen voor Back-upopslag naar Azure SQL Database pagina met prijzen en de SQL Azure SQL Managed Instance.

Kosten bewaken

Als u de kosten voor back-upopslag wilt begrijpen, gaat u naar Cost Management + Billing in de Azure Portal, selecteert u Cost Management en selecteert u vervolgens Kostenanalyse. Selecteer het gewenste abonnement als bereik en filter vervolgens op de periode en service waarin u bent geïnteresseerd.

Voeg een filter toe voor Servicenaam en selecteer sql database in de vervolgkeuzelijst. Gebruik het subcategoriefilter voor de meter om de factureringsteller voor uw service te kiezen. Selecteer voor één database of een pool voor elastische databases back-upopslag met één pool of een elastische pool. Selecteer mi PITR backup storage voor een beheerd exemplaar. De Storage en rekensubcategorieën zijn mogelijk ook interessant voor u, maar ze zijn niet gekoppeld aan de kosten voor back-upopslag.

Zie Kostenbeheer voor Azure SQL Database meer informatie.

Versleutelde back-ups

Als uw database is versleuteld met TDE, worden back-ups automatisch 'at rest' versleuteld, inclusief LTR-back-ups. Alle nieuwe databases in Azure SQL geconfigureerd met TDE standaard ingeschakeld. Zie Voor meer informatie over TDE Transparent Data Encryption met SQL Database & SQL Managed Instance.

Back-upintegriteit

Het technische team van Azure SQL test automatisch het herstellen van automatische databaseback-ups. (Deze test is momenteel niet beschikbaar in SQL Managed Instance. U moet DBCC CHECKDB plannen voor uw databases in SQL Managed Instance, gepland rond op uw workload.)

Bij herstel naar een bepaald tijdstip ontvangen databases ook DBCC CHECKDB-integriteitscontroles.

Eventuele problemen die tijdens de integriteitscontrole zijn aangetroffen, leiden tot een waarschuwing aan het technische team. Zie Gegevensintegriteit in SQL Database voor meer SQL Database.

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

Naleving

Wanneer u uw database migreert van een servicelaag op basis van DTU naar een vCore-servicelaag, blijft de bewaarperiode van de herstelperiode 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 Change the PITR backup retention period (De bewaarperiode voor back-ups van de pitr wijzigen) voor meer informatie.

Het retentiebeleid voor de korte termijn wijzigen

U kunt de standaardretentieperiode voor pitr-back-ups en de frequentie van de differentiële back-up wijzigen met behulp van de Azure Portal, PowerShell of de REST API. In de volgende voorbeelden ziet u hoe u de retentie van de pitr wijzigt in 28 dagen en de differentiële back-ups in een interval van 24 uur.

Wijzig het beleid voor kortetermijnretentie met behulp van de Azure Portal

Als u de bewaarperiode voor back-ups van de pitr of de differentiële back-upfrequentie voor actieve databases wilt wijzigen met behulp van de Azure Portal, gaat u naar de server of het beheerde exemplaar met de databases waarvan u de bewaarperiode wilt wijzigen. Selecteer Back-ups in het linkerdeelvenster en selecteer vervolgens het tabblad Bewaarbeleid. Selecteer de database(s) waarvoor u de back-upretentie van de pitr wilt wijzigen. Selecteer vervolgens Bewaarperiode configureren in de actiebalk.

Het retentiebeleid voor de korte termijn wijzigen met behulp van Azure CLI

Bereid uw omgeving voor op Azure CLI.

• Gebruik de bash-omgeving in Azure Cloud shell.

  

• Installeer de Azure CLI, indien gewenst, om CLI-referentieopdrachten uit te voeren.

  • Als u een lokale installatie gebruikt, meldt u zich aan bij Azure CLI met behulp van de opdracht AZ login. Volg de stappen die worden weergegeven in de terminal, om het verificatieproces te voltooien. Raadpleeg Aanmelden bij de Azure CLI voor aanvullende aanmeldingsopties.

  • Installeer de Azure CLI-extensie bij het eerste gebruik, wanneer u hierom wordt gevraagd. Raadpleeg Extensies gebruiken met Azure CLI voor meer informatie over extensies.

  • Voer az version uit om de geïnstalleerde versie en afhankelijke bibliotheken te vinden. Voer az upgrade uit om te upgraden naar de nieuwste versie.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

# Set new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --name mymanageddb \
    --retention-days 1 \

# Set new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --retention-days 1 \

Het beleid voor kortetermijnretentie wijzigen met behulp van PowerShell

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase -RetentionDays 1

# SET new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
Get-AzSqlInstanceDatabase -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 1

# SET new PITR backup retention on an individual deleted database
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database.
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

# SET new PITR backup retention for ALL deleted databases
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

Wijzig het beleid voor kortetermijnretentie met behulp van de REST API

Met de onderstaande aanvraag wordt de retentieperiode bijgewerkt naar 28 dagen en wordt ook de frequentie van de differentiële back-up op 24 uur.

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

{ 
    "properties":{
        "retentionDays":28
        "diffBackupIntervalInHours":24
  }
}

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
    "diffBackupIntervalInHours":24
  }
}

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

{
  "properties":{
    "retentionDays":28
  }
}

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

Redundantie voor back-upopslag configureren

Configureerbare opslag redundantie voor SQL Databases kan worden geconfigureerd op het moment dat de database wordt gemaakt of kan worden bijgewerkt voor een bestaande database. De wijzigingen die in een bestaande database worden aangebracht, zijn alleen van toepassing op toekomstige back-ups. Voor SQL Managed Instance en HyperScale kan redundantie van back-upopslag alleen worden opgegeven tijdens het maakproces. Zodra de resource is ingericht, kunt u de redundantieoptie voor back-upopslag niet meer wijzigen. De standaardwaarde is geografisch redundante opslag. Voor verschillen in prijzen tussen lokaal redundante, zone-redundante en geografisch redundante back-upopslag gaat u naar de pagina met prijzen voor beheerde exemplaren.

Redundantie voor back-upopslag configureren met behulp van de Azure Portal

Redundantie voor back-upopslag configureren met behulp van de Azure CLI

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Redundantie voor back-upopslag configureren met behulp van PowerShell

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Geo

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Zone

New-AzSqlInstance -Name managedInstance2 -ResourceGroupName ResourceGroup01 -Location westcentralus -AdministratorCredential (Get-Credential) -SubnetId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/resourcegroup01/providers/Microsoft.Network/virtualNetworks/vnet_name/subnets/subnet_name" -LicenseType LicenseIncluded -StorageSizeInGB 1024 -VCore 16 -Edition "GeneralPurpose" -ComputeGeneration Gen4 -BackupStorageRedundancy Geo

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

Als u vereisten voor gegevensstatus hebt waarvoor u al uw gegevens in één Azure-regio moet bewaren, kunt u zone-redundante of lokaal redundante back-ups afdwingen voor uw SQL Database of beheerd exemplaar met behulp van Azure Policy. Azure Policy is een service die u kunt gebruiken voor het maken, toewijzen en beheren van beleidsregels die regels toepassen op Azure-resources. Azure Policy kunt u ervoor zorgen dat deze resources voldoen aan de standaarden en serviceovereenkomsten van uw bedrijf. Zie Overzicht van Azure Policy voor meer informatie.

Ingebouwd redundantiebeleid voor back-upopslag

Er worden nieuwe ingebouwde beleidsregels toegevoegd, die kunnen worden toegewezen op abonnements- of resourcegroepniveau om het maken van nieuwe database(s) of exemplaren met geografisch redundante back-upopslag te blokkeren.

SQL Database moet het gebruik van GRS-back-up-redundantie voorkomen

Door SQL beheerde instanties moeten het gebruik van GRS-back-up-redundantie voorkomen

Een volledige lijst met ingebouwde beleidsdefinities voor SQL Database managed instance vindt u hier.

Als u vereisten voor gegevensverplaatsing op organisatieniveau wilt afdwingen, kunnen deze beleidsregels worden toegewezen aan een abonnement. Nadat deze beleidsregels zijn toegewezen op abonnementsniveau, kunnen gebruikers in het opgegeven abonnement geen database of beheerd exemplaar met geografisch redundante back-upopslag maken via Azure Portal of Azure PowerShell.

Meer informatie over het toewijzen van beleid met behulp Azure Portal of Azure PowerShell

Volgende stappen

• Databaseback-ups zijn een essentieel onderdeel van elke strategie voor bedrijfscontinuïteit en herstel na noodherstel, omdat deze uw gegevens beschermen tegen onbedoelde beschadiging of verwijdering. Zie Overzicht van bedrijfscontinuïteit SQL Database andere oplossingen voor bedrijfscontinuïteit.
• Zie Langetermijnretentie van back-upsbeheren met behulp van de Azure Portal voor informatie over het configureren, beheren en herstellen van automatische back-ups in Azure Blob Storage met behulp van de Azure Portal.
• Zie Langetermijnretentie van back-ups beheren met Behulp van PowerShell voor informatie over het configureren, beheren en herstellen van geautomatiseerde back-ups in Azure Blob Storage met behulp van PowerShell.
• Meer informatie over het herstellen van een database naar een bepaald tijdstip met behulp van de Azure Portal.
• Meer informatie over het herstellen van een database naar een bepaald tijdstip met behulp van PowerShell.
• Zie Verbruik van back-upopslag in Managed Instance voor meer informatie over het gebruik van back-upopslag in Azure SQL Managed Instance.
• Zie Fine tuning backup storage costs on Managed Instance (Opslagkosten voor back-ups afstemmen op managed instance) voor meer informatie over het afstemmen van de retentie en kosten voor back-upopslag voor Azure SQL Managed Instance.