Резервные копии журналов транзакций (SQL Server)Transaction Log Backups (SQL Server)

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL AzureнетХранилище данных SQL AzureнетParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

Этот раздел относится только к тем базам данных SQL ServerSQL Server, которые используют модель полного восстановления или модель восстановления с неполным протоколированием.This topic is relevant only for SQL ServerSQL Server databases that are using the full or bulk-logged recovery models. В этом разделе рассматривается создание резервной копии журнала транзакций базы данных SQL ServerSQL Server .This topic discusses backing up the transaction log of a SQL ServerSQL Server database.

Перед созданием любой резервной копии журнала необходимо создать как минимум одну полную резервную копию.Minimally, you must have created at least one full backup before you can create any log backups. После этого резервное копирование журнала транзакций может выполняться в любое время, кроме времени другого резервного копирования журнала.After that, the transaction log can be backed up at any time unless the log is already being backed up.

Рекомендуется периодически производить резервное копирование журнала для снижения вероятности потери результатов работы и для усечения журнала транзакций.We recommend you take log backups frequently, both to minimize work loss exposure and to truncate the transaction log.

Обычно администратор базы данных время от времени создает полную резервную копию базы данных (например, еженедельно) и дополнительно создает разностные резервные копии через более короткие интервалы, например ежедневно.A database administrator typically creates a full database backup occasionally, such as weekly, and, optionally, creates a series of differential database backup at a shorter interval, such as daily. Независимо от резервного копирования базы данных администратор с высокой периодичностью создает резервные копии журнала транзакций.Independent of the database backups, the database administrator backs up the transaction log at frequent intervals. При таком подходе к резервному копированию оптимальный интервал между моментами выполнения резервного копирования зависит от множества факторов: важности данных, размера базы данных и рабочей нагрузки сервера.For a given type of backup, the optimal interval depends on factors such as the importance of the data, the size of the database, and the workload of the server. Дополнительные сведения о выборе подходящей стратегией см. в разделе Рекомендации этой статьи.For more information about implementing a good strategy, see Recommendations in this topic.

Работа последовательности резервных копий журналаHow a sequence of log backups works

Последовательность резервных копий цепочки журналов транзакций не зависит от резервных копий данных.The sequence of transaction log backups log chain is independent of data backups. Например, предположим, что имеется следующая последовательность событий:For example, assume the following sequence of events.

TimeTime СобытиеEvent
8:008:00 AM Резервное копирование базы данных.Back up database.
ПолденьNoon Резервное копирование журнала транзакций.Back up transaction log.
16:004:00 PM Резервное копирование журнала транзакций.Back up transaction log.
18:006:00 PM Резервное копирование базы данных.Back up database.
20:008:00 PM Резервное копирование журнала транзакций.Back up transaction log.

Резервная копия журналов транзакций, созданная в 20:00, содержит записи журнала транзакций с 16:00 до 20:00. В этом временном диапазоне, а именно в 18:00, была создана полная резервная копия базы данных. Последовательность резервных копий журнала транзакций продолжается непрерывно с момента создания начальной полной резервной копии базы данных в 8:00 и до создания последней резервной копии журналов транзакций в 20:00.The transaction log backup created at 8:00 PM contains transaction log records from 4:00 PM through 8:00 PM, spanning the time when the full database backup was created at 6:00 PM The sequence of transaction log backups is continuous from the initial full database backup created at 8:00 AM to the last transaction log backup created at 8:00 PM. Сведения о применении этих резервных копий журналов приводятся в примере в статье Применение резервных копий журналов транзакций (SQL Server).For information about how to apply these log backups, see the example in Apply Transaction Log Backups (SQL Server).

