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

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Notitie

Dit artikel bevat stappen voor als u persoonlijke gegevens van het apparaat of de service wilt verwijderen. Bovendien kunt u het gebruiken om uw verplichtingen met betrekking tot de AVG na te komen.This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. Zie het gedeelte AVG van de Service Trust Portal als u op zoek bent naar algemene informatie over de AVG.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

Wat is een back-up van de data base?What is a database backup?

Database back-ups zijn een essentieel onderdeel van een strategie voor bedrijfs continuïteit en herstel na nood gevallen, omdat ze uw gegevens beschermen tegen beschadiging of verwijdering.Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or deletion. Deze back-ups maken het herstellen van data bases mogelijk op een bepaald moment binnen de geconfigureerde Bewaar periode.These backups enable database restore to a point in time within the configured retention period. Als uw regels voor gegevens bescherming vereisen dat uw back-ups langere tijd beschikbaar zijn (tot tien jaar), kunt u de lange termijn retentie voor zowel één als gepoolde data bases configureren.If your data protection rules require that your backups are available for an extended time (up to 10 years), you can configure long-term retention for both single and pooled databases.

Back-upfrequentieBackup frequency

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 back-ups van transactie logboeken om de vijf tot tien minuten.Both SQL Database and SQL Managed Instance use SQL Server technology to create full backups every week, differential backups every 12-24 hours, and transaction log backups every 5 to 10 minutes. De frequentie van back-ups van transactie Logboeken is gebaseerd op de berekenings grootte en de hoeveelheid database activiteit.The frequency of transaction log backups is based on the compute size and the amount of database activity.

Wanneer u een Data Base herstelt, bepaalt de service welke volledige, differentiële en transactie logboek back-ups moeten worden hersteld.When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.

Opslag redundantie van back-upsBackup storage redundancy

SQL Database en SQL Managed instance slaan gegevens standaard op in geografisch redundante opslag-blobs die worden gerepliceerd naar een gekoppelde regio.By default, SQL Database and SQL Managed Instance store data in geo-redundant storage blobs that are replicated to a paired region. Zo kunt u zich beschermen tegen storingen die van invloed zijn op de back-upopslag in de primaire regio en kunt u uw server herstellen naar een andere regio in het geval van een ramp.This helps to protect against outages impacting backup storage in the primary region and allow you to restore your server to a different region in the event of a disaster.

De optie voor het configureren van redundantie opslag voor back-ups biedt de flexibiliteit om te kiezen tussen lokaal redundante, zone redundante of geografisch redundante opslag-blobs voor een door SQL beheerd exemplaar of een SQL Database.The option to configure backup storage redundancy provides the flexibility to choose between locally-redundant, zone-redundant, or geo-redundant storage blobs for a SQL Managed Instance or a SQL Database. Om ervoor te zorgen dat uw gegevens binnen dezelfde regio blijven waar uw beheerde instantie of SQL database wordt geïmplementeerd, kunt u de standaard geo-redundante opslag redundantie voor back-ups wijzigen en lokaal redundante of zone-redundante opslag-blobs voor back-ups configureren.To ensure that your data stays within the same region where your managed instance or SQL database is deployed, you can change the default geo-redundant backup storage redundancy and configure either locally-redundant or zone-redundant storage blobs for backups. Opslag redundantie mechanismen slaan meerdere kopieën van uw gegevens op, zodat deze beschermd zijn tegen geplande en niet-geplande gebeurtenissen, waaronder tijdelijke hardwarestoringen, netwerk-of energie storingen of enorme natuur rampen.Storage redundancy mechanisms store multiple copies of your data so that it is protected from planned and unplanned events, including transient hardware failure, network or power outages, or massive natural disasters. De geconfigureerde redundantie voor back-upopslag wordt toegepast op de instellingen voor retentie van back-ups op korte termijn die worden gebruikt voor herstel naar een bepaald tijdstip (PITR) en back-ups voor lange termijn retentie die worden gebruikt voor langdurige back-ups (LTR).The configured backup storage redundancy is applied to both short-term backup retention settings that are used for point in time restore (PITR) and long-term retention backups used for long-term backups (LTR).

Voor een SQL Database kan de redundantie van de back-upopslag worden geconfigureerd op het moment dat de data base wordt gemaakt of kan worden bijgewerkt voor een bestaande data base. de wijzigingen die zijn aangebracht in een bestaande data base, zijn alleen van toepassing op toekomstige back-ups.For a SQL Database the backup storage redundancy can be configured at the time of database creation or can be updated for an existing database; the changes made to an existing database apply to future backups only. Nadat de redundantie van de back-upopslag van een bestaande data base is bijgewerkt, kan het tot 48 uur duren voordat de wijzigingen zijn toegepast.After the backup storage redundancy of an existing database is updated, it may take up to 48 hours for the changes to be applied. Houd er rekening mee dat geo Restore is uitgeschakeld zodra een Data Base is bijgewerkt voor het gebruik van lokale of zone redundante opslag.Note that, geo restore is disabled as soon as a database is updated to use local or zone redundant storage.

Belangrijk

De redundantie van back-upopslag configureren tijdens het proces voor het maken van een beheerd exemplaar als de resource is ingericht, is het niet meer mogelijk om de opslag redundantie te wijzigen.Configure backup storage redundancy during the managed instance creation process as once the resource is provisioned, it is no longer possible to change the storage redundancy.

Belangrijk

Zone-redundante opslag is momenteel alleen beschikbaar in bepaalde regio's.Zone-redundant storage is currently only available in certain regions.

Notitie

Configureer bare opslag redundantie van back-ups voor Azure SQL Database is momenteel beschikbaar in de preview-versie van Brazilië-zuid en algemeen beschikbaar in de Azure-regio Zuid-Azië.Configurable Backup Storage Redundancy for Azure SQL Database is currently available in public preview in Brazil South and generally available in Southeast Asia Azure region only. Deze functie is nog niet beschikbaar voor de grootschalige-laag.This feature is not yet available for Hyperscale tier.

Back-upgebruikBackup usage

