Резервное копирование баз 1С: что реально восстанавливается, а что только выглядит бэкапом

У каждого второго клиента, приходящего к нам на поддержку, бэкап «настроен». У каждого четвёртого он при этом не восстанавливается. Разница между этими состояниями обнаруживается ровно один раз — в тот день, когда база нужна обратно. Разберём, какие уровни копирования бывают, что из них чего стоит и как за час проверить, что у вас на самом деле.

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

Уровень СУБД. Полный бэкап базы плюс бэкапы журнала транзакций. Это основной инструмент. Восстанавливает базу целиком на любой момент времени, если журнал пишется в режиме FULL. Быстро, надёжно, не требует останова.

Уровень платформы. Выгрузка в файл .dt средствами конфигуратора. Медленно, требует монопольного доступа, на базе за 100 ГБ может идти часами. Зато файл переносится между разными СУБД и разными версиями платформы. Это инструмент переезда, а не ежедневного бэкапа.

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

Каждый уровень закрывает свой класс аварий. Удалили документы задним числом — нужен уровень СУБД с точкой восстановления. Умер хост виртуализации — нужен уровень инфраструктуры. Переезжаете с MS SQL на PostgreSQL — нужен .dt.

Схема, которую мы считаем минимально достаточной для офиса до 50 мест: полный бэкап СУБД ежедневно, журнал транзакций каждые 15–30 минут, бэкап ВМ раз в неделю, выгрузка .dt раз в месяц в архив. Плюс копия за пределами площадки.

Выгрузка в .dt популярна, потому что понятна: один файл, положил в папку, спокоен. Проблем с ней четыре.

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

Вторая: время. База на 80 ГБ выгружается в .dt сорок минут — час, загружается обратно два-три часа. Бэкап СУБД той же базы делается за 6–8 минут, восстанавливается за 12–20.

Третья: .dt не умеет в точку восстановления. Он даёт состояние на момент выгрузки, и всё. Ошибку, найденную в среду, вы откатите на состояние ночи вторника, потеряв рабочий день целиком.

Четвёртая, самая коварная: выгрузка может пройти успешно, а загрузка — упасть. Формат .dt не содержит контрольных сумм, которые проверялись бы при выгрузке. Битую выгрузку вы обнаружите только при попытке загрузить.

Где .dt действительно нужен: переезд между СУБД, передача базы разработчику, архивная копия перед крупным обновлением, долгосрочное хранение состояния на конец года. Для этих задач он идеален. Для ежедневного бэкапа — нет.

Ключевая настройка на стороне MS SQL, которую половина инсталляций оставляет неправильной.

Модель SIMPLE означает, что журнал транзакций не сохраняется. Восстановиться можно только на момент полного бэкапа. Потеряли базу в 17:00, последний бэкап был в 01:00 — потеряли весь рабочий день.

Модель FULL плюс регулярный бэкап журнала даёт восстановление на любую минуту. Потеряли базу в 17:00, журнал бэкапится каждые 15 минут — потеряли максимум 15 минут работы.

ALTER DATABASE [buh_prod] SET RECOVERY FULL;
-- и обязательно расписание бэкапа журнала, иначе лог вырастет до размера диска
BACKUP LOG [buh_prod] TO DISK = 'E:\backup\buh_prod_log.trn' WITH COMPRESSION;

Вторая строка — не опциональна. Переключить базу в FULL и не настроить бэкап журнала — прямой путь к переполнению диска: журнал не усекается, пока его не забэкапят, и растёт бесконечно. Мы регулярно приходим к клиентам, где база 40 ГБ, а её лог — 300 ГБ.

Проверить текущее состояние:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases WHERE name NOT IN ('master','model','msdb','tempdb');

Колонка log_reuse_wait_desc со значением LOG_BACKUP — прямое указание: журнал ждёт бэкапа и до тех пор не освободится.

Это не абстракция из учебника, а два вопроса, ответы на которые определяют всю схему.

RPO — сколько данных допустимо потерять. Час работы бухгалтерии? Пятнадцать минут? День? Ответ даёт не администратор, а руководитель. От него зависит частота бэкапа журнала.

RTO — сколько времени допустимо лежать. Час? Четыре часа? Сутки? От этого зависит, нужен ли горячий резерв, или достаточно восстановления из файла.

Разговор с клиентом мы строим просто: «Сколько стоит для вас день простоя учёта?» Цифры обычно называют легко. Дальше становится понятно, что имеет смысл, а что избыточно.

