Резервное копирование 1С: как проверить восстановление базы

Резервная копия 1С есть. Задание выполняется каждую ночь. В журнале написано Success. Файлы .bak аккуратно складываются на сервер.

Кажется, что данные защищены.

Для клиент-серверной 1С, где информационная база размещена на Microsoft SQL Server, резервирование самой базы строится на штатных механизмах SQL Server. При этом рабочая стратегия должна учитывать не только создание backup, но и возможность его реального восстановления в нужный момент.

Почему просто иметь backup недостаточно

Типичная схема в небольшой компании выглядит так:

• 1С работает на виртуальном сервере;
• база размещена на Microsoft SQL Server;
• ночью создаётся .bak;
• копия хранится на том же сервере или на сетевом диске;
• администратор периодически проверяет, что файл появился.

Наличие файла подтверждает только то, что файл существует. Оно не доказывает, что вся цепочка восстановления доступна, что на резервной площадке хватит места, что необходимые доступы известны ответственным сотрудникам и что восстановленная информационная база действительно запустится в 1С.

CISA рекомендует хранить критичные резервные копии изолированно и регулярно проверять их доступность и целостность в сценариях аварийного восстановления.

Что резервировать в контуре 1С

1. База Microsoft SQL Server

Для SQL Server обычно рассматривают несколько типов резервных копий:

• Full Backup — полная резервная копия базы;
• Differential Backup — изменения относительно базовой полной копии;
• Transaction Log Backup — резервные копии журнала транзакций для Full/Bulk-Logged Recovery Model.

Microsoft указывает, что для восстановления в простой типовой последовательности могут использоваться последняя полная копия, последняя подходящая differential-копия и последующие log backup в правильном порядке.

2. Сервер приложений 1С

Нужно понимать, как восстановить не только SQL-базу, но и инфраструктуру сервера 1С:

• версию платформы;
• настройки служб;
• параметры кластера;
• сервисные учётные записи;
• необходимые компоненты и драйверы;
• настройки публикаций и интеграций.

3. Зависимая инфраструктура

В зависимости от архитектуры могут понадобиться:

• IIS или Apache для веб-публикаций;
• сертификаты;
• SQL Server Agent Jobs;
• файловые каталоги и сетевые ресурсы;
• внешние обработки;
• обмены и интеграционные сервисы;
• DNS, Active Directory, RDS и лицензирование.

Поэтому Disaster Recovery для 1С — это восстановление сервиса целиком, а не только одного файла .bak.

Snapshot виртуальной машины — не полноценный backup

VMware/Broadcom прямо рекомендует не использовать snapshots виртуальных машин как резервные копии. Snapshot зависит от базового виртуального диска и предназначен прежде всего для кратковременных сценариев отката.

Правило 3-2-1 для резервных копий 1С

Базовый принцип 3-2-1 предполагает несколько независимых экземпляров данных, разные уровни хранения и хотя бы одну копию вне основной площадки.

Такая схема снижает риск ситуации, когда одна авария, ошибка администратора или компрометация учётной записи уничтожает одновременно production и все доступные backup.

RPO и RTO простыми словами

NIST определяет RPO как точку во времени, до которой должны быть восстановлены данные после сбоя, а RTO — как допустимую длительность фазы восстановления до того, как простой начнёт неприемлемо влиять на бизнес-процессы.

Пример:

• RPO = 15 минут — бизнес допускает потерю максимум последних 15 минут операций;
• RTO = 2 часа — 1С должна снова стать доступна пользователям не позднее чем через два часа.

Если backup базы выполняется только один раз ночью, это не обеспечивает RPO в 15 минут. При Full Recovery Model для более частых точек восстановления обычно используют Transaction Log Backup с периодичностью, соответствующей требованиям бизнеса.

Пример схемы резервного копирования

RESTORE VERIFYONLY полезен, но недостаточен

В SQL Server есть команда RESTORE VERIFYONLY. Она проверяет, что backup set читается и выглядит завершённым, однако Microsoft отдельно указывает: команда не выполняет фактическое восстановление и не проверяет структуру данных так же, как полноценный restore.

Поэтому RESTORE VERIFYONLY стоит использовать как дополнительную автоматическую проверку, но не как замену регулярному восстановлению базы на тестовом SQL Server.