U kunt deze back-ups gebruiken om:You can use these backups to:

  • Herstel naar een bepaald tijdstip van een bestaande data base - Een bestaande data base herstellen naar een bepaald tijdstip in het verleden binnen de retentie periode met behulp van Azure Portal, Azure PowerShell, Azure CLI of rest API.Point-in-time restore of existing database - Restore an existing database to a point in time in the past within the retention period by using Azure portal, Azure PowerShell, Azure CLI, or REST API. Voor SQL Database maakt deze bewerking een nieuwe Data Base op dezelfde server als de oorspronkelijke Data Base, maar gebruikt een andere naam om te voor komen dat de oorspronkelijke Data Base wordt overschreven.For SQL Database, this operation creates a new database on the same server as the original database, but uses a different name to avoid overwriting the original database. Nadat het herstellen is voltooid, kunt u de oorspronkelijke data base verwijderen.After restore completes, you can delete the original database. U kunt ook de naam van de oorspronkelijke data base wijzigen en vervolgens de naam van de herstelde data base wijzigen in de oorspronkelijke data base.Alternatively, you can rename both the original database, and then rename the restored database to the original database name. Op dezelfde manier maakt deze bewerking voor een SQL Managed instance een kopie van de Data Base op hetzelfde of een ander beheerd exemplaar in hetzelfde abonnement en dezelfde regio.Similarly, for SQL Managed Instance, this operation creates a copy of the database on the same or different managed instance in the same subscription and same region.
  • Herstel naar een bepaald tijdstip van een verwijderde data base - Een verwijderde data base herstellen naar het tijdstip van de verwijdering of naar een bepaald tijdstip binnen de Bewaar periode.Point-in-time restore of deleted database - Restore a deleted database to the time of deletion or to any point in time within the retention period. De verwijderde data base kan alleen worden teruggezet op een server of een beheerd exemplaar waarop de oorspronkelijke Data Base is gemaakt.The deleted database can be restored only on the same server or managed instance where the original database was created. Bij het verwijderen van een Data Base neemt de service een definitieve back-up van transactie logboeken voordat deze wordt verwijderd, om verlies van gegevens te voor komen.When deleting a database, the service takes a final transaction log backup before deletion, to prevent any data loss.
  • Geo-herstel - Een Data Base herstellen naar een andere geografische regio.Geo-restore - Restore a database to another geographic region. Met geo-Restore kunt u een geografische nood situatie herstellen wanneer u geen toegang hebt tot uw data base of back-ups in de primaire regio.Geo-restore allows you to recover from a geographic disaster when you cannot access your database or backups in the primary region. Er wordt in elke Azure-regio een nieuwe data base gemaakt op een bestaande server of een beheerd exemplaar.It creates a new database on any existing server or managed instance, in any Azure region.

    Belangrijk

    Geo-Restore is alleen beschikbaar voor SQL-data bases of beheerde exemplaren die zijn geconfigureerd met geografisch redundante back-upopslag.Geo-restore is available only for SQL databases or managed instances configured with geo-redundant backup storage.

  • Herstellen vanaf back-up - op lange termijn Een Data Base herstellen op basis van een specifieke lange termijn back-up van een enkele data base of gepoolde data base, als de data base is geconfigureerd met een lange termijn retentie beleid (LTR).Restore from long-term backup - Restore a database from a specific long-term backup of a single database or pooled database, if the database has been configured with a long-term retention policy (LTR). Met LTR kunt u een oude versie van de data base herstellen met behulp van de Azure Portal of Azure PowerShell om te voldoen aan een nalevings aanvraag of een oude versie van de toepassing uit te voeren.LTR allows you to restore an old version of the database by using the Azure portal or Azure PowerShell to satisfy a compliance request or to run an old version of the application. Zie Langetermijnretentie voor meer informatie.For more information, see Long-term retention.

Zie Data Base terugzetten van back-upsom een herstel bewerking uit te voeren.To perform a restore, see Restore database from backups.

Notitie

In Azure Storage verwijst de term replicatie naar het kopiëren van blobs van de ene locatie naar een andere.In Azure Storage, the term replication refers to copying blobs from one location to another. In SQL verwijst database replicatie naar verschillende technologieën om te voor komen dat meerdere secundaire data bases worden gesynchroniseerd met een primaire data base.In SQL, database replication refers to various technologies used to keep multiple secondary databases synchronized with a primary database.

U kunt back-ups van de configuratie-en herstel bewerkingen proberen met de volgende voor beelden:You can try backup configuration and restore operations using the following examples:

BewerkingOperation Azure PortalAzure portal Azure PowerShellAzure PowerShell
Retentie van back-ups wijzigenChange backup retention SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
Lange termijn retentie van back-ups wijzigenChange long-term backup retention SQL DatabaseSQL Database
Door SQL beheerd exemplaar-N.v.t.SQL Managed Instance - N/A
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
Een Data Base vanaf een bepaald moment herstellenRestore a database from a point in time SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
Een verwijderde database herstellenRestore a deleted database SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
Een Data Base herstellen vanuit Azure Blob-opslagRestore a database from Azure Blob storage SQL Database-N.v.t.SQL Database - N/A
Door SQL beheerd exemplaar-N.v.t.SQL Managed Instance - N/A
SQL Database-N.v.t.SQL Database - N/A
SQL Managed InstanceSQL Managed Instance

Back-upplanningBackup scheduling

De eerste volledige back-up wordt direct na het maken of herstellen van een nieuwe data base gepland.The first full backup is scheduled immediately after a new database is created or restored. Deze back-up wordt gewoonlijk binnen 30 minuten voltooid, maar kan langer duren als de data base groot is.This backup usually completes within 30 minutes, but it can take longer when the database is large. De eerste back-up kan bijvoorbeeld langer duren op een herstelde data base of een kopie van een Data Base die normaal gesp roken groter is dan een nieuwe data base.For example, the initial backup can take longer on a restored database or a database copy, which would typically be larger than a new database. Na de eerste volledige back-up worden alle verdere back-ups automatisch gepland en beheerd.After the first full backup, all further backups are scheduled and managed automatically. De exacte timing van alle database back-ups wordt bepaald door de SQL Database of de SQL Managed instance service, omdat deze de algehele systeem werk belasting evenwichtig benadert.The exact timing of all database backups is determined by the SQL Database or SQL Managed Instance service as it balances the overall system workload. U kunt het schema van back-uptaken niet wijzigen of uitschakelen.You cannot change the schedule of backup jobs or disable them.

Belangrijk

Voor een nieuwe, herstelde of gekopieerde data base wordt herstel naar een bepaald tijdstip beschikbaar vanaf het moment dat de eerste back-up van het transactie logboek dat volgt, de eerste volledige back-up wordt gemaakt.For a new, restored, or copied database, point-in-time restore capability becomes available from the time when the initial transaction log backup that follows the initial full backup is created.

Opslag gebruik back-upsBackup storage consumption

