Автоматическое резервное копирование базы данных SQL Azure & SQL Управляемый экземплярAutomated backups - Azure SQL Database & SQL Managed Instance

ОБЛАСТЬ ПРИМЕНЕНИЯ: даБаза данных SQL Azure даУправляемый экземпляр SQL Azure APPLIES TO: yesAzure SQL Database yesAzure SQL Managed Instance

Примечание

В этой статье приведены пошаговые инструкции по удалению персональных данных с устройства или из службы. Эти сведения можно использовать для соблюдения обязательств согласно Общему регламенту по защите данных (GDPR).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. Если вы ищете общие сведения о GDPR, см. раздел о GDPR на Service Trust Portal.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

Что такое резервная копия базы данных?What is a database backup?

Резервные копии баз данных являются важнейшей частью любой стратегии непрерывности бизнес-процессов и аварийного восстановления, так как они защищают данные от повреждения или удаления.Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or deletion.

Как база данных SQL, так и SQL Управляемый экземпляр используют технологию SQL Server для создания полных резервных копий каждую неделю, разностные резервные копии каждые 12-24 часов и резервные копии журналов транзакций каждые 5 – 10 минут.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. Периодичность резервного копирования журнала транзакций зависит от размера вычислений и объема активности базы данных.The frequency of transaction log backups is based on the compute size and the amount of database activity.

При восстановлении базы данных служба определяет, какие резервные копии полных, разностных и журналов транзакций необходимо восстановить.When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.

Эти резервные копии позволяют восстановить базу данных на определенный момент времени в течение заданного срока хранения.These backups enable database restore to a point in time within the configured retention period. Резервные копии хранятся в виде больших двоичных объектов хранилища RA-GRS , которые реплицируются в парный регион для защиты от простоев, влияющих на хранилище резервных копий в основном регионе.The backups are stored as RA-GRS storage blobs that are replicated to a paired region for protection against outages impacting backup storage in the primary region.

Если для правил защиты данных требуется, чтобы резервные копии были доступны в течение длительного времени (до 10 лет), можно настроить долгосрочное хранение как для одной, так и для баз данных в составе пула.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.

Эти резервные копии позволяют выполнить следующие операции:You can use these backups to:

  • Восстановите существующую базу данных до точки во времени в прошлом в течение срока хранения с помощью портал Azure, Azure PowerShell, Azure CLI или REST API.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. Для баз данных одной и нескольких групп эта операция создает новую базу данных на том же сервере, что и исходная база данных, но под другим именем, чтобы избежать перезаписи исходной базы данных.For single and pooled databases, this operation will create a new database on the same server as the original database, but under a different name to avoid overwriting the original database. После завершения восстановления можно удалить или Переименовать исходную базу данных и переименовать восстановленную базу данных, чтобы она соимела имя исходной базы данных.Once restore completes, you can delete or rename the original database, and rename the restored database to have the original database name. На управляемом экземпляре эта операция также может создать копию базы данных на том же или другом управляемом экземпляре в той же подписке и в том же регионе.On a managed instance, this operation can similarly create a copy of the database on the same or a different managed instance under the same subscription and in the same region.
  • Восстановление удаленной базы данных до момента удаления или в любой момент времени в течение срока хранения.Restore a deleted database to the time of deletion or to any point in time within the retention period. Удаленную базу данных можно восстановить только на том же сервере или в управляемом экземпляре, где была создана исходная база данных.The deleted database can be restored only on the same server or managed instance where the original database was created. При удалении базы данных служба выполняет окончательную резервную копию журнала транзакций перед удалением, чтобы предотвратить потери данных.When deleting a database, the service takes a final transaction log backup before deletion, to prevent any data loss.
  • Восстановление базы данных в другой географический регион.Restore a database to another geographic region. Геовосстановление позволяет восстанавливаться после географической аварии, когда доступ к базе данных или резервным копиям в основном регионе невозможен.Geo-restore allows you to recover from a geographic disaster when you cannot access your database or backups in the primary region. Она создает новую базу данных на любом существующем сервере или управляемом экземпляре в любом регионе Azure.It creates a new database on any existing server or managed instance, in any Azure region.
  • Восстановление базы данных из определенной долгосрочной резервной копии отдельной базы данных или базы данных в составе пула, если для базы данных настроена политика долгосрочного хранения (LTR).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). LTR позволяет восстановить старую версию базы данных с помощью портал Azure или Azure PowerShell для удовлетворения запроса на соответствие или запуска старой версии приложения.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. Дополнительные сведения см. в разделе долгосрочное хранение.For more information, see Long-term retention.

