Резервные копии журналов транзакций (SQL Server)
Область применения: 
SQL Server
Эта статья относится только к базам данных SQL Server, использующим полные или массовые модели восстановления. В этой статье описывается резервное копирование журнала транзакций базы данных SQL Server.
Перед созданием любой резервной копии журнала необходимо создать как минимум одну полную резервную копию. После этого резервное копирование журнала транзакций может выполняться в любое время, кроме времени другого резервного копирования журнала.
Рекомендуется периодически производить резервное копирование журнала для снижения вероятности потери результатов работы и для усечения журнала транзакций.
Обычно администратор базы данных время от времени создает полную резервную копию базы данных (например, еженедельно) и дополнительно создает разностные резервные копии через более короткие интервалы, например ежедневно. Независимо от резервного копирования базы данных администратор с высокой периодичностью создает резервные копии журнала транзакций. При таком подходе к резервному копированию оптимальный интервал между моментами выполнения резервного копирования зависит от множества факторов: важности данных, размера базы данных и рабочей нагрузки сервера. Дополнительные сведения о реализации хорошей стратегии см. в этой статье.
Работа последовательности резервных копий журнала
Последовательность резервных копий цепочки журналов транзакций не зависит от резервных копий данных. Например, предположим, что имеется следующая последовательность событий:
| Time | Событие |
|---|---|
| 8:00 | Резервное копирование базы данных. |
| Полдень | Резервное копирование журнала транзакций. |
| 16:00 | Резервное копирование журнала транзакций. |
| 18:00 | Резервное копирование базы данных. |
| 20:00 | Резервное копирование журнала транзакций. |
Резервная копия журнала транзакций, созданная в 8:00 вечера, содержит записи журнала транзакций с 4:00 по 8:00, охватывая время создания полной резервной копии базы данных в 6:00. Последовательность резервных копий журналов транзакций выполняется непрерывно, начиная с исходной полной резервной копии базы данных, созданной в 8:00 утра, до последней резервной копии журнала транзакций, созданной в 8:00. Сведения о применении этих резервных копий журналов см. в примере в разделе "Применение резервных копий журналов транзакций" (SQL Server).
Рекомендации
Если журнал транзакций поврежден, будут потеряны все результаты работы, начиная с момента самого последнего действительного резервного копирования. Поэтому настоятельно рекомендуется помещать файлы журнала в отказоустойчивое хранилище.
Если база данных повреждена или вы будете восстанавливать базу данных, рекомендуется создать резервную копию журнала хвоста, чтобы можно было восстановить базу данных до текущей точки во времени.
Внимание
Известная проблема: для баз данных с оптимизированными для памяти таблицами, выполнение резервного копирования журналов транзакций без восстановления и последующее восстановление журнала транзакций с восстановлением может привести к неответственному процессу восстановления базы данных. Эта проблема также может повлиять на функции доставки журналов. Чтобы обойти эту проблему, экземпляр SQL Server можно перезапустить перед началом процесса восстановления.
По умолчанию каждая успешная операция резервного копирования добавляет запись в журнал ошибок SQL Server и в журнал системных событий. Если создание резервной копии журналов производится очень часто, сообщения об успешном завершении накапливаются очень быстро. Это приводит к увеличению журналов ошибок, затрудняя поиск других сообщений. В таких случаях эти записи журнала можно отключить с помощью флага трассировки 3226, если ни один из скриптов не зависит от этих записей. Дополнительные сведения см. в разделе Флаги трассировки (Transact-SQL).
Создавайте резервные копии журналов с достаточной периодичностью в соответствии с вашими бизнес-требованиями, в особенности касающимися устойчивости к потере данных, что может произойти из-за повреждения хранилища журналов.
Частота создания резервных копий журнала зависит от степени толерантности к возможности потери данных и от того, какое количество резервных копий журнала получится хранить и в потенциале восстанавливать, а также каким количеством управлять. Думайте о требуемом целевом времени восстановления (RTO) и целевой точке восстановления (RPO) при реализации стратегии восстановления и, в частности, о времени резервного копирования журналов.
Возможно, создания резервных копий журналов один раз в 15-30 минут может оказаться достаточно. Если предприятию необходимо минимизировать вероятность потери данных, следует увеличить частоту создания резервных копий журнала. Более частое создание резервных копий журнала предоставляет преимущество за счет более частого усечения журнала, результатом которого является меньший размер файлов журнала.
Внимание
Чтобы ограничить число резервных копий журналов, которые требуется восстановить, важно периодически создавать резервные копии данных. Например, можно запланировать еженедельное создание полной резервной копии базы данных и ежедневное создание разностных резервных копий.
Опять же, при реализации стратегии восстановления и, в частности, периодичности полного и разностного резервного копирования базы данных, определите необходимое целевое время и целевую точку восстановления.