Дополнительно SQL Server поддерживает backup checksums. Их использование помогает выявлять определённые ошибки во время операций backup/restore, однако и checksum не отменяет необходимости реального тестового восстановления.

Как проверить восстановление базы 1С

Шаг 1. Подготовить изолированную тестовую среду

Для проверки используйте:

• отдельный SQL Server или тестовую VM;
• отдельное имя базы;
• изолированный VLAN или закрытый сетевой сегмент — если это требуется архитектурой;
• отключённые реальные интеграции, рассылки и регламентные задания, способные воздействовать на production.

Шаг 2. Восстановить Full Backup

Сначала восстанавливается базовая полная копия, от которой строится выбранная последовательность восстановления.

Шаг 3. Применить Differential Backup — если он используется

Обычно выбирается наиболее свежая differential-копия, основанная на нужном Full Backup.

Шаг 4. Применить Transaction Log Backup

При Full Recovery Model последующие журналы восстанавливаются в хронологическом порядке. Если необходимый log backup из цепочки потерян или повреждён, продолжить восстановление за эту точку в рамках этой цепочки не получится.

Шаг 5. Подключить восстановленную базу к тестовой 1С

Минимальный функциональный тест:

• информационная база добавляется и открывается;
• пользователь может авторизоваться;
• открываются основные справочники и документы;
• формируются ключевые отчёты;
• видны ожидаемые последние операции;
• нет критичных ошибок платформы и SQL;
• проверены критичные для бизнеса функции.

Шаг 6. Измерить фактический RPO

Пример:

• авария смоделирована на 14:00;
• последняя операция в восстановленной базе — 13:47;
• фактическая потеря данных — 13 минут.

Теперь результат можно сравнить с целевым RPO.

Шаг 7. Измерить фактический RTO

Только после такого теста можно говорить о подтверждённом времени восстановления.

Типовые ошибки

Backup хранится рядом с production

Отказ хранилища, ошибка администратора или ransomware могут затронуть одновременно рабочую систему и доступные резервные копии.

Проверяется только статус задания

Статус Success полезен для мониторинга, но не подтверждает, что бизнес-сервис полностью восстановится.

Не проверяется цепочка Transaction Log

Для восстановления через log backup важна доступность нужных журналов и правильный порядок их применения.

Snapshot считается backup

VMware/Broadcom не рекомендует использовать snapshots как механизм резервного копирования VM, особенно как долгосрочную защиту базы данных.

Нет независимой off-site копии

Все данные остаются внутри одного административного или физического контура.

RTO существует только в документе

Если полное восстановление никогда не выполнялось, реальное время возврата 1С в работу неизвестно.

Чек-лист резервного копирования 1С

• SQL Server создаёт резервные копии автоматически.
• Ошибки backup контролируются и вызывают уведомление.
• Определены целевые RPO и RTO.
• Есть локальная резервная копия.
• Есть независимая off-site копия.
• Есть защита от массового удаления/шифрования backup.
• VM Snapshot не используется как единственный backup.
• Известна и документирована последовательность восстановления.
• RESTORE VERIFYONLY используется только как дополнительная проверка.
• Проводится реальный test restore в отдельной среде.
• После SQL restore проверяется сама информационная база 1С.
• Замеряется фактический RPO.
• Замеряется фактический RTO.
• У ответственных сотрудников есть необходимые доступы и инструкция.

Backup считается рабочим после проверки восстановления

Можно годами создавать резервные копии и обнаружить проблему только в момент аварии. Поэтому резервное копирование 1С нельзя сводить к задаче «каждую ночь создать .bak».

Лучший момент проверить backup — когда рабочая 1С продолжает нормально работать, а не после отказа SQL Server, повреждения хранилища или инцидента с шифровальщиком.

Источники

1. Microsoft Learn — Restore sequences (Full Recovery Model): документация SQL Server.
2. Microsoft Learn — Apply Transaction Log Backups: порядок восстановления log backup.
3. Microsoft Learn — RESTORE VERIFYONLY: ограничения VERIFYONLY.
4. Microsoft Learn — backup checksum default: backup checksums.
5. CISA — #StopRansomware Guide: рекомендации по offline/изолированным backup и тестированию восстановления.
6. Broadcom / VMware — Best practices for using VMware snapshots: snapshots не следует использовать как backup.
7. NIST CSRC — Recovery Point Objective: определение RPO.
8. NIST CSRC — Recovery Time Objective: определение RTO.