Сведения о выполнении восстановления см. в разделе Восстановление базы данных из резервных копий.To perform a restore, see Restore database from backups.

Примечание

В службе хранилища Azure термин репликация означает копирование больших двоичных объектов из одного расположения в другое.In Azure Storage, the term replication refers to copying blobs from one location to another. В SQL репликация базы данных относится к различным технологиям, используемым для синхронизации нескольких баз данных-получателей с первичной базой данных.In SQL, database replication refers to various technologies used to keep multiple secondary databases synchronized with a primary database.

Вы можете выполнить операции резервного копирования и восстановления, используя следующие примеры:You can try backup configuration and restore operations using the following examples:

Портал AzureAzure portal Azure PowerShellAzure PowerShell
Изменение срока хранения резервной копииChange backup retention Отдельная база данныхSingle database
Управляемый экземплярManaged instance
Отдельная база данныхSingle database
Управляемый экземплярManaged instance
Изменение долгосрочного хранения резервных копийChange long-term backup retention Отдельная база данныхSingle database
Управляемый экземпляр — н/дManaged instance - N/A
Отдельная база данныхSingle database
Управляемый экземпляр — н/дManaged instance - N/A
Восстановление базы данных на момент времениRestore a database from a point in time Отдельная база данныхSingle database Отдельная база данныхSingle database
Управляемый экземплярManaged instance
Восстановление удаленной базы данныхRestore a deleted database Отдельная база данныхSingle database Отдельная база данныхSingle database
Управляемый экземплярManaged instance
Восстановление базы данных из хранилища BLOB-объектов AzureRestore a database from Azure Blob storage Отдельная база данных — н/дSingle database - N/A
Управляемый экземпляр — н/дManaged instance - N/A
Отдельная база данных — н/дSingle database - N/A
Управляемый экземплярManaged instance

Планирование резервного копированияBackup scheduling

Первая полная резервная копия планируется сразу же после создания или восстановления новой базы данных.The first full backup is scheduled immediately after a new database is created or restored. Эта резервная копия обычно завершается в течение 30 минут, но при большом объеме базы данных может потребоваться больше времени.This backup usually completes within 30 minutes, but it can take longer when the database is large. Например, начальное резервное копирование может занять больше времени в восстановленной базе данных или копии базы данных, что, как правило, больше, чем новая база данных.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. После первого полного резервного копирования все дальнейшие резервные копии планируются и управляются автоматически.After the first full backup, all further backups are scheduled and managed automatically. Точное время резервного копирования всех баз данных определяется базой данных SQL или службой SQL Управляемый экземпляр, так как она распределяет общую рабочую нагрузку системы.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. Нельзя изменить расписание заданий резервного копирования или отключить их.You cannot change the schedule of backup jobs or disable them.

Важно!

Для новой, восстановленной или скопированной базы данных возможность восстановления на момент времени становится доступной с момента создания первоначальной резервной копии журнала транзакций, следующей за начальной полной резервной копией.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.

Использование хранилища резервных копийBackup storage consumption

При использовании SQL Server технологии резервного копирования и восстановления восстановление базы данных на момент времени требует наличия непрерывной цепочки резервных копий, состоящей из одной полной резервной копии, при необходимости одной разностной архивации и одной или нескольких резервных копий журналов транзакций.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. База данных SQL и расписание резервного копирования SQL Управляемый экземпляр включают по одной полной резервной копии каждую неделю.SQL Database and SQL Managed Instance backup schedule includes one full backup every week. Таким образом, чтобы включить PITR в течение всего срока хранения, система должна хранить дополнительные резервные копии полных, разностных и журналов транзакций в течение недели дольше заданного срока хранения.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.

Другими словами, для любой точки во времени в течение срока хранения должна быть полная резервная копия, которая старше, чем самое старое время срока хранения, а также непрерывная цепочка разностных резервных копий и журналов транзакций из этой полной резервной копии до следующей полной резервной копии.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.

Примечание

Чтобы включить PITR, дополнительные резервные копии хранятся в течение недели дольше заданного срока хранения.To enable PITR, additional backups are stored for up to a week longer than the configured retention period. Плата за хранилище резервных копий насчитывается по той же ставке для всех резервных копий.Backup storage is charged at the same rate for all backups.

