Резервное копирование баз 1С — стратегия без боли

Базу 1С можно потерять тремя способами: шифровальщик, сломанный диск, ошибка администратора. Все три случаются регулярно. Стратегия бэкапов «программист скидывает .dt в папку D:\backup раз в неделю» — не стратегия, а иллюзия.

Что не бэкап

• Выгрузка .dt. Это не консистентная копия БД, а сериализация — длинная, медленная, легко повреждается. Подходит только для переноса между серверами и небольших файловых баз.
• Снапшот VMware/Hyper-V «на ходу» без quiesce. Постгрес или MS SQL внутри VM в момент снапшота — это битый файл.
• Копия mdf/ldf на работающем сервере через xcopy. БД заблокирована, файл недописан.
• Backup на тот же диск, что и продакшен. Диск сдох — и бэкап вместе с ним.

Правильно — нативные средства СУБД

База 1С на MS SQL — Maintenance Plan с FULL + Differential + Log:

• FULL — раз в неделю.
• Differential — раз в день.
• Transaction log — каждые 15-60 минут.

Это даёт восстановление на любую минуту последнего часа.

На PostgreSQL — связка pg_basebackup для базы + WAL-archiving в S3:

archive_mode = on
archive_command = 'wal-g wal-push %p'
restore_command = 'wal-g wal-fetch %f %p'

WAL-G или Barman — два рабочих инструмента. Делают консистентные бэкапы без даунтайма.

Стратегия 3-2-1

• 3 копии данных (продакшен + 2 бэкапа).
• 2 разных носителя (например, NAS + S3).
• 1 копия off-site (другой ЦОД, другой регион, физически другая площадка).

Для 1С это значит: продакшен → локальный backup-сервер → S3 (Selectel, Яндекс, MTС Cloud), причём S3 в другом регионе.

Ротация — обязательно

Если не настроена ротация, бэкапы накапливаются, диск кончается. И не дай бог настроено «хранить вечно» — отчёт за прошлый год через 3 года становится обузой.

Рабочая схема для средней базы:

• Ежедневные — хранить 14 дней.
• Еженедельные — хранить 8 недель.
• Ежемесячные — хранить 12 месяцев.
• Ежегодные — хранить 5-7 лет (требования законодательства).

Шифровальщик

Главный страх 2025-2026. Если шифровальщик дошёл до бэкап-сервера — пиши пропало. Защита:

• S3 c object lock (WORM) — нельзя удалить или перезаписать до истечения retention.
• Бэкап-сервер в отдельном VLAN, доступ только с продакшен-серверов в одну сторону.
• Отдельный домен или вообще без домена — чтобы скомпрометированный AD не дал доступ.
• Регулярная проверка целостности (checksum, mtime).

Проверка восстановления

Бэкап, который никогда не восстанавливали — иллюзия. Минимум раз в квартал:

1. Поднять тестовый сервер.
2. Восстановить базу из последнего FULL + последнего Differential.
3. Запустить 1С, открыть базу, проверить целостность («Тестирование и исправление»).
4. Проверить, что выгрузка по типичному отчёту даёт ожидаемые цифры.

Без проверки 30-40% бэкапов оказываются битыми в момент аварии.

Сколько денег экономит

Восстановление 1С после шифровальщика без бэкапа — это 200-800 тыс ₽ выкуп (без гарантии) + неделя простоя + потеря данных за месяц. Правильная стратегия с S3 — 5-15 тыс ₽/мес. Окупаемость очевидная, пока не случится.

Вывод

dt-выгрузка — не бэкап. Нормальная стратегия: нативный бэкап СУБД (FULL/Diff/Log для MS SQL, pg_basebackup + WAL для PostgreSQL) + 3-2-1 с S3 object lock + ротация + проверка восстановления раз в квартал. Без любого пункта стратегия дырявая. После шифровальщика поздно настраивать.