Резервное копирование часто воспринимают как техническую галочку: “копии настроены”, “место на NAS есть”, “скрипт работает”, “облако подключено”. Но для бизнеса важен не сам факт копирования, а возможность быстро восстановить работу: 1С, базы данных, файловые ресурсы, AD, почту, доступы, обмены и критичные сервисы.
Проблема проявляется в момент инцидента. Сервер не загружается, база 1С повреждена, сотрудник удалил документы, шифровальщик задел файловую шару или обновление прошло неудачно. Команда открывает систему бэкапов — и только тогда выясняет, что последняя копия неполная, пароль никто не знает, восстановление не тестировалось, а зависимые сервисы забыли включить в план.
Рабочий контур резервного копирования заканчивается не созданием копии, а проверенным восстановлением сервиса.
Почему “бэкап есть” не гарантирует восстановление
В реальности бэкап может существовать, но не решать задачу бизнеса. Например, копия делается каждый день, но в неё не попадают файловые вложения, расширения 1С, настройки обменов или внешние обработки. Или копия есть, но восстановление на тестовом сервере занимает 18 часов, а бизнес может стоять не больше двух.
Ещё один частый риск — отсутствие ответственного регламента. Когда всё работает, кажется, что администратор “в случае чего разберётся”. Но при инциденте нужно быстро понимать: какую копию брать, куда восстанавливать, кто принимает решение, какие сервисы включать первыми и как проверить, что 1С действительно открывается и документы не повреждены.
Частые проблемы:
- Копия неполная. Сохранили базу, но забыли файловое хранилище, расширения, внешние обработки, обмены, сертификаты или настройки пользователей.
- Копия слишком старая. Резервное копирование идёт раз в сутки, а бизнес считает, что потеряет максимум 15 минут данных.
- Нет места для восстановления. Бэкап лежит на NAS, но нет тестового сервера или свободного хранилища, чтобы быстро поднять копию.
- Не проверяли запуск. Файл восстановили, но 1С не стартует, база требует ремонта, пользователи не могут подключиться, обмены не работают.
Что особенно важно для 1С
1С редко существует сама по себе. Вокруг неё есть SQL Server или PostgreSQL, файловые ресурсы, расширения, внешние обработки, регламентные задания, обмены с сайтом, ЭДО, кассами, банками, складами, сервисами маркировки и отчётности. Поэтому “сделать копию базы” — только часть задачи.
- для файловых баз нужно понимать, где лежит каталог, кто имеет доступ и как исключить повреждение при копировании;
- для SQL/PostgreSQL важны корректные дампы/снапшоты, журналы, консистентность и порядок восстановления;
- для больших баз нужно учитывать время копирования, время проверки и нагрузку на сервер;
- для обменов важно сохранить настройки подключений, сертификаты, регламенты и права;
- для пользователей важно восстановить не только базу, но и доступ к рабочим местам, RDP, VPN, AD и файловым ресурсам.
RPO и RTO: два вопроса для руководителя
В резервном копировании есть два практических показателя, которые должны быть понятны не только ИТ, но и руководству.
RPO — сколько данных можно потерять
Если копия делается раз в сутки, бизнес потенциально теряет день работы. Для продаж, склада и бухгалтерии это может быть неприемлемо.
RTO — за сколько нужно восстановиться
Если восстановление 1С занимает сутки, а склад не может ждать больше двух часов, текущая схема не соответствует бизнесу.
Без RPO/RTO бэкапы обычно настраиваются “как получилось”: по расписанию, месту и привычке администратора. С RPO/RTO появляется управляемый подход: что копируем, как часто, куда, кто проверяет и сколько времени бизнес реально может стоять.
Что проверить в своей инфраструктуре
- Какие системы критичны: 1С, SQL/PostgreSQL, файловые ресурсы, AD, RDP, VPN, почта, сайты, обмены, кассы, ЭДО.
- Как часто создаются копии и соответствует ли это реальному допустимому объёму потери данных.
- Где лежат копии: локально, на отдельном сервере, на NAS, в облаке, офлайн или в immutable-хранилище.
- Есть ли копии, недоступные для шифровальщика или администратора с обычными правами.
- Проверялись ли копии восстановлением, а не только успешным завершением задания.
- Есть ли отдельный регламент: кто принимает решение, кто восстанавливает, кто проверяет бизнес‑данные.
- Сколько времени занимает восстановление полной 1С и зависимых сервисов на тестовой площадке.
Как построить нормальный контур резервного копирования
Рабочая схема резервного копирования — это не один продукт и не одна настройка. Это процесс, где технические решения связаны с бизнес‑приоритетами.
Чем критичнее 1С и серверы для бизнеса, тем важнее разнести копии по уровням и регулярно проверять восстановление.
1. Составить карту критичных сервисов
Определить, что именно нужно восстановить для продолжения работы: 1С, базы, файлы, AD, RDP, обмены, сертификаты, права.
2. Зафиксировать RPO/RTO
Согласовать с руководством, сколько данных допустимо потерять и за сколько часов нужно восстановить ключевые системы.
3. Разнести копии по уровням
Локальная быстрая копия, отдельное хранилище, внешняя площадка или облако, защита от удаления и шифрования.
4. Настроить мониторинг заданий
Не просто “скрипт запустился”, а понятные уведомления об ошибках, пропусках, нехватке места и устаревших копиях.
5. Провести тест восстановления
Поднять 1С и зависимые сервисы на тестовой площадке, проверить вход пользователей, документы, обмены и скорость запуска.
6. Повторять проверку регулярно
После обновлений 1С, изменения серверов, роста базы или появления новых сервисов контур бэкапов нужно пересматривать.
Как может помочь WeProf
WeProf смотрит на резервное копирование не как на отдельную программу, а как на часть управляемой инфраструктуры: 1С, серверы, базы данных, доступы, мониторинг, регламенты и SLA.
Мы можем:
- провести аудит текущего резервного копирования 1С и серверов;
- проверить, какие базы, файлы, сервисы и настройки не попадают в копии;
- оценить RPO/RTO и сопоставить их с реальными требованиями бизнеса;
- настроить хранение копий на разных уровнях, включая защиту от удаления и шифрования;
- провести тестовое восстановление 1С, SQL/PostgreSQL и зависимых сервисов;
- подготовить регламент аварийного восстановления;
- взять инфраструктуру, 1С и мониторинг в SLA‑сопровождение.
FAQ
Достаточно ли копировать только базу 1С?
Нет. Нужно учитывать файловое хранилище, расширения, внешние обработки, настройки обменов, сертификаты, права, сервер приложений и базу SQL/PostgreSQL.
Как часто нужно тестировать восстановление?
Минимум после значимых изменений: обновления 1С, миграции сервера, роста базы, изменения схемы хранения или появления новых критичных сервисов.
Что опаснее всего?
Бэкапы, которые никто не проверял восстановлением. Успешный статус задания ещё не означает, что бизнес сможет работать после инцидента.
Нужно ли хранить копии вне офиса?
Для критичных систем — да. Если все копии доступны из одного контура, шифровальщик, пожар, авария или ошибка администратора могут уничтожить и рабочие данные, и бэкапы.
По теме статьи
Проверьте, что ваша 1С и серверы действительно восстановятся
Оставьте заявку — разберём текущую схему бэкапов, проверим критичные сервисы, оценим RPO/RTO и покажем, где есть риск многодневного простоя.