Резервные копии, которые больше не нужны для предоставления функциональных возможностей PITR, автоматически удаляются.Backups that are no longer needed to provide PITR functionality are automatically deleted. Так как для разностных резервных копий и резервных копий журналов требуется, чтобы была restorable более ранняя полная резервная копия, все три типа резервного копирования удаляются в еженедельные наборы.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets.

Для всех баз данных, включая зашифрованные базы данных TDE, резервные копии сжимаются для уменьшения сжатия и затрат на хранение резервных копий.For all databases including TDE encrypted databases, backups are compressed to reduce backup storage compression and costs. Средняя степень сжатия резервных копий составляет 3-4 раз, однако она может быть значительно ниже или выше в зависимости от характера данных и от того, используется ли сжатие данных в базе данных.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 и SQL Управляемый экземпляр вычисляют общее используемое хранилище резервных копий как совокупное значение.SQL Database and SQL Managed Instance compute your total used backup storage as a cumulative value. Каждый час это значение передается в конвейер выставления счетов Azure, который отвечает за агрегирование этого почасового использования для вычисления потребления в конце каждого месяца.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. После удаления базы данных потребление уменьшается по мере устаревания резервных копий и удаляется.After the database is deleted, consumption decreases as backups age out and are deleted. Когда все резервные копии будут удалены и PITR больше невозможно, выставление счетов прекращается.Once all backups are deleted and PITR is no longer possible, billing stops.

Важно!

Резервные копии базы данных сохраняются для включения PITR, даже если база данных была удалена.Backups of a database are retained to enable PITR even if the database has been deleted. Хотя удаление и повторное создание базы данных может сэкономить на затратах на хранение и вычисление, это может привести к увеличению затрат на хранение резервных копий, так как служба сохраняет резервные копии каждой удаленной базы данных при каждом удалении.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.

Мониторинг потребленияMonitor consumption

Для баз данных Виртуальное ядро хранилище, используемое каждым типом резервных копий (полная, разностная и журнал), отображается в колонке "мониторинг базы данных" как отдельная метрика.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. На следующей схеме показано, как отслеживать потребление хранилища резервных копий для отдельной базы данных.The following diagram shows how to monitor the backup storage consumption for a single database. В настоящее время эта функция недоступна для управляемых экземпляров.This feature is currently not available for managed instances.

Мониторинг потребления резервной копии базы данных в портал Azure

Тонкая настройка использования хранилища резервных копийFine-tune backup storage consumption

Использование хранилища резервных копий вплоть до максимального размера данных для базы данных не будет взиматься.Backup storage consumption up to the maximum data size for a database is not charged. Избыточное потребление хранилища резервных копий будет зависеть от рабочей нагрузки и максимального размера отдельных баз данных.Excess backup storage consumption will depend on the workload and maximum size of the individual databases. Рассмотрите некоторые из следующих методов настройки для уменьшения потребления хранилища резервных копий:Consider some of the following tuning techniques to reduce your backup storage consumption:

  • Сократите срок хранения резервных копий до минимально возможной потребности.Reduce the backup retention period to the minimum possible for your needs.
  • Избегайте выполнения больших операций записи, таких как перестроение индекса, чаще, чем требуется.Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • Для операций загрузки больших данных рассмотрите возможность использования кластеризованных индексов columnstore и следующих связанных рекомендаций, а также уменьшения числа некластеризованных индексов.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 the General Purpose service tier, the provisioned data storage is less expensive than the price of the backup storage. При постоянном повышении затрат на хранение резервных копий можно увеличить объем хранилища данных для сохранения в хранилище резервных копий.If you have continually high excess backup storage costs, you might consider increasing data storage to save on the backup storage.
  • Используйте базу данных TempDB вместо постоянных таблиц в логике приложения для хранения временных результатов и (или) временных данных.Use TempDB instead of permanent tables in your application logic for storing temporary results and/or transient data.

Хранение резервных копийBackup retention

Для всех новых, восстановленных и скопированных баз данных, баз данных SQL Azure и Azure SQL Управляемый экземпляр сохранять достаточно резервных копий, чтобы разрешить PITR в течение последних 7 дней по умолчанию.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. За исключением баз данных с масштабированием, можно изменить срок хранения резервных копий каждой активной базы данных в диапазоне 1-35 дней.With the exception of Hyperscale databases, you can change backup retention period per each active database in the 1-35 day range. Как описано в статье Использование хранилища резервных копий, резервные копии, сохраненные для включения PITR, могут быть старше, чем срок хранения.As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period. Только для Управляемый экземпляр Azure SQL можно задать скорость хранения резервных копий PITR после удаления базы данных в диапазоне 0-35 дней.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.