Met SQL Server-technologie voor back-up en herstel is het herstellen van een Data Base naar een bepaald tijdstip een niet-onderbroken back-upketen die bestaat uit één volledige back-up, eventueel een differentiële back-up en een of meer back-ups van transactie Logboeken.With SQL Server backup and restore technology, restoring a database to a point in time requires an uninterrupted backup chain consisting of one full backup, optionally one differential backup, and one or more transaction log backups. Het back-upschema van SQL Database en SQL Managed instance bevat een volledige back-up elke week.SQL Database and SQL Managed Instance backup schedule includes one full backup every week. Daarom moet het systeem, om PITR binnen de gehele Bewaar periode in te scha kelen, extra volledige, differentiële en transactie logboek back-ups opslaan gedurende een periode die langer is dan de geconfigureerde Bewaar periode.Therefore, to enable PITR within the entire retention period, the system must store additional full, differential, and transaction log backups for up to a week longer than the configured retention period.

Met andere woorden: voor elk tijdstip tijdens de Bewaar periode moet er een volledige back-up worden gemaakt die ouder is dan de oudste tijd van de retentie periode, evenals een ononderbroken keten van differentiële en transactie logboek back-ups van die volledige back-up tot de volgende volledige back-up.In other words, for any point in time during the retention period, there must be a full backup that is older than the oldest time of the retention period, as well as an uninterrupted chain of differential and transaction log backups from that full backup until the next full backup.

Notitie

Om PITR in te scha kelen, worden extra back-ups gedurende een week langer opgeslagen dan de geconfigureerde Bewaar periode.To enable PITR, additional backups are stored for up to a week longer than the configured retention period. Back-upopslag wordt in rekening gebracht tegen hetzelfde tarief voor alle back-ups.Backup storage is charged at the same rate for all backups.

Back-ups die niet meer nodig zijn om de PITR-functionaliteit te bieden, worden automatisch verwijderd.Backups that are no longer needed to provide PITR functionality are automatically deleted. Omdat voor differentiële back-ups en logboek back-ups een eerdere volledige back-up kan worden herstorable, worden alle drie de back-uptypen samen in wekelijkse sets opgeschoond.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets.

Voor alle data bases, inclusief TDe versleutelde data bases, worden back-ups gecomprimeerd om compressie van back-upopslag en kosten te verminderen.For all databases including TDE encrypted databases, backups are compressed to reduce backup storage compression and costs. De gemiddelde compressie ratio van back-ups is 3-4 keer, maar dit kan aanzienlijk lager of hoger zijn, afhankelijk van de aard van de gegevens en of gegevens compressie wordt gebruikt in de-data base.Average backup compression ratio is 3-4 times, however it can be significantly lower or higher depending on the nature of the data and whether data compression is used in the database.

SQL Database en SQL Managed instance berekenen de totale gebruikte back-upopslag als een cumulatieve waarde.SQL Database and SQL Managed Instance compute your total used backup storage as a cumulative value. Elk uur wordt deze waarde gerapporteerd aan de Azure-facturerings pijplijn, die verantwoordelijk is voor het samen voegen van dit uur gebruik om uw verbruik aan het einde van elke maand te berekenen.Every hour, this value is reported to the Azure billing pipeline, which is responsible for aggregating this hourly usage to calculate your consumption at the end of each month. Nadat de data base is verwijderd, neemt het verbruik af naarmate back-ups worden verwijderd.After the database is deleted, consumption decreases as backups age out and are deleted. Zodra alle back-ups zijn verwijderd en PITR niet meer mogelijk is, wordt de facturering gestopt.Once all backups are deleted and PITR is no longer possible, billing stops.

Belangrijk

Back-ups van een Data Base worden bewaard om PITR in te scha kelen, zelfs als de data base is verwijderd.Backups of a database are retained to enable PITR even if the database has been deleted. Tijdens het verwijderen en opnieuw maken van een Data Base kunnen opslag-en reken kosten worden bespaard, kunnen de kosten voor back-upopslag toenemen omdat de service back-ups voor elke verwijderde data base behoudt, telkens wanneer deze wordt verwijderd.While deleting and re-creating a database may save storage and compute costs, it may increase backup storage costs, because the service retains backups for each deleted database, every time it is deleted.

Verbruik bewakenMonitor consumption

Voor vCore-data bases wordt de opslag die wordt gebruikt door elk type back-up (volledig, differentieel en logboek) op de Blade database bewaking gerapporteerd als een afzonderlijke metriek.For vCore databases, the storage consumed by each type of backup (full, differential, and log) is reported on the database monitoring blade as a separate metric. In het volgende diagram ziet u hoe u het verbruik van back-upopslag voor één data base bewaakt.The following diagram shows how to monitor the backup storage consumption for a single database. Deze functie is momenteel niet beschikbaar voor beheerde exemplaren.This feature is currently not available for managed instances.

Gebruik van database back-ups in de Azure Portal bewaken

Het gebruik van back-upopslag nauw keuriger instellenFine-tune backup storage consumption

Voor het verbruik van back-upopslag tot de maximale gegevens grootte voor een Data Base worden geen kosten in rekening gebracht.Backup storage consumption up to the maximum data size for a database is not charged. Het verbruik van het back-upopslag is afhankelijk van de werk belasting en de maximale grootte van de afzonderlijke data bases.Excess backup storage consumption will depend on the workload and maximum size of the individual databases. Bekijk een aantal van de volgende afstemmings technieken om het verbruik van back-upopslag te verminderen:Consider some of the following tuning techniques to reduce your backup storage consumption:

  • Verminder de Bewaar periode voor back-ups naar de minimale vereisten voor uw behoeften.Reduce the backup retention period to the minimum possible for your needs.
  • Vermijd grote schrijf bewerkingen, zoals het opnieuw opbouwen van indexen, vaker dan u nodig hebt.Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • Overweeg het gebruik van geclusterde column Store-indexen en de volgende gerelateerde Aanbevolen procedures, en/of verklein het aantal niet-geclusterde indexen voor bewerkingen voor grote gegevens belasting.For large data load operations, consider using clustered columnstore indexes and following related best practices, and/or reduce the number of non-clustered indexes.
  • In de servicelaag Algemeen is de ingerichte gegevens opslag minder duur dan de prijs van de back-upopslag.In the General Purpose service tier, the provisioned data storage is less expensive than the price of the backup storage. Als u voortdurend veel overtollige back-upopslagkosten hebt, kunt u overwegen gegevens opslag te verg Roten om op te slaan in de back-upopslag.If you have continually high excess backup storage costs, you might consider increasing data storage to save on the backup storage.
  • Gebruik TempDB in plaats van permanente tabellen in uw toepassings logica om tijdelijke resultaten en/of tijdelijke gegevens op te slaan.Use TempDB instead of permanent tables in your application logic for storing temporary results and/or transient data.
  • Gebruik waar mogelijk lokaal redundante back-upopslag (bijvoorbeeld ontwikkel-en test omgevingen)Use locally-redundant backup storage whenever possible (for example dev/test environments)