РекомендацииRecommendations

  • Если журнал транзакций поврежден, будут потеряны все результаты работы, начиная с момента самого последнего действительного резервного копирования.If a transaction log is damaged, work that is performed since the most recent valid backup is lost. Поэтому настоятельно рекомендуется помещать файлы журнала в отказоустойчивое хранилище.Therefore we strongly recommend that you put your log files on fault-tolerant storage.

  • Если база данных повреждена или требуется восстановить базу данных, рекомендуется создать резервную копию заключительного фрагмента журнала , чтобы можно было восстановить базу данных до текущего момента.If a database is damaged or you are about to restore the database, we recommend that you create a tail-log backup to enable you to restore the database to the current point in time.

  • По умолчанию каждая успешная операция резервного копирования добавляет запись в журнал ошибок служб SQL ServerSQL Server и в журнал системных событий.By default, every successful backup operation adds an entry in the SQL ServerSQL Server error log and in the system event log. Если создание резервной копии журналов производится очень часто, это приводит к быстрому накоплению сообщений об успешном завершении. Это приводит к увеличению журналов ошибок, затрудняя поиск других сообщений.If back up the log very frequently, these success messages accumulate quickly, resulting in huge error logs that can make finding other messages difficult. Если работа существующих скриптов не зависит от этих записей, то их можно отключить с помощью флага трассировки 3226.In such cases you can suppress these log entries by using trace flag 3226 if none of your scripts depend on those entries. Дополнительные сведения см. в разделе Флаги трассировки (Transact-SQL).For more information, see Trace Flags (Transact-SQL).

  • Создавайте резервные копии журналов с достаточной периодичностью в соответствии с вашими бизнес-требованиями, в особенности касающимися устойчивости к потере данных, что может произойти из-за повреждения хранилища журналов.Take frequent enough log backups to support your business requirements, specifically your tolerance for work loss such as might be caused by a damaged log storage.

  • Частота создания резервных копий журнала зависит от степени толерантности к возможности потери данных и от того, какое количество резервных копий журнала получится хранить и в потенциале восстанавливать, а также каким количеством управлять.The appropriate frequency for taking log backups depends on your tolerance for work-loss exposure balanced by how many log backups you can store, manage, and, potentially, restore. При реализации стратегии восстановления и, в частности, периодичности резервного копирования журнала, определите необходимое целевое время и целевую точку восстановления.Think about the required RTO and RPO when implementing your recovery strategy, and specifically the log backup cadence.

  • Возможно, создания резервных копий журналов один раз в 15-30 минут может оказаться достаточно.Taking a log backup every 15 to 30 minutes might be enough. Если предприятию необходимо минимизировать вероятность потери данных, следует увеличить частоту создания резервных копий журнала.If your business requires that you minimize work-loss exposure, consider taking log backups more frequently. Более частое создание резервных копий журнала предоставляет преимущество за счет более частого усечения журнала, результатом которого является меньший размер файлов журнала.More frequent log backups have the added advantage of increasing the frequency of log truncation, resulting in smaller log files.

Важно!

Чтобы ограничить число резервных копий журналов, которые требуется восстановить, важно периодически создавать резервные копии данных.To limit the number of log backups that you need to restore, it is essential to routinely back up your data. Например, можно запланировать еженедельное создание полной резервной копии базы данных и ежедневное создание разностных резервных копий.For example, you might schedule a weekly full database backup and daily differential database backups.
Опять же, при реализации стратегии восстановления и, в частности, периодичности полного и разностного резервного копирования базы данных, определите необходимое целевое время и целевую точку восстановления.Again, think about the required RTO and RPO when implementing your recovery strategy, and specifically the full and differential database backup cadence.

Связанные задачиRelated Tasks

Создание резервной копии журнала транзакцийTo create a transaction log backup

Описание планирования заданий резервного копирования см. в разделе Use the Maintenance Plan Wizard.To schedule backup jobs, see Use the Maintenance Plan Wizard.

См. также:See Also

Журнал транзакций (SQL Server) The Transaction Log (SQL Server)
Раздел "Резервные копии журналов транзакций" в руководстве по архитектуре журнала транзакций SQL Server и управлению им Transaction Log Backups in the SQL Server Transaction Log Architecture and Management Guide
Резервное копирование и восстановление баз данных SQL Server Back Up and Restore of SQL Server Databases
Резервные копии заключительного фрагмента журнала (SQL Server) Tail-Log Backups (SQL Server)
Применение резервных копий журналов транзакций (SQL Server)Apply Transaction Log Backups (SQL Server)