При удалении базы данных система сохраняет резервные копии так же, как и для базы данных в сети с заданным сроком хранения.If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. Нельзя изменить срок хранения резервной копии для удаленной базы данных.You cannot change backup retention period for a deleted database.

Важно!

При удалении сервера или управляемого экземпляра все базы данных на этом сервере или управляемом экземпляре также удаляются и не могут быть восстановлены.If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. Нельзя восстановить удаленный сервер или управляемый экземпляр.You cannot restore a deleted server or managed instance. Но если вы настроили долгосрочное хранение (LTR) для базы данных или управляемого экземпляра, резервные копии долгосрочного хранения не удаляются и могут использоваться для восстановления баз данных на другом сервере или управляемом экземпляре в той же подписке на момент времени, когда была создана долгосрочная резервная копия хранения.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.

Хранение резервных копий в целях PITR в течение последних 1-35 дней иногда называется краткосрочным хранением резервных копий.Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. Если необходимо хранить резервные копии дольше, чем максимальный период удержания в 35 дней, можно включить долгосрочное хранение.If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.

Длительный период удержанияLong-term retention

Для отдельных баз данных и управляемых экземпляров можно настроить долгосрочное хранение (LTR) полных резервных копий до 10 лет в хранилище BLOB-объектов Azure.For single and pooled databases and managed instances, you can configure long-term retention (LTR) of full backups for up to 10 years in Azure Blob storage. Если включить политику LTR, еженедельные полные резервные копии автоматически копируются в другой контейнер хранилища RA-GRS.If you enable an LTR policy, the weekly full backups are automatically copied to a different RA-GRS storage container. Для удовлетворения различных требований соответствия можно выбрать разные периоды хранения для еженедельных, ежемесячных и (или) ежегодно полных резервных копий.To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. Потребление хранилища зависит от выбранной частоты резервного копирования LTR, а также периода хранения или периодов.The storage consumption depends on the selected frequency of LTR backups, and the retention period or periods. Вы можете использовать Калькулятор цен LTR для оценки стоимости хранения на LTR.You can use the LTR pricing calculator to estimate the cost of LTR storage.

Как и резервные копии PITR, резервное копирование на LTR с геоизбыточным хранилищем защищено.Like PITR backups, LTR backups are protected with geo-redundant storage. Дополнительные сведения см. в статье Репликация службы хранилища Azure.For more information, see Azure Storage redundancy.

Дополнительные сведения о LTR см. в статье долгосрочное хранение резервных копий.For more information about LTR, see Long-term backup retention.

Затраты на хранениеStorage costs

Цена за хранилище зависит от того, используете ли вы модель DTU или модель Виртуальное ядро.The price for storage varies depending on whether you're using the DTU model or the vCore model.

Модель с DTUDTU model

В модели DTU не взимается дополнительная плата за хранение резервных копий для баз данных и эластичных пулов.In the DTU model, there's no additional charge for backup storage for databases and elastic pools. Цена хранилища резервных копий является частью цены на базу данных или пул.The price of backup storage is a part of database or pool price.

Модель с виртуальными ядрамиvCore model

Для одной базы данных в базе данных SQL объем хранилища резервных копий, равный 100 процентам от максимального размера хранилища данных для базы данных, предоставляется без дополнительной платы.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. Для эластичных пулов и управляемых экземпляров объем хранилища резервных копий, равный 100 процентам от максимального объема хранилища данных для пула или максимального размера хранилища, соответственно, предоставляется без дополнительной платы.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.

Для отдельных баз данных это уравнение используется для вычисления общего количества оплачиваемых использованных хранилищ резервных копий: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

Для баз данных в составе пула суммарный размер оплачиваемого хранилища резервных копий вычисляется на уровне пула и вычисляется следующим образом: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

Для управляемых экземпляров общий объем оплачиваемого хранилища резервных копий вычисляется на уровне экземпляра и вычисляется следующим образом: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

