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

VAN TOEPASSING OP: jaAzure SQL Database jaMet Azure SQL beheerd exemplaar APPLIES TO: yesAzure SQL Database yesAzure 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

Belangrijk

Configureer bare opslag redundantie voor back-ups is momenteel alleen beschikbaar voor SQL Managed instance en kan alleen worden opgegeven tijdens het proces voor het maken van een beheerd exemplaar.Configurable storage redundancy for backups is currently only available for SQL Managed Instance, and 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.

De optie voor het configureren van redundantie opslag voor back-ups biedt de flexibiliteit om te kiezen tussen lokaal redundante (LRS), zone redundante (ZRS) of geografisch redundante (RA-GRS) opslag-blobs.The option to configure backup storage redundancy provides the flexibility to choose between locally-redundant (LRS), zone-redundant (ZRS) or geo-redundant (RA-GRS) storage blobs. 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. Deze functie is momenteel alleen beschikbaar voor SQL Managed instance.This feature is currently only available for SQL Managed Instance.

RA-GRS-opslag-blobs worden gerepliceerd naar een gekoppeld gebied om te beschermen tegen storingen die van invloed zijn op de back-upopslag in de primaire regio en u in staat stellen om uw server te herstellen naar een andere regio in het geval van een ramp.RA-GRS storage blobs are replicated to a paired region 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.

LRS-en ZRS-opslag-blobs zorgen ervoor dat uw gegevens binnen dezelfde regio blijven waar uw SQL Database of SQL Managed instance wordt geïmplementeerd.Conversely, LRS and ZRS storage blobs ensure that your data stays within the same region where your SQL Database or SQL Managed Instance is deployed. Zone-redundante opslag (ZRS) is momenteel alleen beschikbaar in bepaalde regio's.Zone-redundant storage (ZRS) is currently only available in certain regions).

Belangrijk

In het SQL Managed instance wordt de geconfigureerde back-upredundantie toegepast op de instellingen voor retentie van back-ups op korte termijn die worden gebruikt voor herstel van een punt in tijd (PITR) en back-ups voor lange termijn retentie die worden gebruikt voor langdurige back-ups (LTR).In SQL Managed Instance, the configured backup 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).

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 beheerde exemplaren met geconfigureerde geo-redundante (RA-GRS) back-upopslag.Geo-restore is available only for managed instances with configured geo-redundant (RA-GRS) 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)

Retentie van back-upsBackup 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-data bases, 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 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.

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.Total billable backup storage, if any, will be charged in GB/month. 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:

  • LRS prijs = xLRS price = x
  • ZRS prijs = 1,25 xZRS price = 1.25x
  • RA-GRS prijs = 2xRA-GRS 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 opslag redundantie voor back-ups is momenteel alleen beschikbaar voor SQL Managed instance en kan alleen worden opgegeven tijdens het proces voor het maken van een beheerd exemplaar.Configurable storage redundancy for backups is currently only available for SQL Managed Instance, and 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.

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 Managementen 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 bereiken 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 naamen 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 is momenteel alleen beschikbaar voor SQL Managed instance en kan alleen worden opgegeven tijdens het proces voor het maken van een beheerd exemplaar.Configurable storage redundancy for backups is currently only available for SQL Managed Instance, and 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.

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. De standaard waarde is geografisch redundante opslag (RA-GRS).The default value is geo-redundant storage (RA-GRS). Zie de pagina met prijzen voor Managed instance(Engelstalig) voor verschillen in de prijs van een LRS (Local-redundante), zone-redundante (ZRS) en geo-redundante (RA-GRS)-back-upopslag.For differences in pricing between locally-redundant (LRS), zone-redundant (ZRS) and geo-redundant (RA-GRS) 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 de Azure Portal, de optie voor het wijzigen van de redundantie van back-upopslag bevindt zich op de Blade Compute + Storage die toegankelijk is via de optie Managed instance configureren op het tabblad basis beginselen wanneer u uw SQL Managed instance maakt.In the Azure portal, the option to change backup storage redundancy is located on the Compute + storage blade accessible from the Configure Managed Instance option on the Basics tab when you are creating your SQL Managed Instance. Berekenings-en opslag configuratie openen-BladeOpen Compute+Storage configuration-blade

Zoek de optie voor het selecteren van back-upopslag redundantie op de Blade reken kracht en opslag .Find the option to select backup storage redundancy on the Compute + storage blade. Opslag redundantie voor back-ups configurerenConfigure backup storage redundancy

Volgende stappenNext steps