Сервер 1С может пасть по любой причине - от шифровальщика до сгоревшего рейд-контроллера. Без рабочего бэкапа компания теряет не только базу, но и день, неделю или больше работы пользователей. Хорошее резервное копирование 1C - это не «настроил и забыл», а отдельный рабочий процесс с расписанием, хранилищем, шифрованием и регулярным тестом восстановления.
В статье - последовательность из шести шагов: что бэкапить, как настроить бэкап СУБД, когда нужна выгрузка .dt, какая стратегия частоты и хранения, куда складывать копии и как тестировать восстановление. Подойдёт и для разовой настройки нового сервера, и для аудита того, что у вас уже настроено.
Что именно бэкапить в инфраструктуре 1С
Шесть компонентов, без которых восстановление либо невозможно, либо растягивается на дни.
- База СУБД - главное. Это и есть «база 1С» в техническом смысле: все справочники, документы, регистры. Делается средствами СУБД, не платформы 1С.
- Журнал транзакций СУБД нужен для восстановления на момент времени (point-in-time recovery), а не только на момент последнего полного бэкапа. Без него теряется работа с момента последней полной копии.
- Каталог srvinfo сервера 1С - метаданные кластера, кэши, журнал регистрации (если в формате SQLite). Кластер без него восстановить можно, но дольше и руками.
- Выгрузка конфигурации .cf - снимок текущей конфигурации базы. Полезен при разработке и обновлениях, но это не замена бэкапу базы.
- Файловые базы 1С (.1CD) - отдельный сценарий, разобран ниже в разделе про средства платформы.
- Лицензии и серверные ключи - отдельно сохранить .key-файлы и контакт владельца HASP-ключей.
Бэкап СУБД: главный шаг
MS SQL: SQL Server Agent и Maintenance Plans
Бэкап ms sql 1С настраивается через штатный инструмент SQL Server. Шаги по порядку.
- Перевести базу в режим Full Recovery. Без него нельзя делать бэкап журнала транзакций.
- Через SQL Server Management Studio → Maintenance Plans создать план: задачи Backup Database (Full) еженедельно, Backup Database (Differential) ежедневно, Backup Transaction Log каждые 15–30 минут.
- Настроить Cleanup Task - удалять копии старше двух недель, чтобы диск не переполнялся.
- Включить Verify Backup Integrity (RESTORE VERIFYONLY) - это спасает от тихо битых файлов.
- Прописать рассылку результатов через Database Mail и Operator. Без уведомлений вы не узнаете, что бэкап сломался, до момента, когда он понадобится.
- Учётка SQL Server Agent должна иметь права на запись в каталог хранения копий - частая причина «непонятных» сбоев бэкапа.
PostgreSQL: pg_dump, pg_basebackup, WAL-archiving
В PostgreSQL для 1С три уровня бэкапа, они дополняют друг друга.
- pg_dump - логическая выгрузка базы в SQL-скрипт или custom-формат. Для крупной продуктивной базы pg_dump не подходит как основная стратегия резервного копирования: выгрузка занимает часы и не даёт point-in-time recovery. Для небольших баз и тестовых окружений - рабочий вариант.
- pg_basebackup - физическая копия каталога данных PostgreSQL целиком. Быстрее pg_dump, годится для крупных баз. Запускается с правами postgres-пользователя.
- WAL-archiving - постоянное архивирование журналов записи. Вместе с базовой копией от pg_basebackup даёт восстановление на любую точку времени.
Для серьёзного прода ставится Barman или pgBackRest, они автоматизируют всё перечисленное и решают сжатие, дедупликацию, хранение. Расписание через cron, без cron-задачи бэкап остаётся ручным.
Бэкап средствами платформы 1С
Выгрузка базы 1С в формат .dt - встроенный механизм платформы, который многие администраторы по привычке используют как бэкап. Делается через консоль администрирования или через 1cv8.exe DESIGNER /DumpIB. Технически .dt - это полный логический срез базы, но как штатное средство бэкапа продакшена он не годится.
Где .dt оправдан: смена сервера, миграция между MS SQL и PostgreSQL, отдача базы во внешнюю инстанцию (обработчику или партнёру). Это инструмент переноса, а не замена бэкапу СУБД. Выгрузка крупной базы занимает часы и блокирует работу. Восстановление из .dt тоже идёт долго - на роль ежедневного бэкапа прода это не подходит.
Автоматизировать выгрузку всё равно полезно для миграций и под отдельные сценарии. На Windows - bat или PowerShell через Task Scheduler, на Linux - bash через cron, учётка должна иметь права на ИБ. Файловые базы 1С - отдельный случай: бэкап .1CD делается копированием файла после остановки сервиса 1С или через .dt, копирование на лету без остановки часто даёт битый файл.
Стратегия бэкапа: как часто, куда, сколько хранить
Правило 3-2-1 как ориентир
Стратегия резервного копирования начинается с классического индустриального правила 3-2-1, и для 1С оно работает без поправок.
- Три копии данных: одна - оригинал на сервере, две - резервные. Если выйдет из строя одна копия, останется ещё одна страховка.
- На двух разных носителях: например, диск самого сервера плюс отдельная сетевая СХД, или внутренний RAID плюс сетевое хранилище NAS. Один RAID - это не две копии.
- Одна копия - вне локации (off-site). На другом физическом объекте, в облаке или в офисе филиала. Защита от пожара, потопа и шифровальщика, который дотянется до всех сетевых дисков.
Расписание под это правило: полный бэкап раз в неделю, дифференциальный ежедневно, журнал транзакций каждые 15–30 минут. Так теряется максимум полчаса работы при инциденте. Хранить - минимум четыре полных еженедельных копии плюс ежедневные за месяц: если в базе обнаружится тихая порча, пригодится копия двух- или трёхнедельной давности.
Шифрование копий - стандартное требование, особенно если копия покидает периметр. Без шифрования бэкап в облаке или на внешнем диске превращается в утечку ПДн при первом инциденте.
Куда складывать резервные копии
Пять рабочих вариантов хранилища - от категорически плохих до правильных.
- На том же сервере, где работает 1С нельзя. Шифровальщик, пожар или сбой RAID унесут и базу, и копии одновременно.
- Отдельная серверная СХД с RAID - стандартный вариант для среднего бизнеса. Подключение по iSCSI или NFS, отдельная сеть для бэкап-трафика.
- NAS в той же серверной - рабочий вариант для малого бизнеса. Минус: общая инфраструктура с серверами, от пожара или потопа в комнате не защищает.
- Облачное хранилище - отдельная копия off-site. Российский провайдер с шифрованием на стороне клиента, чтобы данные не уходили в чужой open.
- Дедупликация копий - экономит место при ежедневных бэкапах с похожим содержимым. Поддерживается современными СХД и большинством серьёзных решений.
Когда объём ежедневных копий перерастает возможности обычного NAS-хранилища, имеет смысл сразу смотреть на специализированное оборудование для резервного копирования: с дедупликацией, аппаратным шифрованием и достаточной пропускной способностью под бэкап-окно.
Тестирование восстановления: без него бэкапа нет
Главное правило: непротестированный бэкап - это не бэкап. На практике большая часть «не работающих» восстановлений случается у тех, у кого расписание копирования настроено идеально, но никто никогда не пробовал развернуть копию обратно. Узнают об этом в момент реальной аварии.
Регламент простой. Полное тестовое восстановление - раз в месяц на отдельный тестовый сервер: открыть восстановленную базу из 1С, провести тестовый документ. Точечное - раз в квартал: восстановить копию недельной давности, проверить, что цепочка журналов транзакций живая. После каждого крупного обновления конфигурации или платформы - внеплановый тест. И всегда вести журнал восстановлений с датой, версией, временем, ответственным. Если тест не вышел - проблема выясняется на учебной задаче, а не во время инцидента.
Чего точно не делать
Короткий список «нельзя» - каждый пункт хотя бы раз был причиной потери базы у того или иного коллеги.
- Хранить копии на том же диске, где живёт сама база. RAID, к сожалению, не отменяет этого правила.
- Делать бэкап только средствами платформы 1С (.dt) для прода. Это инструмент миграции, не бэкап-стратегия.
- Складывать копии в облако без шифрования. Один скомпрометированный API-токен и вся база у того, кто не должен её видеть.
- Не отправлять уведомления о сбоях бэкапа. Молчаливо упавший job - самая частая причина «у нас вроде был бэкап».
Заключение
Автоматический бэкап 1С - это шесть составляющих: бэкап СУБД с журналом транзакций, выгрузка .dt для миграций, стратегия 3-2-1 с расписанием, надёжное хранилище off-site, шифрование и регулярный тест восстановления. Отвалится любая из шести - в момент реального инцидента всё построение посыпется.
Если на компанию накладываются регуляторные требования или сама база уже не помещается в самописные скрипты, проще закрыть задачу комплексно - собрать систему резервного копирования с шифрованием, off-site-репликой и протестированной процедурой восстановления, а не строить её по кусочкам из bat-файлов и cron-задач.