Общий объем оплачиваемого хранилища резервных копий, если таковой имеется, будет выставлен в ГБ/месяц.Total billable backup storage, if any, will be charged in GB/month. Это использование хранилища резервных копий зависит от рабочей нагрузки и размера отдельных баз данных, эластичных пулов и управляемых экземпляров.This backup storage consumption will depend on the workload and size of individual databases, elastic pools, and managed instances. Базы данных с интенсивным изменением имеют большие разностные резервные копии и журналы, так как размер этих резервных копий пропорциональен объему изменений данных.Heavily modified databases have larger differential and log backups, because the size of these backups is proportional to the amount of data changes. Таким образом, такие базы данных будут иметь более высокие затраты на резервное копирование.Therefore, such databases will have higher backup charges.

База данных SQL и SQL Управляемый экземпляр рассчитывают общее значение оплачиваемого хранилища резервных копий в виде совокупного значения во всех файлах резервных копий.SQL Database and SQL Managed Instance computes your total billable backup storage as a cumulative value across all backup files. Каждый час это значение передается в конвейер выставления счетов Azure, который объединяет это почасовое использование для получения сведений о потреблении хранилища резервных копий в конце каждого месяца.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. Если база данных удалена, то использование хранилища резервных копий постепенно снизится по мере устаревания старых резервных копий и их удаления.If a database is deleted, backup storage consumption will gradually decrease as older backups age out and are deleted. Так как для разностных резервных копий и резервных копий журналов требуется, чтобы была restorable более ранняя полная резервная копия, все три типа резервного копирования удаляются в еженедельные наборы.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets. После удаления всех резервных копий выставление счетов прекращается.Once all backups are deleted, billing stops.

В качестве упрощенного примера предположим, что база данных накоплена на 744 ГБ хранилища службы архивации и что эта сумма остается постоянной в течение всего месяца, так как база данных полностью бездействует.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. Чтобы преобразовать это совокупное потребление хранилища в почасовое использование, разделите его на 744,0 (31 день в месяц * 24 часа в день).To convert this cumulative storage consumption to hourly usage, divide it by 744.0 (31 days per month * 24 hours per day). База данных SQL сообщит о конвейере выставления счетов Azure о том, что база данных потребляет 1 ГБ резервной копии PITR каждый час с постоянной скоростью.SQL Database will report to Azure billing pipeline that the database consumed 1 GB of PITR backup each hour, at a constant rate. При выставлении счетов Azure будет агрегировано это потребление и показано использование 744 ГБ на весь месяц.Azure billing will aggregate this consumption and show a usage of 744 GB for the entire month. Стоимость будет основываться на ставке суммы/ГБ/месяц в вашем регионе.The cost will be based on the amount/GB/month rate in your region.

Теперь более сложный пример.Now, a more complex example. Предположим, что срок хранения одной и той же простой базы данных увеличился с 7 дней до 14 дней в середине месяца.Suppose the same idle database has its retention increased from 7 days to 14 days in the middle of the month. Это увеличение приводит к увеличению общего объема хранилища резервных копий с удвоением до 1 488 ГБ.This increase results in the total backup storage doubling to 1,488 GB. База данных SQL сообщит об использовании 1 ГБ для часов с 1 по 372 (первая половина месяца).SQL Database would report 1 GB of usage for hours 1 through 372 (the first half of the month). Он будет сообщать об использовании как 2 ГБ для часов с 373 по 744 (вторая половина месяца).It would report the usage as 2 GB for hours 373 through 744 (the second half of the month). Это использование будет агрегировано до окончательной суммы в 1 116 ГБ/месяц.This usage would be aggregated to a final bill of 1,116 GB/month.

Фактические сценарии выставления счетов по резервному копированию являются более сложными.Actual backup billing scenarios are more complex. Поскольку скорость изменений в базе данных зависит от рабочей нагрузки и имеет переменную с течением времени, размер каждой разностной резервной копии и журнала может отличаться, что приведет к неправильному израсходованию почасового хранения резервных копий.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. Более того, каждая разностная резервная копия содержит все изменения, внесенные в базу данных с момента последнего полного резервного копирования, поэтому общий размер всех разностных резервных копий постепенно увеличивается в течение недели, а затем резко снижается, когда возрастает более старый набор полных, разностных и резервных копий журналов. Например, если активное действие записи, такое как перестроение индекса, выполняется сразу после завершения полного резервного копирования, то изменения, внесенные в результате перестроения индекса, будут включаться в резервные копии журналов транзакций, созданные в течение периода перестроения, в следующей разностной резервной копии и в каждой разностной резервной копии, созданной до следующего полного резервного копирования.Furthermore, 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. Для последнего сценария в больших базах данных оптимизация в службе создает полную резервную копию, а не разностную резервную копию, если в противном случае разностная резервная копия слишком велика.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. Это сокращает размер всех разностных резервных копий до создания следующей полной резервной копии.This reduces the size of all differential backups until the following full backup.

