Резервные копии 1С/BAS на MS SQL: полная, дифференциальная, журнал

Для чего и кому

Резервные копии базы 1С/BAS на MS SQL состоят из трёх частей: полной копии, дифференциальной и копии журнала транзакций. Вместе они определяют, сколько работы придётся восстанавливать вручную после сбоя. Как SQL Server организует такие копии, описано в Microsoft Learn: Back up and restore of SQL Server databases.

Инструкция касается компаний, где 1С/BAS работает в клиент-серверном режиме на MS SQL Server: на собственном сервере, в виртуальной машине или на сервере для 1С/BAS на MS SQL в дата-центре. Если ваша база файловая и SQL Server не использует, модели и сроки ниже к ней не относятся. Руководителю достаточно прочитать этот раздел и раздел о проверке, администратору пригодятся все.

Для бизнеса в Украине тема вполне практическая. Источник называет типичные причины потери данных: сбой носителя, ошибка пользователя (например, случайно удалённая таблица), выход из строя оборудования, стихийные бедствия. К этому в наших условиях добавляются внезапные отключения электричества, после которых диск или база не всегда поднимаются. О защите серверной от таких ситуаций мы писали в статье об ИБП и генераторе для серверной. Без пригодной копии восстановление означает повторный ввод документов за потерянный период.

Три типа копий простыми словами

Полная копия – это состояние всей базы на момент завершения копирования, как фотография. Дифференциальная содержит только то, что изменилось после последней полной, и без своей полной копии не восстанавливается. Копия журнала хранит записи об операциях, которых ещё нет в предыдущих копиях журнала, и позволяет вернуть базу на нужный момент, скажем, за пять минут до ошибочного проведения.

Копии журнала доступны не всегда: всё зависит от модели восстановления (recovery model) базы. В простой модели (simple) их нет, и изменения после последней копии при сбое теряются. В полной (full) копии журнала обязательны, зато потеря данных обычно минимальна. По умолчанию редакции Standard и Enterprise используют полную модель, а Express простую, поэтому начинать лучше именно с проверки модели.

Приоритет

Сегодня: если свежей копии базы за последние сутки нет или она лежит только на том же сервере, что и база. На этой неделе: проверить модель восстановления, составить расписание и сделать первое тестовое восстановление. При плановом обновлении сервера или раз в квартал: пересмотреть расписание, место хранения и время восстановления.

Что понадобится

Нужен доступ администратора к SQL Server, где лежат базы 1С/BAS, и список этих баз. Базу «Бухгалтерия» часто дополняют отдельные базы зарплаты, торговли или тестовая копия, поэтому список лучше сверить с человеком, который ведёт 1С. Отдельно нужно место для копий: диск, сетевая папка или хранилище, не связанное с диском базы.

Понадобятся и два решения от руководства. Первое: сколько работы компания готова потерять (для бухгалтерии это часы или минуты?). Второе: сколько времени база может быть недоступна. В терминах источника это соответственно точка (RPO) и время восстановления (RTO). Без этих цифр расписание копий составляют наугад.

Для проверки нужен отдельный сервер или виртуальная машина, куда можно восстановить копию, не затрагивая рабочую базу. Восстанавливать «поверх» боевой базы ради теста нельзя.

Если нет своего администратора

Настроить расписание копий и проверить восстановление может внешний специалист, но решать, какие потери допустимы, должен владелец бизнеса. Если в вашей компании нет человека, который следит за резервным копированием базы 1С/BAS, это обслуживание можно передать на IT-аутсорсинг команде TakeIT.

Шаги

Порядок такой, что каждый следующий шаг опирается на предыдущий. Расписание в шаге 2 приведено как пример для отталкивания, а не как норма: ваши цифры зависят от ответов руководства.