Back-upretentieBackup retention

Voor alle nieuwe, herstelde en gekopieerde data bases Azure SQL Database en Azure SQL Managed instance voldoende back-ups behouden zodat PITR in de afgelopen 7 dagen standaard is toegestaan.For all new, restored, and copied databases, Azure SQL Database and Azure SQL Managed Instance retain sufficient backups to allow PITR within the last 7 days by default. Met uitzonde ring van grootschalige-en Basic-laag databases, kunt u de Bewaar periode voor back-ups wijzigen per actieve data base in het bereik van 1-35 dagen.With the exception of Hyperscale and Basic tier databases, you can change backup retention period per each active database in the 1-35 day range. Zoals beschreven in back-upopslag, is het mogelijk dat back-ups die zijn opgeslagen om PITR in te scha kelen, ouder zijn dan de retentie periode.As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period. Alleen voor Azure SQL Managed instance is het mogelijk om de retentie frequentie van PITR-back-ups in te stellen wanneer een Data Base binnen het bereik van 0-35 dagen is verwijderd.For Azure SQL Managed Instance only, it is possible to set the PITR backup retention rate once a database has been deleted in the 0-35 days range.

Als u een Data Base verwijdert, houdt het systeem back-ups op dezelfde manier als voor een online-data base met de specifieke Bewaar periode.If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. U kunt de Bewaar periode voor back-ups niet wijzigen voor een verwijderde data base.You cannot change backup retention period for a deleted database.

Belangrijk

Als u een server of een beheerd exemplaar verwijdert, worden ook alle data bases op die server of het beheerde exemplaar verwijderd en kunnen deze niet worden hersteld.If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. U kunt een verwijderde server of een beheerd exemplaar niet herstellen.You cannot restore a deleted server or managed instance. Maar als u wel lange termijn retentie (LTR) hebt geconfigureerd voor een Data Base of een beheerd exemplaar, worden back-ups voor lange termijn retentie niet verwijderd en kunnen ze worden gebruikt voor het herstellen van data bases op een andere server of een beheerd exemplaar in hetzelfde abonnement, tot een tijdstip waarop een back-up met lange termijn retentie is gemaakt.But if you had configured long-term retention (LTR) for a database or managed instance, long-term retention backups are not deleted, and can be used to restore databases on a different server or managed instance in the same subscription, to a point in time when a long-term retention backup was taken.

De retentie van back-ups voor PITR in de afgelopen 1-35 dagen wordt soms een retentie voor de korte termijn voor back-ups genoemd.Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. Als u back-ups langer wilt bewaren dan de maximale Bewaar periode voor de korte termijn van 35 dagen, kunt u de lange termijn retentieinschakelen.If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.

Lange bewaartermijnLong-term retention

Voor zowel SQL Database als SQL Managed Instance kunt u een volledige back-up voor de lange termijn (LTR) voor de hele periode configureren in Azure Blob-opslag.For both SQL Database and SQL Managed Instance, you can configure full backup long-term retention (LTR) for up to 10 years in Azure Blob storage. Nadat het LTR-beleid is geconfigureerd, worden volledige back-ups automatisch wekelijks naar een andere opslag container gekopieerd.After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. Om aan verschillende nalevings vereisten te voldoen, kunt u verschillende Bewaar perioden selecteren voor wekelijkse, maandelijkse en/of jaarlijkse volledige back-ups.To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. Het opslag verbruik is afhankelijk van de geselecteerde frequentie en de retentie perioden van V.L.N.R.-back-ups.Storage consumption depends on the selected frequency and retention periods of LTR backups. U kunt de LTR-prijs calculator gebruiken om de kosten van v.l.n.r.-opslag te schatten.You can use the LTR pricing calculator to estimate the cost of LTR storage.

Belangrijk

Het bijwerken van de redundantie van de back-upopslag voor een bestaande Azure SQL Database is alleen van toepassing op de toekomstige back-ups die zijn gemaakt voor de data base.Updating the backup storage redundancy for an existing Azure SQL Database, only applies to the future backups taken for the database. Alle bestaande LTR-back-ups voor de data base blijven aanwezig in de bestaande opslag-Blob en er worden nieuwe back-ups opgeslagen op het aangevraagde type opslag-blob.All existing LTR backups for the database will continue to reside in the existing storage blob and new backups will be stored on the requested storage blob type.

Voor meer informatie over LTR, Zie lange termijn retentie van back-ups.For more information about LTR, see Long-term backup retention.

OpslagkostenStorage costs

De prijs voor back-upopslag varieert en is afhankelijk van uw aankoop model (DTU of vCore), de gekozen optie voor opslag redundantie van back-ups en ook in uw regio.The price for backup storage varies and depends on your purchasing model (DTU or vCore), chosen backup storage redundancy option, and also on your region. De back-upopslag wordt in rekening gebracht per GB/maand verbruikt voor prijzen Zie Azure SQL database prijs pagina en prijs pagina Azure SQL Managed instance .The backup storage is charged per GB/month consumed, for pricing see Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

DTU-modelDTU model

In het DTU-model worden geen extra kosten in rekening gebracht voor back-upopslag voor data bases en elastische Pools.In the DTU model, there's no additional charge for backup storage for databases and elastic pools. De prijs van back-upopslag is onderdeel van de prijs van de data base of groep.The price of backup storage is a part of database or pool price.

vCore-modelvCore model

Voor afzonderlijke data bases in SQL Database is een back-upopslagwaarde gelijk aan 100 procent van de maximale grootte van de gegevens opslag voor de data base, zonder extra kosten.For single databases in SQL Database, a backup storage amount equal to 100 percent of the maximum data storage size for the database is provided at no extra charge. Voor elastische Pools en beheerde instanties is een back-upopslagwaarde gelijk aan 100 procent van de maximale gegevens opslag voor de pool of de maximale grootte van het exemplaar van de opslag, respectievelijk, zonder extra kosten.For elastic pools and managed instances, a backup storage amount equal to 100 percent of the maximum data storage for the pool or the maximum instance storage size, respectively, is provided at no extra charge.

