Сценарий “умер диск/сервер”: план восстановления 1С, который реально работает

Привет, друзья! На связи ведущий программист 1С Иван Николенко из компании OSMINOG PROJECT.

Это случилось в обычный вторник. Отделы бронируют заказы, бухгалтер платит налоги, на складе отгружают товар. И вдруг — тишина. 1С не открывается. Экран гаснет сообщением: «Файл базы поврежден»!

Системный администратор проводит диагностику. Приговор суров: жёсткий диск умер навсегда. Безвозвратно.

Можно ли было этого избежать? Да. Можно ли восстановиться и не потерять миллионы? Тоже да. Разбираем чёткий план действий — без паники, с холодной головой.

Шаг 1. Остановка и диагностика

В этот момент самое главное — не усугублять. Никаких перезагрузок, никаких попыток «починить» нажатием кнопок. Первым делом проверьте аппаратную часть сервера: диск, блок питания, оперативную память. Если это виртуальный сервер — посмотрите логи виртуализации и состояние сториджа. Убедитесь, что проблема именно в диске, а не в сетевой инфраструктуре или блокировках со стороны антивируса.

Шаг 2. Поиск работающей резервной копии

И здесь проявляется главная боль: многие уверены, что «у нас есть бэкапы». И в самый ответственный момент выясняется страшная правда: бэкап лежит на том же диске, который умер. Или он не восстанавливается. Или никто никогда не проверял, можно ли из него вообще восстановиться.

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

Шаг 3. Восстановление базы — подробный алгоритм

У вас есть два варианта работы с базой 1С: файловая и SQL (клиент-серверная). Действия отличаются в корне.

Восстановление базы

Для SQL-баз важно использовать отдельную систему резервирования на уровне СУБД. Если у вас настроены дифференциальные бэкапы (например, каждый час — дифференциальный, каждую ночь — полный), восстановление пройдёт быстрее. И не забывайте про проверку целостности бэкапов — хотя бы раз в неделю.

Шаг 4. Проверка и запуск

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

В практике ведущего программиста 1С компании OSMINOG PROJECT Ивана Николенко был случай, который идеально иллюстрирует, почему важно не просто делать бэкап, а продумать его план:

— Крупный поставщик стройматериалов, 12 складов, 30+ менеджеров, годовой оборот около 800 млн рублей. База 1С: ERP на MS SQL Server.

И вот однажды в пятницу вечером сервер замолчал навсегда. RAID-массив RAID 5 развалился полностью — синхронно умерли два диска. Последний полноценный бэкап был от прошлой субботы — недельной давности. Восстановление из него означало бы неделю полностью потерянной работы всех складов и отдела продаж.

Вот что сделала моя команда:

1. Диагностика за 40 минут. Первым делом проверили — диск реально мёртв, восстановление данных специализированными утилитами невозможно.

2. Экстренный обход. Обнаружили, что на резервном SQL-сервере стояла репликация только для отчётности, но база 1С там была не полностью актуальной — запаздывала на 7-8 часов.

3. Ручное донакопление. За 9 часов непрерывной работы команда вручную восстановила из реплики все документы за потерянный день, сверяя с первичкой, логами и бумажными накладными от контрагентов.

— Это адская работа — по одному документу восстанавливать день работы склада. Но выбор был простой: 9 часов ручного труда сейчас или неделя простоя с убытками в 4–5 млн рублей, — объясняет Иван.

Что изменили после инцидента:

- Настроили ежечасное дифференциальное резервное копирование на отдельный физический диск.

- Внедрили ежемесячное тестовое восстановление на резервный сервер «по щелчку».

- Купили и настроили реальный план Disaster Recovery: чёткие инструкции, роли ответственных, контакты подрядчиков.

В результате: даже если сервер умрёт сегодня в 15:00, к 18:00 того же дня компания будет работать с новым сервером и потеряет не более часа данных.

1. Настройте автоматическое резервное копирование. Средствами СУБД (например, SQL Server), с чёткими интервалами: полное — раз в сутки, дифференциальное — каждый час.

2. Храните бэкапы отдельно от сервера. На другом физическом диске, в облаке, в другом ЦОД.

3. Проверяйте бэкапы. Раз в месяц — тестовое восстановление на резервную машину.

4. Напишите план восстановления. Кто звонит, куда бежит, в каком порядке восстанавливать. Документ, который лежит не на умершем диске.

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

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

Помните — проще и дешевле предусмотреть, чем недосмотреть.