Можно отслеживать общее использование хранилища резервных копий для каждого типа резервных копий (полное, разностное, журнал транзакций) с течением времени, как описано в разделе мониторинг потребления.You can monitor total backup storage consumption for each backup type (full, differential, transaction log) over time as described in Monitor consumption.

Мониторинг затратMonitor costs

Чтобы узнать стоимость хранилища резервных копий, выберите Управление затратами + выставление счетов в портал Azure, щелкните Управление затратами, а затем выберите анализ затрат.To understand backup storage costs, go to Cost Management + Billing in the Azure portal, select Cost Management, and then select Cost analysis. Выберите нужную подписку в качестве области, а затем выполните фильтрацию за период времени и службу, которые вас интересуют.Select the desired subscription as the Scope, and then filter for the time period and service that you're interested in.

Добавьте фильтр для имени службы, а затем выберите база данных SQL в раскрывающемся списке.Add a filter for Service name, and then select sql database in the drop-down list. Используйте фильтр Подкатегория подкатегории , чтобы выбрать счетчик выставления счетов для службы.Use the meter subcategory filter to choose the billing counter for your service. Для отдельной базы данных или пула эластичных баз данных выберите один или эластичный пул pitr хранилище резервных копий.For a single database or an elastic database pool, select single/elastic pool pitr backup storage. Для управляемого экземпляра выберите pitr хранилище резервных копий.For a managed instance, select mi pitr backup storage. Подкатегории хранилища и вычислений могут быть также интересны, но не связаны с затратами на хранение резервных копий.The Storage and compute subcategories might interest you as well, but they're not associated with backup storage costs.

Анализ затрат на хранилище резервных копий

Примечание

Индикаторы отображаются только для счетчиков, которые используются в данный момент.Meters are only visible for counters that are currently in use. Если счетчик недоступен, скорее всего, эта категория не используется в данный момент.If a counter is not available, it is likely that the category is not currently being used. Например, счетчики управляемого экземпляра не будут присутствовать для клиентов, которые не развернули управляемый экземпляр.For example, managed instance counters will not be present for customers who do not have a managed instance deployed. Точно так же счетчики хранилища не будут видны для ресурсов, которые не потребляют хранилище.Likewise, storage counters will not be visible for resources that are not consuming storage.

Зашифрованные резервные копииEncrypted backups

Если база данных зашифрована с помощью TDE, резервные копии автоматически шифруются при хранении, включая резервные копии LTR.If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. По умолчанию все новые базы данных в SQL Azure настроены с включенным TDE.All new databases in Azure SQL are configured with TDE enabled by default. Дополнительные сведения о TDE см. в статье прозрачное шифрование данных с базой данных sql & sql управляемый экземпляр.For more information on TDE, see Transparent Data Encryption with SQL Database & SQL Managed Instance.

Целостность резервной копииBackup integrity

