Резервное копирование баз данных 1С на платформе SQL Server 2014 — это критически важная задача для любого системного администратора. В процессе настройки планов обслуживания часто возникает вопрос: какую стратегию выбрать? Разобраться в отличиях между полным, разностным бэкапом и бэкапом журнала транзакций бывает непросто, особенно когда речь идет о балансе между скоростью восстановления, точностью данных и нагрузкой на сервер. В этой статье мы подробно разберем механизмы работы каждого типа копирования, проанализируем их влияние на систему и выясним, как обеспечить максимальную сохранность данных вашей 1С.
Разберем сначала базу. Полный бэкап — это фундамент. Он содержит абсолютно все данные, необходимые для восстановления базы данных на момент завершения операции резервного копирования. Без полного бэкапа ни разностные копии, ни журналы транзакций не имеют смысла, так как им не к чему «прицепиться». Рассмотрим ситуацию: если мы сделали полный бэкап в 5:00, то это наша «точка отсчета». Любая последующая стратегия восстановления будет начинаться с развертывания именно этого файла.
Рассмотрим, что происходит, когда мы создаем разностный бэкап. Многие ошибочно полагают, что SQL Server сравнивает текущее состояние базы с предыдущим бэкапом «на лету». На самом деле механизм гораздо изящнее. Проанализируем работу специальной битовой карты — DCM (Differential Changed Map). Каждый раз, когда в базе данных 1С изменяется экстент (блок из 8 страниц по 8 КБ), SQL Server помечает соответствующий бит в карте DCM.
Когда запускается разностное копирование, серверу не нужно ничего сравнивать. Он просто считывает карту DCM и копирует только те блоки, которые были изменены с момента последнего полного бэкапа. Важно понимать: каждый последующий разностный бэкап включает в себя все изменения, накопленные с момента фулл-бэкапа, а не с момента предыдущего разностного. То есть, если мы делаем разностные бэкапы каждый час, то копия в 22:00 будет содержать все изменения с 5:00 до 22:00.
Преимущества разностного бэкапа:
Недостатки:
Теперь выясним, в чем особенность бэкапа журнала транзакций (Log). В отличие от разностного, бэкап лога копирует записи из файла .ldf, которые накопились с момента последнего бэкапа журнала. Это создает непрерывную цепочку событий.
Главная особенность здесь — Point-in-time recovery. Рассмотрим наш сценарий с восстановлением в 22:13. Имея цепочку логов, мы можем «проиграть» транзакции и остановить процесс ровно на 22:13:00. Разностный бэкап такой точности не дает.
Важные моменты работы с логами:
Проанализируем вопрос автора темы: в чем разница при восстановлении на 22:13 при двух разных схемах?
Вариант 1: Полный (5:00) + все часовые разностные.
В этом случае мы восстанавливаем фулл (5:00) и последний разностный бэкап (22:00). Итог: база восстановлена на 22:00. Данные 1С, внесенные пользователями с 22:00 до 22:13, безвозвратно потеряны.
Вариант 2: Полный (5:00) + все часовые логи.
Мы восстанавливаем фулл (5:00), а затем последовательно накатываем все файлы логов (6:00, 7:00 ... 22:00) и, если есть возможность, «хвост журнала». Итог: мы можем восстановить базу ровно на 22:13. Ни одна транзакция не потеряна.
Выясним, как настройки SQL Server влияют на возможности резервного копирования. Существует три модели:
CREATE INDEX) не записываются в лог детально. Это экономит место, но если такая операция попала в период бэкапа лога, вы теряете возможность восстановления «Point-in-time» внутри этого интервала — только на момент окончания бэкапа.При настройке планов обслуживания для 1С рекомендуем обратить внимание на следующие технические детали:
1. Tail-Log Backup (Бэкап хвоста журнала).
Если база «упала», но файл лога (.ldf) жив, первым делом выполните бэкап хвоста журнала. Это позволит спасти самые последние данные, которые еще не успели уйти в плановый бэкап.
2. Сжатие (Backup Compression).
SQL Server 2014 Standard и выше поддерживает сжатие. Обязательно используйте его. Это не только экономит место, но и ускоряет процесс, так как запись на диск (самое медленное звено) сокращается в несколько раз.
3. Проверка контрольных сумм (CHECKSUM).
При создании бэкапа всегда используйте флаг CHECKSUM. Рассмотрим ситуацию: если на диске есть битая страница, без этой проверки SQL Server создаст бэкап и «успешно» отчитается. Однако при восстановлении вы получите ошибку. С CHECKSUM сервер обнаружит проблему еще на этапе копирования.
4. Copy-Only Backups.
Если вам нужно сделать разовый бэкап (например, для разработки), используйте режим COPY_ONLY. Посмотрим на причину: обычный полный бэкап «сбивает» цепочку разностных бэкапов, и все последующие разностные копии будут ориентироваться на этот ваш временный файл, что может разрушить план автоматического восстановления.
Подведем итоги нашего исследования. Для высоконагруженной базы 1С оптимальной стратегией будет:
Такая комбинированная схема позволяет совместить точность восстановления до секунды и высокую скорость развертывания базы при критических сбоях.