Voor afzonderlijke data bases wordt deze vergelijking gebruikt voor het berekenen van het totale factureer bare gebruik van back-ups:For single databases, this equation is used to calculate the total billable backup storage usage:

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

Voor gegroepeerde Data bases wordt de totale factureer bare opslag grootte geaggregeerd op het groeps niveau en wordt als volgt berekend:For pooled databases, the total billable backup storage size is aggregated at the pool level and is calculated as follows:

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 instanties wordt de totale factureer bare opslag grootte op het exemplaar niveau geaggregeerd en als volgt berekend:For managed instances, the total billable backup storage size is aggregated at the instance level and is calculated as follows:

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 factureer bare back-upopslag wordt in GB per maand in rekening gebracht op basis van de frequentie van de gebruikte back-upopslag-redundantie.Total billable backup storage, if any, will be charged in GB/month as per the rate of the backup storage redundancy used. Dit verbruik van back-upopslag is afhankelijk van de werk belasting en de grootte van afzonderlijke data bases, elastische Pools en beheerde exemplaren.This backup storage consumption will depend on the workload and size of individual databases, elastic pools, and managed instances. Sterk gewijzigde data bases hebben meer differentiële en logboek back-ups, omdat de grootte van deze back-ups evenredig is met de hoeveelheid gegevens wijzigingen.Heavily modified databases have larger differential and log backups, because the size of these backups is proportional to the amount of data changes. Daarom zullen dergelijke data bases hogere back-upkosten hebben.Therefore, such databases will have higher backup charges.

SQL Database en SQL Managed instance berekent uw totale factureer bare back-upopslag als een cumulatieve waarde voor alle back-upbestanden.SQL Database and SQL Managed Instance computes your total billable backup storage as a cumulative value across all backup files. Elk uur wordt deze waarde gerapporteerd aan de Azure-facturerings pijplijn, waarmee dit uur gebruik wordt geaggregeerd om het verbruik van back-upopslag aan het einde van elke maand te verkrijgen.Every hour, this value is reported to the Azure billing pipeline, which aggregates this hourly usage to get your backup storage consumption at the end of each month. Als een Data Base wordt verwijderd, neemt het verbruik van back-upopslag geleidelijk af naarmate oudere back-ups worden verwijderd.If a database is deleted, backup storage consumption will gradually decrease as older backups age out and are deleted. Omdat voor differentiële back-ups en logboek back-ups een eerdere volledige back-up kan worden herstorable, worden alle drie de back-uptypen samen in wekelijkse sets opgeschoond.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets. Zodra alle back-ups zijn verwijderd, wordt de facturering gestopt.Once all backups are deleted, billing stops.

Als een vereenvoudigd voor beeld wordt ervan uitgegaan dat een Data Base 744 GB back-upopslag heeft gecumuleerd en dat deze hoeveelheid gedurende een hele maand constant blijft, omdat de data base volledig niet actief is.As a simplified example, assume a database has accumulated 744 GB of backup storage and that this amount stays constant throughout an entire month because the database is completely idle. Als u dit cumulatieve opslag gebruik wilt converteren naar het uurverbruik, deelt u dit op 744,0 (31 dagen per maand * 24 uur per dag).To convert this cumulative storage consumption to hourly usage, divide it by 744.0 (31 days per month * 24 hours per day). SQL Database meldt zich aan de Azure-facturerings pijplijn dat de data base elk uur 1 GB PITR-back-up heeft verbruikt, tegen een constant tarief.SQL Database will report to Azure billing pipeline that the database consumed 1 GB of PITR backup each hour, at a constant rate. In azure billing wordt dit verbruik geaggregeerd en wordt een gebruik van 744 GB voor de hele maand weer gegeven.Azure billing will aggregate this consumption and show a usage of 744 GB for the entire month. De kosten worden berekend op basis van het percentage van de hoeveelheid/GB per maand in uw regio.The cost will be based on the amount/GB/month rate in your region.

Nu is een complexere voor beeld.Now, a more complex example. Stel dat voor dezelfde niet-actieve Data Base de Bewaar periode van 7 dagen tot 14 dagen in het midden van de maand is verhoogd.Suppose the same idle database has its retention increased from 7 days to 14 days in the middle of the month. Dit verhoogt de resultaten van de totale back-upopslag, verdubbeld tot 1.488 GB.This increase results in the total backup storage doubling to 1,488 GB. SQL Database zou 1 GB aan gebruik melden voor uren 1 tot en met 372 (de eerste helft van de maand).SQL Database would report 1 GB of usage for hours 1 through 372 (the first half of the month). Hiermee wordt het gebruik gerapporteerd als 2 GB voor uren 373 tot 744 (de tweede helft van de maand).It would report the usage as 2 GB for hours 373 through 744 (the second half of the month). Dit gebruik wordt geaggregeerd naar een voltooide factuur van 1.116 GB/maand.This usage would be aggregated to a final bill of 1,116 GB/month.

De daad werkelijke facturerings scenario's voor back-ups zijn complexer.Actual backup billing scenarios are more complex. Omdat de frequentie van de wijzigingen in de data base afhankelijk is van de werk belasting en de variabele gedurende een bepaalde periode, is de grootte van elke differentiële back-up en logboek registratie ook afhankelijk, waardoor het verbruik van de back-upopslag per uur dienovereenkomstig wordt geschommeld.Because the rate of changes in the database depends on the workload and is variable over time, the size of each differential and log backup will vary as well, causing the hourly backup storage consumption to fluctuate accordingly. Daarnaast bevat elke differentiële back-up alle wijzigingen die zijn aangebracht in de data base sinds de laatste volledige back-up, waardoor de totale grootte van alle differentiële back-ups geleidelijk in de loop van een week toeneemt en vervolgens weer wordt versneld als er een oudere set van volledige, differentiële en logboek back-ups wordt weer gegeven. Als er bijvoorbeeld een zware schrijf activiteit zoals het opnieuw opbouwen van de index is uitgevoerd nadat een volledige back-up is voltooid, worden de wijzigingen die zijn aangebracht door het opnieuw opbouwen van de index opgenomen in de back-ups van de transactie logboeken die zijn gemaakt tijdens het opnieuw opbouwen, in de volgende differentiële back-up en in elke differentiële back-up die tot de volgende volledige back-up wordtFurthermore, each differential backup contains all changes made in the database since the last full backup, thus the total size of all differential backups gradually increases over the course of a week, and then drops sharply once an older set of full, differential, and log backups ages out. For example, if a heavy write activity such as index rebuild has been run just after a full backup completed, then the modifications made by the index rebuild will be included in the transaction log backups taken over the duration of rebuild, in the next differential backup, and in every differential backup taken until the next full backup occurs. Voor het laatste scenario in grotere data bases maakt een optimalisatie in de service een volledige back-up in plaats van een differentiële back-up als een differentiële back-up uitzonderlijk groot zou zijn.For the latter scenario in larger databases, an optimization in the service creates a full backup instead of a differential backup if a differential backup would be excessively large otherwise. Dit beperkt de grootte van alle differentiële back-ups tot de volgende volledige back-up.This reduces the size of all differential backups until the following full backup.