1. Определите модель восстановления каждой базы 1С/BAS. Как посмотреть и изменить модель восстановления (recovery model), описано в документации Microsoft SQL Server, в задаче «View or change the recovery model»; среди связанных материалов упомянуто и системное представление sys.databases. Проверка: у вас есть таблица «база – модель», и для баз, где нужно восстановление на момент времени, стоит полная модель. Модель можно изменить в любое время, поэтому после смены проверьте, что расписание копий соответствует новой модели.
2. Составьте расписание исходя из допустимой потери данных. Для примера: полная копия раз в сутки ночью, дифференциальная несколько раз в течение рабочего дня, копия журнала каждые 15–30 минут. Чем чаще журнал, тем меньше работы придётся повторять. Проверка: расписание записано, и руководитель подтвердил, что такая максимальная потеря его устраивает.
3. Создайте автоматические задания. Для этого обычно используют SQL Server Agent: отдельное задание для полных, дифференциальных копий и журнала, с именами файлов, по которым видно базу, тип и время. Проверка: за сутки в истории заданий есть успешные запуски каждого типа, а файлы появились в целевой папке.
4. Вынесите копии за пределы сервера. Копии на том же диске, что и база, не спасают при сбое диска или потере сервера. Нужна вторая копия в другом месте: на отдельном хранилище, в другом помещении или в удалённом хранилище. Проверка: файл вчерашней копии открывается из второго места, а доступ к нему есть только у учётных записей, которым он нужен.
5. Сделайте тестовое восстановление на отдельном сервере. Восстановите набор копий, который вы реально создаёте по расписанию (полную, а также дифференциальную и копии журнала, если они есть), по процедуре из документации Microsoft для вашей модели восстановления; для полной модели это раздел «Complete database restores (full recovery model)». Проверка: база поднялась, 1С/BAS подключается к ней, а бухгалтер находит в ней документы за последний день и подтверждает, что данные похожи на правду.
6. Настройте оповещения и контроль. Администратор должен получать письмо или сообщение, когда задание копирования завершилось ошибкой, а также следить за размером журнала и свободным местом в хранилище. Проверка: временно сломайте путь в тестовом задании и убедитесь, что оповещение пришло.

Как проверить результат

Главный показатель один: база восстановилась из копий за известное время. Засекайте длительность тестового восстановления и сравнивайте с допустимым для компании временем простоя. Если восстановление занимает час, а бизнес ждёт не больше получаса, нужны другие копии, более быстрое хранилище или другая схема. Для этого часто достаточно настроить резервное копирование и восстановление под реальные требования.

Вторая проверка касается восстановления на момент времени. Выберите момент в середине рабочего дня и восстановите базу на него, используя копии журнала. В полной модели это возможно, если цепочка копий без разрывов. В простой модели вернуться можно только к концу одной из копий.

Третье: посмотрите на размер журнала транзакций. В полной модели он растёт, пока не сделана копия журнала, поэтому после настройки расписания его размер должен стабилизироваться. Фиксируйте результат теста в коротком отчёте: дата, какие копии использованы, сколько заняло, кто проверял. Через квартал такая запись покажет, что изменилось.

Типичные ошибки

Журнал растёт без конца

База работает в полной модели, а копий журнала никто не делает. Журнал занимает весь диск, и база останавливается. В источнике этот случай разобран как ошибка SQL Server 9002 (заполненный журнал транзакций). Лечение простое: настроить регулярные копии журнала или осознанно перейти на простую модель, если восстановление на момент времени вам не нужно.

Копии лежат рядом с базой

Если копии хранятся на сервере, сбой сервера забирает и базу, и копии. То же происходит, когда шифровальщик получает доступ к сетевой папке с копиями. О подготовке к такой атаке есть отдельная статья: программа-вымогатель: как подготовиться и что делать.

Восстановление ни разу не пробовали

Файл копии может существовать и не восстанавливаться: он повреждён, цепочка неполная, пароль неизвестен. Источник прямо советует проверять стратегию, восстанавливая набор копий. Тестируйте не реже раза в квартал и после любых изменений на сервере или в расписании.

Ожидания как в полной модели, а модель простая

Руководитель ждёт, что потеряется не более получаса работы, а база на Express в простой модели с одной копией на ночь. Тогда реальная потеря может достигать почти суток. Сверяйте модель и расписание с тем, что вы пообещали бизнесу.

Связанные базы копируются отдельно

Если несколько баз в полной модели должны быть логически согласованы между собой, источник советует предусмотреть специальные процедуры восстановления. Уточните у ответственного за 1С, есть ли такие связи между вашими базами, и восстанавливайте их на один момент времени.

Вывод

Начните с одного действия на эту неделю: выясните, какая модель восстановления задана для базы 1С/BAS. Остальное (расписание, второе место хранения, тестовое восстановление) логично вытекает из этого ответа и из решения руководства о допустимой потере данных. Копия, которую ни разу не восстанавливали, остаётся предположением, поэтому запишите дату первого теста в календарь.