Обратите внимание: жёсткий RTO стоит денег, жёсткий RPO — почти нет. Уменьшить окно потери данных с часа до пятнадцати минут — это поменять расписание задания. Уменьшить время простоя с четырёх часов до тридцати минут — это второй сервер и репликация.

Классика: три копии, на двух разных носителях, одна вне площадки. Спорить с формулой смысла нет, но её применение в малом офисе имеет особенности.

«Три копии» часто вырождаются в три файла на одном RAID-массиве. Формально три, фактически одна точка отказа. Мы это видим постоянно: бэкапы лежат на диске E: того же сервера, где база на диске D:. Умер контроллер — умерло всё.

«Два носителя» в реальности означает: локальный диск плюс NAS, либо локальный диск плюс внешний USB. Оба варианта рабочие. Важно, чтобы второй носитель не был примонтирован постоянно с правом записи от той же учётки — иначе шифровальщик доберётся и до него. Мы предпочитаем pull-модель: NAS сам забирает бэкапы по расписанию, сервер к нему не имеет доступа на запись.

«Одна вне площадки» — самый пропускаемый пункт и самый важный. Пожар, залив, кража, шифровальщик с правами домена — всё это выносит площадку целиком. Внешняя копия может быть облачным хранилищем, вторым офисом или просто диском, который раз в неделю увозят.

Отдельно про шифровальщиков. Бэкап, доступный на запись из-под доменной учётной записи с сервера, — это не бэкап, а вторая жертва. Иммутабельное хранилище или хотя бы отдельные учётные данные, не совпадающие с доменными, снимают этот класс аварий полностью.

Формулировка простая: бэкап, который ни разу не разворачивали, бэкапом не является. Это утверждение, а не фигура речи.

Что мы делаем ежемесячно у клиентов на поддержке:

1. Берём случайный бэкап за последние 30 дней, не самый свежий.
2. Восстанавливаем на тестовый сервер под именем вида buh_restoretest.
3. Запускаем базу, отключая работу с внешними ресурсами.
4. Проверяем: заходит ли пользователь, открывается ли последний документ, формируется ли ОСВ.
5. Засекаем время всей процедуры — это ваш реальный RTO.
6. Записываем результат в журнал с датой.

Пятый пункт даёт неприятные открытия. У клиента с базой 120 ГБ на плане значился RTO четыре часа; фактическая проверка показала семь с половиной, потому что бэкап лежал на NAS с гигабитным каналом и одно только копирование заняло два часа. Исправили переносом свежих копий на локальный SSD, оставив на NAS архив.

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

Восстановление базы — это половина возврата к работе. Вторая половина обычно всплывает уже в процессе.

• Каталог кластера srvinfo — в нём список информационных баз и данные сеансов. Без него базу придётся регистрировать в кластере заново.
• Файлы лицензий из C:\ProgramData\1C\licenses.
• Каталог публикации с default.vrd, если база публикуется.
• Внешние обработки и печатные формы, если они лежат в файловой системе, а не в базе.
• Правила обмена и настройки интеграций.
• Дистрибутив платформы той версии, на которой работает база. Скачать старую версию с портала можно, но не в момент аварии.
• Сертификаты ЭЦП и настройки криптопровайдера.

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

Мы держим для каждого клиента короткий документ «Что нужно для восстановления учёта с нуля» на одну страницу: список файлов, где лежат, кто владеет паролями, в каком порядке разворачивать. Когда авария случается, этот лист экономит первые два часа — те самые, в которые обычно ищут, у кого пароль от NAS.

Достаточно ли ежедневной выгрузки в dt?

Для ежедневного бэкапа — нет. Она требует монопольного доступа, идёт часами на крупных базах и не даёт восстановления на точку времени: потеряете весь день до момента выгрузки. Основной бэкап делается средствами СУБД, а dt остаётся для переездов и архива.

Зачем бэкапить журнал транзакций, если есть полный бэкап?

Полный бэкап даёт состояние на момент своего создания. Бэкап журнала позволяет докатить базу до любой минуты после него — это разница между потерей рабочего дня и потерей пятнадцати минут. Плюс без бэкапа журнала он не усекается и растёт до размера диска.

Как часто проверять бэкапы восстановлением?

Раз в месяц — выборочное восстановление на тестовый сервер, раз в квартал — полный прогон руками с замером времени. Замер важен: фактический RTO почти всегда больше планового, и узнавать об этом лучше не в день аварии.

Спасёт ли бэкап от шифровальщика?

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