U kunt het totale opslag verbruik van back-ups voor elk back-uptype (volledig, Differentieel, transactie logboek) in de loop van de tijd bewaken, zoals beschreven in het monitor gebruik.You can monitor total backup storage consumption for each backup type (full, differential, transaction log) over time as described in Monitor consumption.

Opslag redundantie van back-upsBackup storage redundancy

Opslag redundantie van back-ups heeft gevolgen voor back-upkosten op de volgende manier:Backup storage redundancy impacts backup costs in the following way:

  • lokaal redundante prijs = xlocally-redundant price = x
  • zone-redundante prijs = 1,25 xzone-redundant price = 1.25x
  • geografisch redundante prijs = 2xgeo-redundant price = 2x

Ga voor meer informatie over prijzen voor back-upopslag naar Azure SQL database prijs pagina en de pagina met prijzen voor Azure SQL Managed instance.For more details about backup storage pricing visit Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

Belangrijk

Configureer bare back-upopslag redundantie voor een SQL Managed instance is beschikbaar in alle Azure-regio's en is momenteel alleen beschikbaar in Zuidoost-Azië Azure-regio voor SQL Database.Configurable backup storage redundancy for SQL Managed instance is available in all Azure regions and currently available in Southeast Asia Azure region only for SQL Database. Voor een beheerd exemplaar kan dit alleen worden opgegeven tijdens het proces voor het maken van een beheerd exemplaar.For Managed Instance it can only be specified during the create managed instance process. Zodra de resource is ingericht, kunt u de optie voor opslag redundantie van back-ups niet meer wijzigen.Once the resource is provisioned, you cannot change the backup storage redundancy option.

Kosten bewakenMonitor costs

Als u meer wilt weten over de kosten voor back-upopslag, gaat u naar Cost Management + facturering in de Azure Portal, selecteert u Cost Management en selecteert u vervolgens kosten analyse.To understand backup storage costs, go to Cost Management + Billing in the Azure portal, select Cost Management, and then select Cost analysis. Selecteer het gewenste abonnement als bereik en filter vervolgens op de periode en service waarop u bent geïnteresseerd.Select the desired subscription as the Scope, and then filter for the time period and service that you're interested in.

Voeg een filter toe voor service naam en selecteer vervolgens SQL data base in de vervolg keuzelijst.Add a filter for Service name, and then select sql database in the drop-down list. Gebruik het filter meter subcategorie om de facturerings teller voor uw service te kiezen.Use the meter subcategory filter to choose the billing counter for your service. Selecteer voor één data base of een pool voor elastische Data Base één/elastische pool PITR back-upopslag.For a single database or an elastic database pool, select single/elastic pool PITR backup storage. Voor een beheerd exemplaar selecteert u mi PITR Backup Storage.For a managed instance, select mi PITR backup storage. De subcategorieën voor opslag en berekening kunnen u ook interesseren, maar ze zijn niet gekoppeld aan back-upopslagkosten.The Storage and compute subcategories might interest you as well, but they're not associated with backup storage costs.

Kosten analyse back-upopslag

Notitie

Meters zijn alleen zichtbaar voor prestatie meter items die momenteel in gebruik zijn.Meters are only visible for counters that are currently in use. Als een item niet beschikbaar is, is het waarschijnlijk dat de categorie momenteel niet wordt gebruikt.If a counter is not available, it is likely that the category is not currently being used. Managed instance Counters is bijvoorbeeld niet aanwezig voor klanten die geen beheerd exemplaar hebben geïmplementeerd.For example, managed instance counters will not be present for customers who do not have a managed instance deployed. Opslag tellers zijn ook niet zichtbaar voor bronnen die geen opslag ruimte gebruiken.Likewise, storage counters will not be visible for resources that are not consuming storage.

Versleutelde back-upsEncrypted backups

Als uw data base is versleuteld met TDE, worden back-ups automatisch versleuteld op rest, waaronder LTR-back-ups.If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. Alle nieuwe data bases in Azure SQL worden geconfigureerd met TDE standaard ingeschakeld.All new databases in Azure SQL are configured with TDE enabled by default. Zie transparent Data Encryption met SQL Database & Managed instancevoor meer informatie over TDe.For more information on TDE, see Transparent Data Encryption with SQL Database & SQL Managed Instance.

Back-upintegriteitBackup integrity

