Резервная копия журнала транзакций

Резервная копия журнала транзакций — это копия файла журнала транзакций базы данных, создаваемая для обеспечения возможности восстановления базы данных на определённый момент времени (point-in-time recovery) или для освобождения места в файле журнала (усечения журнала). Является одним из трёх основных типов резервного копирования в системах управления базами данных (СУБД), наряду с полной и разностной (дифференциальной) резервными копиями. Используется преимущественно в моделях восстановления, предполагающих полное протоколирование всех изменений (full recovery model).

Назначение и принцип действия

Журнал транзакций (transaction log) — это последовательный файл, в который СУБД записывает все изменения, производимые над данными, а также информацию о начале и завершении каждой транзакции. В случае сбоя (отказ оборудования, ошибка программного обеспечения, потеря данных) для восстановления базы данных до работоспособного состояния требуется последовательность действий: сначала восстанавливается последняя полная резервная копия, затем — последняя разностная копия (если она есть), и после этого — все резервные копии журнала транзакций, созданные после последней разностной или полной копии.

Резервная копия журнала транзакций содержит все записи о транзакциях, произошедших с момента создания предыдущей резервной копии журнала (или с момента создания полной копии, если это первая копия журнала). При восстановлении СУБД «проигрывает» эти записи заново, применяя изменения к восстанавливаемой базе данных. Это позволяет восстановить базу данных не только до момента последней полной копии, но и до любого конкретного момента времени (например, до 14:30:00), если в журнале зафиксированы все транзакции до этого момента.

Отличия от других типов резервного копирования

• Полная резервная копия (full backup) — копия всей базы данных целиком, включая все данные, индексы, схемы и метаданные. Восстановление из полной копии не требует дополнительных копий, но занимает много времени и дискового пространства.
• Разностная (дифференциальная) резервная копия (differential backup) — копия всех изменений, произошедших с момента последней полной копии. Восстановление из разностной копии требует наличия полной копии. Разностная копия не содержит всех транзакций, а только итоговые изменения на уровне страниц данных.
• Резервная копия журнала транзакций (transaction log backup) — копия только записей журнала, а не самих данных. Восстановление из копии журнала требует наличия полной и, возможно, разностной копий. Позволяет восстановить базу данных на любой момент времени в пределах цепочки журналов.

Модели восстановления и частота создания

Возможность и необходимость создания резервных копий журнала транзакций зависит от выбранной модели восстановления в СУБД. В Microsoft SQL Server, например, существуют три модели:

• Простая модель (simple recovery model) — журнал транзакций автоматически усекается после завершения каждой транзакции. Резервные копии журнала не создаются, восстановление возможно только до момента последней полной или разностной копии. Потеря данных между копиями неизбежна.
• Полная модель (full recovery model) — все транзакции полностью протоколируются, журнал не усекается автоматически. Для освобождения места в журнале необходимо создавать резервные копии журнала. Только при этой модели возможна точка восстановления на любой момент времени.
• Модель с неполным протоколированием (bulk-logged recovery model) — операции массового импорта данных (bulk operations) протоколируются минимально, что ускоряет их выполнение, но снижает возможности восстановления на момент времени. Резервные копии журнала создаются, но при восстановлении после массовых операций возможна потеря данных.

Частота создания резервных копий журнала транзакций определяется требованиями к допустимой потере данных (RPO — Recovery Point Objective). В системах с высокой транзакционной нагрузкой (банковские системы, биржевые платформы) копии могут создаваться каждые 5–15 минут. В менее критичных системах — раз в час или реже. Слишком редкое создание копий приводит к неограниченному росту файла журнала, что может вызвать переполнение диска и остановку базы данных.

Процесс создания и восстановления

Создание резервной копии журнала

В большинстве СУБД (Microsoft SQL Server, Oracle, PostgreSQL с расширением WAL) создание резервной копии журнала выполняется командой BACKUP LOG (в SQL Server) или аналогичной. При этом происходит:

1. Фиксация текущей позиции в журнале (LSN — Log Sequence Number).
2. Копирование всех записей журнала от предыдущей точки фиксации до текущей.
3. После успешного завершения копирования — усечение (truncation) журнала: освобождение пространства, занятого скопированными записями, для повторного использования.

Восстановление из резервных копий журнала

Последовательность восстановления базы данных с использованием журнала транзакций:

1. Восстановление последней полной резервной копии с опцией NORECOVERY (база данных остаётся в состоянии восстановления, не принимает пользовательские подключения).
2. Восстановление последней разностной копии (если есть) с опцией NORECOVERY.
3. Последовательное восстановление всех резервных копий журнала, начиная с самой старой после полной/разностной копии и заканчивая самой новой. Каждая копия восстанавливается с опцией NORECOVERY, кроме последней, которая может быть восстановлена с опцией RECOVERY (база данных становится доступной для пользователей).
4. При необходимости восстановления на конкретный момент времени (point-in-time) — указание времени остановки (STOPAT) при восстановлении последней копии журнала. Все транзакции, совершённые после указанного времени, откатываются.

Особенности в различных СУБД

• Microsoft SQL Server — наиболее развитая поддержка резервного копирования журнала транзакций. Поддерживает цепочки журналов, восстановление на момент времени, восстановление до маркера (log mark), а также восстановление с пропуском повреждённых страниц (page-level restore).
• Oracle Database — использует механизм Redo Logs и Archive Logs. Архивные журналы (archived redo logs) по сути являются резервными копиями журнала транзакций. Восстановление на момент времени выполняется с помощью команды RECOVER DATABASE UNTIL TIME.
• PostgreSQL — использует Write-Ahead Log (WAL). Для создания резервных копий WAL применяется архивация (WAL archiving). Восстановление на момент времени (PITR) выполняется с помощью файла recovery.conf (в старых версиях) или параметров конфигурации.
• MySQL — в InnoDB используется журнал транзакций (redo log), но резервные копии журнала как отдельный тип не поддерживаются. Для восстановления на момент времени применяются бинарные логи (binary log), которые по сути выполняют ту же функцию.

Преимущества и недостатки

Преимущества:

• Минимальный размер по сравнению с полными и разностными копиями (копируются только записи изменений, а не все данные).
• Высокая скорость создания (особенно при частых копиях).
• Возможность восстановления на любой момент времени в пределах цепочки журналов.
• Возможность освобождения места в файле журнала без остановки базы данных.

Недостатки:

• Зависимость от целостности цепочки журналов: потеря одной копии журнала делает невозможным восстановление на момент времени после этой копии.
• Требуется хранение большого количества файлов (при частых копиях).
• Восстановление занимает больше времени, чем из полной копии, так как требуется последовательное применение всех копий журнала.
• Необходимость регулярного мониторинга размера файла журнала.

Практические рекомендации

Для обеспечения надёжного восстановления базы данных с использованием резервных копий журнала транзакций рекомендуется:

• Выбирать полную модель восстановления для критичных систем, где допустимая потеря данных измеряется минутами.
• Создавать полные резервные копии не реже одного раза в сутки, разностные — каждые 4–6 часов, а журнальные — с интервалом, соответствующим RPO (например, каждые 15 минут).
• Хранить резервные копии на отдельном физическом носителе или в облачном хранилище.
• Регулярно тестировать процедуру восстановления, включая восстановление на момент времени.
• Использовать автоматические скрипты или средства администрирования (например, SQL Server Agent, Oracle Recovery Manager) для планирования и выполнения операций.

Источники

• Microsoft Docs. «Backup Overview (SQL Server)».
• Oracle Database Backup and Recovery User’s Guide.
• PostgreSQL Documentation. «Continuous Archiving and Point-in-Time Recovery (PITR)».
• MySQL 8.0 Reference Manual. «The Binary Log».
• Томас К. «Администрирование Microsoft SQL Server 2019». — М.: Вильямс, 2021.
• Гурвиц М. «Oracle Database 12c. Администрирование и настройка». — СПб.: Питер, 2018.