При обслуживании боевых информационных баз 1С на платформе Microsoft SQL Server перед администраторами регулярно встает задача минимизации потерь данных при сбоях (RPO — Recovery Point Objective) и сокращения времени на восстановление работоспособности (RTO — Recovery Time Objective). Для базы размером около 40 ГБ создание полного бэкапа каждый час технически возможно, однако такой подход часто является избыточным и неоптимальным с точки зрения дисковой нагрузки. Проанализируем рабочие стратегии организации резервного копирования, рассмотрим альтернативные сценарии и выясним технические нюансы взаимодействия платформы 1С и СУБД.
Разберем стандартную и наиболее сбалансированную схему обслуживания, которая обеспечивает минимальные потери данных без постоянной перегрузки дисков полными копиями базы данных:
Рассмотрим пример T-SQL скрипта для выгрузки бэкапа журнала транзакций со сжатием и контролем целостности:
BACKUP LOG [ib_production]
TO DISK = N'D:\Backups\ib_production_Log.trn'
WITH NOFORMAT, NOINIT,
NAME = N'ib_production-Log Backup',
COMPRESSION,
CHECKSUM;
Если специфика бизнеса требует восстанавливать систему с минимальным количеством цепочек логов, можно настроить дифференциальное копирование каждый час. Разберем, как устроен этот механизм: раз в сутки снимается полный бэкап, а каждый последующий час — дифференциальный. При сбое для восстановления потребуется поднять только ночной полный бэкап и последний дифференциальный снимок перед аварией.
Посмотрим на важный нюанс: на размер дифференциального бэкапа критически влияют регламентные процедуры СУБД. Если в течение рабочего дня запускается реиндексация таблиц 1С, перестроение индексов модифицирует страницы данных на физическом уровне. В результате размер последующего дифференциального бэкапа вырастет практически до объема полной базы (все 40 ГБ), что перегрузит дисковую подсистему. Поэтому дефрагментацию и реиндексацию следует выносить в ночные технологические окна строго перед созданием полного бэкапа.
Проанализируем распространенное заблуждение о блокировке пользователей. Штатная команда СУБД BACKUP DATABASE считывает страницы параллельно и не накладывает блокировок на чтение или запись таблиц 1С. Единственное ограничение — производительность дисков и процессора.
Однако кардинально иначе обстоит дело при использовании теневых копий (VSS, снапшоты виртуальных машин или СХД). В момент фиксации снапшота происходит кратковременная «заморозка» ввода-вывода (I/O Freeze). Если эта задержка превысит 10–20 секунд, кластер серверов 1С может разорвать соединение с базой данных, сочтя рабочий процесс аварийно завершенным, что приведет к массовому отключению пользователей с ошибкой «Сеанс отсутствует или удален».
Для оптимизации скорости создания копий обязательно используем опцию COMPRESSION. База 1С размером 40 ГБ сжимается в среднем до 6–9 ГБ, что позволяет снять копию за пару минут на современных NVMe/SSD-накопителях без заметного проседания отзывчивости интерфейса пользователей.
При частых бэкапах журнала транзакций необходимо учитывать поведение регламентов 1С. Лог транзакций не усекается до тех пор, пока не завершится самая старая активная транзакция. Тяжелые операции в 1С, такие как групповое перепроведение документов, закрытие месяца или реструктуризация таблиц при обновлении конфигурации, могут удерживать транзакцию открытой несколько часов. В такой ситуации регулярный бэкап лога не остановит рост LDF-файла, и дисковое пространство может быстро исчерпаться.
Рассмотрим предложение создания реплики (master-slave) с помощью доставки журналов (Log Shipping) или механизма групп доступности Always On. Здесь администраторам важно учитывать архитектурные особенности платформы 1С:
STANDBY для выполнения аналитических SQL-запросов, процесс применения очередного лога требует монопольного доступа. Любой активный запрос к базе заблокирует восстановление либо будет принудительно разорван процессом доставки журнала.Выясним перечень обязательных настроек при организации резервного копирования баз 1С:
COPY_ONLY: Если требуется сделать внеплановую копию базы перед тестированием или обновлением конфигурации, используем параметр WITH COPY_ONLY. Это сохранит целостность LSN (Log Sequence Number) и не нарушит автоматическую цепочку дифференциальных бэкапов.CHECKSUM. Это предотвращает создание резервных копий с уже поврежденных дисковых страниц и подтверждает корректность данных на лету.Perform Volume Maintenance Tasks у учетной записи службы SQL Server. Это ускоряет операцию разворачивания файлов MDF при восстановлении из бэкапа, исключая этап зануления дискового пространства.Посмотрим на пример правильного создания ручной резервной копии:
BACKUP DATABASE [ib_production]
TO DISK = N'D:\Backups\ib_production_Manual.bak'
WITH COPY_ONLY,
COMPRESSION,
CHECKSUM,
STATS = 10;