Het Azure SQL engineering-team test automatisch het herstellen van automatische database back-ups.On an ongoing basis, the Azure SQL engineering team automatically tests the restore of automated database backups. (Deze test is momenteel niet beschikbaar in het SQL Managed instance.) Bij herstel naar een bepaald tijdstip ontvangen data bases ook DBCC CHECKDB-integriteits controles.(This testing is not currently available in SQL Managed Instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

Problemen die tijdens de integriteits controle worden gevonden, zullen leiden tot een waarschuwing voor het technische team.Any issues found during the integrity check will result in an alert to the engineering team. Zie gegevens integriteit in SQL databasevoor meer informatie.For more information, see Data Integrity in SQL Database.

Alle database back-ups worden gemaakt met de CONTROLESOM optie om extra back-upintegriteit te bieden.All database backups are taken with the CHECKSUM option to provide additional backup integrity.

NalevingCompliance

Wanneer u uw data base migreert van een service tier op basis van DTU naar een vCore service tier, blijft de retentie van de PITR bewaard om ervoor te zorgen dat het gegevens herstel beleid van uw toepassing niet wordt aangetast.When you migrate your database from a DTU-based service tier to a vCore-based service tier, the PITR retention is preserved to ensure that your application's data recovery policy isn't compromised. Als de standaard retentie niet voldoet aan uw nalevings vereisten, kunt u de retentie periode van PITR wijzigen.If the default retention doesn't meet your compliance requirements, you can change the PITR retention period. Zie de retentie periode voor PITR-back-ups wijzigenvoor meer informatie.For more information, see Change the PITR backup retention period.

Notitie

Dit artikel bevat stappen voor als u persoonlijke gegevens van het apparaat of de service wilt verwijderen. Bovendien kunt u het gebruiken om uw verplichtingen met betrekking tot de AVG na te komen.This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. Zie het gedeelte AVG van de Service Trust Portal als u op zoek bent naar algemene informatie over de AVG.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

De retentie periode voor PITR-back-ups wijzigenChange the PITR backup retention period

U kunt de standaard retentie periode voor PITR-back-ups wijzigen met behulp van de Azure Portal, Power shell of de REST API.You can change the default PITR backup retention period by using the Azure portal, PowerShell, or the REST API. In de volgende voor beelden ziet u hoe u de retentie van PITR wijzigt in 28 dagen.The following examples illustrate how to change the PITR retention to 28 days.

Waarschuwing

Als u de huidige retentie periode verlaagt, verliest u de mogelijkheid om te herstellen naar punten die ouder zijn dan de nieuwe Bewaar periode.If you reduce the current retention period, you lose the ability to restore to points in time older than the new retention period. Back-ups die niet meer nodig zijn voor het leveren van PITR binnen de nieuwe Bewaar periode, worden verwijderd.Backups that are no longer needed to provide PITR within the new retention period are deleted. Als u de huidige retentie periode verhoogt, hebt u niet onmiddellijk de mogelijkheid om binnen de nieuwe Bewaar periode naar oudere tijdstippen te herstellen.If you increase the current retention period, you do not immediately gain the ability to restore to older points in time within the new retention period. U krijgt deze mogelijkheid na verloop van tijd, naarmate het systeem meer back-ups gaat bewaren.You gain that ability over time, as the system starts to retain backups for longer.

Notitie

Deze Api's zijn alleen van invloed op de PITR-retentie periode.These APIs will affect only the PITR retention period. Als u LTR hebt geconfigureerd voor uw data base, heeft dit geen invloed op dit probleem.If you configured LTR for your database, it won't be affected. Zie lange termijn retentievoor informatie over het wijzigen van v.l.n.r.-Bewaar perioden.For information about how to change LTR retention periods, see Long-term retention.

De retentie periode voor PITR-back-ups wijzigen met behulp van de Azure PortalChange the PITR backup retention period by using the Azure portal

Als u de retentie periode voor PITR voor actieve data bases met behulp van de Azure Portal wilt wijzigen, gaat u naar de server of het beheerde exemplaar met de data bases waarvan u de Bewaar periode wilt wijzigen.To change the PITR backup retention period for active databases by using the Azure portal, go to the server or managed instance with the databases whose retention period you want to change.

Wijzigingen in PITR voor het bewaren van back-ups voor SQL Database worden uitgevoerd op de server pagina in de portal.Changes to PITR backup retention for SQL Database are done on the server page in the portal. Als u de retentie van PITR voor data bases op een server wilt wijzigen, gaat u naar de Blade Server overzicht.To change PITR retention for databases on a server, go to the server overview blade. Selecteer back-ups beheren in het linkerdeel venster, selecteer de data bases binnen het bereik van uw wijziging en selecteer vervolgens retentie configureren aan de bovenkant van het scherm:Select Manage Backups in the left pane, select the databases in scope of your change, and then select Configure retention at the top of the screen:

PITR-retentie, server niveau wijzigen

De retentie periode voor PITR-back-ups wijzigen met behulp van Power shellChange the PITR backup retention period by using PowerShell

Notitie

Dit artikel is bijgewerkt voor het gebruik van de nieuwe Azure PowerShell Az-module.This article has been updated to use the new Azure PowerShell Az module. De AzureRM-module kan nog worden gebruikt en krijgt bugoplossingen tot ten minste december 2020.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Zie voor meer informatie over de nieuwe Az-module en compatibiliteit met AzureRM Introductie van de nieuwe Az-module van Azure PowerShell.To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Raadpleeg Azure PowerShell installeren voor instructies over de installatie van de Az-module.For Az module installation instructions, see Install Azure PowerShell.

Belangrijk

De Power shell AzureRM-module wordt nog steeds ondersteund door SQL Database en SQL Managed instance, maar alle toekomstige ontwikkeling is voor de module AZ. SQL.The PowerShell AzureRM module is still supported by SQL Database and SQL Managed Instance, but all future development is for the Az.Sql module. Zie AzureRM. SQLvoor meer informatie.For more information, see AzureRM.Sql. De argumenten voor de opdrachten in de module AZ zijn vrijwel identiek aan die in de AzureRm-modules.The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

Gebruik het volgende Power shell-voor beeld om de PITR-retentie voor actieve Azure SQL-data bases te wijzigen.To change the PITR backup retention for active Azure SQL Databases, use the following PowerShell example.

# 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

De retentie periode voor PITR-back-ups wijzigen met behulp van de REST APIChange the PITR backup retention period by using the REST API

Voorbeeld aanvraagSample request

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

AanvraagbodyRequest body

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

VoorbeeldantwoordSample response

Status code: 200Status code: 200

{
  "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
  }
}

Zie retentie van back-ups rest APIvoor meer informatie.For more information, see Backup Retention REST API.

Voorbeeld aanvraagSample request

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

AanvraagbodyRequest body

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

VoorbeeldantwoordSample response

Status code: 200Status code: 200

{
  "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
  }
}

Zie retentie van back-ups rest APIvoor meer informatie.For more information, see Backup Retention REST API.

Opslag redundantie voor back-ups configurerenConfigure backup storage redundancy

Notitie

Configureer bare opslag redundantie voor back-ups voor SQL Managed instance kan alleen worden opgegeven tijdens het proces voor het maken van een beheerd exemplaar.Configurable storage redundancy for backups for SQL Managed Instance can only be specified during the create managed instance process. Zodra de resource is ingericht, kunt u de optie voor opslag redundantie van back-ups niet meer wijzigen.Once the resource is provisioned, you can't change the backup storage redundancy option. Voor SQL Database is de open bare preview van deze functie momenteel beschikbaar in Brazilië-zuid en is deze algemeen beschikbaar in de Azure-regio Zuidoost-Azië.For SQL Database, public preview of this feature is currently available in Brazil South and it is generally available in Southeast Asia Azure region.