На постоянной основе группа инженеров SQL Azure автоматически проверяет восстановление резервных копий баз данных.On an ongoing basis, the Azure SQL engineering team automatically tests the restore of automated database backups. (В настоящее время это тестирование недоступно в Управляемый экземпляр SQL.) При восстановлении до точки во времени базы данных также получают проверки целостности DBCC CHECKDB.(This testing is not currently available in SQL Managed Instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

При обнаружении ошибок в процессе проверки целостности команда разработки получает оповещения.Any issues found during the integrity check will result in an alert to the engineering team. Дополнительные сведения см. в разделе целостность данных в базе данных SQL.For more information, see Data Integrity in SQL Database.

Все резервные копии базы данных создаются с параметром CHECKSUM для обеспечения дополнительной целостности резервных копий.All database backups are taken with the CHECKSUM option to provide additional backup integrity.

Соответствие нормативным требованиямCompliance

При переносе базы данных с уровня служб на основе DTU на уровень служб на основе виртуальное ядро сохраняется сохранение PITR, чтобы гарантировать, что политика восстановления данных вашего приложения не скомпрометирована.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. Если срок хранения по умолчанию не соответствует требованиям, можно изменить срок хранения PITR.If the default retention doesn't meet your compliance requirements, you can change the PITR retention period. Дополнительные сведения см. в разделе изменение срока хранения резервной копии PITR.For more information, see Change the PITR backup retention period.

Примечание

В этой статье приведены пошаговые инструкции по удалению персональных данных с устройства или из службы. Эти сведения можно использовать для соблюдения обязательств согласно Общему регламенту по защите данных (GDPR).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. Если вы ищете общие сведения о GDPR, см. раздел о GDPR на Service Trust Portal.If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

Изменение срока хранения резервной копии PITRChange the PITR backup retention period

Вы можете изменить срок хранения резервной копии PITR по умолчанию с помощью портал Azure, PowerShell или REST API.You can change the default PITR backup retention period by using the Azure portal, PowerShell, or the REST API. В следующих примерах показано, как изменить срок хранения PITR на 28 дней.The following examples illustrate how to change the PITR retention to 28 days.

Предупреждение

Уменьшение текущего срока хранения приведет к потере возможности восстановления до точек во времени, предшествующих новому сроку хранения.If you reduce the current retention period, you lose the ability to restore to points in time older than the new retention period. Резервные копии, которые больше не нужны для предоставления PITR в течение нового срока хранения, удаляются.Backups that are no longer needed to provide PITR within the new retention period are deleted. Если вы увеличиваете текущий срок хранения, вы не сразу получаете возможность восстановления на более старые моменты времени в течение нового срока хранения.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. Эта возможность получается по мере того, как система начинает хранить резервные копии дольше.You gain that ability over time, as the system starts to retain backups for longer.

Примечание

Эти API влияют только на срок хранения PITR.These APIs will affect only the PITR retention period. Если вы настроили LTR для базы данных, это не повлияет.If you configured LTR for your database, it won't be affected. Сведения о том, как изменить сроки хранения слева направо, см. в разделе долгосрочное хранение.For information about how to change LTR retention periods, see Long-term retention.

Измените срок хранения резервной копии PITR с помощью портал AzureChange the PITR backup retention period by using the Azure portal

Чтобы изменить срок хранения резервной копии PITR для активных баз данных с помощью портал Azure, перейдите на сервер или управляемый экземпляр с базами данных, срок хранения которых требуется изменить.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.

Изменения в PITR хранения резервных копий для базы данных SQL выполняются на странице сервера на портале.Changes to PITR backup retention for SQL Database are done on the server page in the portal. Чтобы изменить срок хранения PITR для баз данных на сервере, перейдите в колонку Обзор сервера.To change PITR retention for databases on a server, go to the server overview blade. Выберите Управление резервными копиями в левой области, выберите базы данных в области изменений, а затем щелкните настроить хранение в верхней части экрана: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, уровень сервера

Изменение срока хранения резервной копии PITR с помощью PowerShellChange the PITR backup retention period by using PowerShell

Примечание

Эта статья была изменена и теперь содержит сведения о новом модуле Az для Azure PowerShell.This article has been updated to use the new Azure PowerShell Az module. Вы по-прежнему можете использовать модуль AzureRM, исправления ошибок для которого будут продолжать выпускаться как минимум до декабря 2020 г.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Дополнительные сведения о совместимости модуля Az с AzureRM см. в статье Introducing the new Azure PowerShell Az module (Знакомство с новым модулем Az для Azure PowerShell).To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Инструкции по установке модуля Az см. в статье об установке Azure PowerShell.For Az module installation instructions, see Install Azure PowerShell.

Важно!

Модуль PowerShell AzureRM по-прежнему поддерживается базой данных SQL и Управляемый экземпляр SQL, но вся будущая разработка предназначена для модуля 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. Дополнительные сведения см. в разделе AzureRM. SQL.For more information, see AzureRM.Sql. Аргументы для команд в модуле AZ существенно идентичны параметрам в модулях AzureRm.The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

Чтобы изменить срок хранения резервной копии PITR для активных баз данных SQL Azure, используйте следующий пример PowerShell.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

Измените срок хранения резервной копии PITR с помощью REST APIChange the PITR backup retention period by using the REST API

Пример запросаSample 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

Тело запросаRequest body

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

Пример ответаSample response

Код состояния: 200.Status 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
  }
}

Дополнительные сведения о политиках краткосрочного хранения резервных копий см. здесь.For more information, see Backup Retention REST API.

Дальнейшие действияNext steps