Een opslag redundantie van een back-up van een beheerd exemplaar kan worden ingesteld tijdens het maken van een exemplaar.A backup storage redundancy of a managed instance can be set during instance creation only. Voor een SQL Database kan deze worden ingesteld bij het maken van de data base of kan worden bijgewerkt voor een bestaande data base.For a SQL Database it can be set when creating the database or can be updated for an existing database. De standaard waarde is geografisch redundante opslag.The default value is geo-redundant storage. Bezoek de pagina met prijzen voor Managed instancesvoor verschillen in de prijs tussen lokaal redundante, zone-redundante en geografisch redundante back-upopslag.For differences in pricing between locally-redundant, zone-redundant and geo-redundant backup storage visit managed instance pricing page.

Opslag redundantie voor back-ups configureren met behulp van de Azure PortalConfigure backup storage redundancy by using the Azure portal

In Azure Portal kunt u de redundantie opslag voor back-ups configureren op de Blade SQL database maken .In Azure portal, you can configure the backup storage redundancy on the Create SQL Database blade. Deze optie is beschikbaar in de sectie opslag redundantie van back-ups.The option is available under the Backup Storage Redundancy section. SQL Database Blade maken openenOpen Create SQL Database blade

Opslag redundantie voor back-ups configureren met behulp van Power shellConfigure backup storage redundancy by using PowerShell

Als u de redundantie van back-upopslag wilt configureren bij het maken van een nieuwe Data Base, kunt u de para meter-BackupStoageRedundancy opgeven.To configure backup storage redundancy when creating a new database you can specify the -BackupStoageRedundancy parameter. Mogelijke waarden zijn geo, zone en local.Possible values are Geo, Zone and Local. Standaard gebruiken alle SQL-data bases geo-redundante opslag voor back-ups.By default, all SQL Databases use geo-redundant storage for backups. Geo Restore is uitgeschakeld als er een Data Base wordt gemaakt met een lokale of zone redundante back-upopslag.Geo Restore is disabled if a database is created with local or zone redundant backup storage.

# 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

Ga voor meer informatie naar New-AzSqlDatabase.For details visit New-AzSqlDatabase.

Als u de redundantie van back-upopslag van een bestaande Data Base wilt bijwerken, kunt u de para meter-BackupStorageRedundancy gebruiken.To update backup storage redundancy of an existing database, you can use the -BackupStorageRedundancy parameter. Mogelijke waarden zijn geo, zone en local.Possible values are Geo, Zone and Local. Houd er rekening mee dat het tot 48 uur kan duren voordat de wijzigingen op de Data Base worden toegepast.Note that, it may take up to 48 hours for the changes to be applied on the database. Als u overschakelt van geografisch redundante back-upopslag naar lokale of zone redundante opslag, wordt geo Restore uitgeschakeld.Switching from geo-redundant backup storage to local or zone redundant storage disables geo restore.

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

Ga voor meer informatie naar set-AzSqlDatabaseFor details visit Set-AzSqlDatabase

Notitie

Als u de para meter-BackupStorageRedundancy wilt gebruiken bij het herstellen van de data base, het kopiëren van de data base of het maken van secundaire bewerkingen, gebruikt u Azure PowerShell versie AZ. SQLTo use -BackupStorageRedundancy parameter with database restore, database copy or create secondary operations, use Azure PowerShell version Az.Sql 2.11.0.

Azure Policy gebruiken om redundantie van back-upopslag af te dwingenUse Azure Policy to enforce backup storage redundancy

Als u gegevens locatie vereisten hebt waarbij u al uw gegevens in één Azure-regio moet houden, wilt u mogelijk zone redundante of lokaal redundante back-ups voor uw SQL Database of beheerde instantie afdwingen met behulp van Azure Policy.If you have data residency requirements that require you to keep all your data in a single Azure region, you may want to enforce zone-redundant or locally-redundant backups for your SQL Database or Managed Instance using Azure Policy. Azure Policy is een service die u kunt gebruiken om beleid te maken, toe te wijzen en te beheren waarmee regels worden toegepast op Azure-resources.Azure Policy is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure Policy helpt u bij het houden van deze resources die voldoen aan uw bedrijfs normen en service overeenkomsten.Azure Policy helps you to keep these resources compliant with your corporate standards and service level agreements. Zie Overzicht van Azure Policy voor meer informatie.For more information, see Overview of Azure Policy.

Ingebouwde beleids regels voor back-upopslagBuilt-in backup storage redundancy policies

Volgende nieuwe ingebouwde beleids regels worden toegevoegd, die kunnen worden toegewezen op het niveau van het abonnement of de resource groep om het maken van nieuwe data base (s) of exemplaren met geografisch redundante back-upopslag te blok keren.Following new built-in policies are added, which can be assigned at the subscription or resource group level to block creation of new database(s) or instance(s) with geo-redundant backup storage.

SQL Database moet het gebruik van GRS-back-up-redundantie voorkomenSQL Database should avoid using GRS backup redundancy

Door SQL beheerde instanties moeten het gebruik van GRS-back-up-redundantie voorkomenSQL Managed Instances should avoid using GRS backup redundancy

Hiervindt u een volledige lijst met ingebouwde beleids definities voor de SQL database en het beheerde exemplaar.A full list of built-in policy definitions for SQL Database and Managed Instance can be found here.

Voor het afdwingen van vereisten voor gegevens locatie op een organisatie niveau, kunnen deze beleids regels worden toegewezen aan een abonnement.To enforce data residency requirements at an organizational level, these policies can be assigned to a subscription. Nadat deze zijn toegewezen op abonnements niveau, kunnen gebruikers in het gegeven abonnement geen data base of een beheerd exemplaar maken met geografisch redundante back-upopslag via Azure Portal of Azure PowerShell.After these are assigned at a subscription level, users in the given subscription will not be able to create a database or a managed instance with geo-redundant backup storage via Azure portal or Azure PowerShell.

Belangrijk

Azure-beleid wordt niet afgedwongen bij het maken van een Data Base via T-SQL.Azure policies are not enforced when creating a database via T-SQL. Als u gegevens locatie wilt afdwingen bij het maken van een Data Base met behulp van T-SQL, gebruikt u ' local ' of ' zone ' als invoer voor BACKUP_STORAGE_REDUNDANCY para meter in de instructie Create Data Base.To enforce data residency when creating a database using T-SQL, use 'LOCAL' or 'ZONE' as input to BACKUP_STORAGE_REDUNDANCY paramater in CREATE DATABASE statement.

Meer informatie over het toewijzen van beleid met behulp van de Azure Portal of Azure PowerShellLearn how to assign policies using the Azure portal or Azure PowerShell

Volgende stappenNext steps