Резервное копирование 1С: как проверить, что база действительно защищена
Общие принципы бэкапов — хранить копию отдельно от оригинала, проверять восстановление, следить за уведомлениями об ошибках — разобраны в статье «5 признаков, что ваши бэкапы не восстановятся». У базы 1С есть своя специфика: копию можно сделать несколькими разными способами, и каждый способ ломается по-своему. Разбираем, что именно проверить в бэкапе именно 1С.
Почему базу 1С нельзя бэкапить так же, как обычные файлы
Документ Word или таблица Excel — это статичный файл: пока его никто не редактирует, скопировать его можно в любой момент, и копия будет полностью рабочей. База 1С — это не статичный файл, а активно используемая база данных: в неё в любой момент могут писать данные десятки пользователей одновременно. Если скопировать файлы базы «на живую», без корректной остановки или без специального механизма бэкапа, есть риск получить копию, в которой часть данных записана, а часть — нет: такая копия открывается, но внутри она нарушена, и это может выясниться далеко не сразу.
Способ, которым нужно делать бэкап, к тому же различается в зависимости от того, файловая у вас база или серверная — если не уверены, какая именно, это стоит уточнить в статье «1С: файловая или серверная база — в чём разница».
Три способа сделать резервную копию 1С — и где каждый чаще всего ломается
1. Выгрузка .dt через Конфигуратор.
Штатный способ 1С: пункт меню «Администрирование → Выгрузить информационную базу» создаёт единый файл .dt с полным содержимым базы. Плюс — файл гарантированно консистентен на момент выгрузки. Минус — выгрузка требует монопольного доступа, то есть на время процесса всех пользователей нужно отключить от базы, а на крупных базах это может занять от десятков минут до нескольких часов.
2. Копирование файла информационной базы (для файлового варианта).
Файловая база 1С хранится в одном файле 1Cv8.1CD. Его можно скопировать средствами операционной системы — но только пока к базе не подключён ни один пользователь и ни один фоновый процесс. Если копирование запускается по расписанию ночью, а в это время кто-то забыл закрытую сессию или работает регламентное задание, итоговый файл рискует оказаться повреждённым или незавершённым.
3. Резервное копирование средствами СУБД (для серверного варианта).
Если база работает на MS SQL Server или PostgreSQL, правильный способ — штатный бэкап самой СУБД, а не попытка скопировать файлы базы данных на диске. СУБД умеет делать это без остановки пользователей и без риска несогласованности. Частая ошибка — администратор бэкапит файлы каталога сервера 1С (кэш, логи, конфигурацию), но не настраивает отдельно регулярный бэкап именно базы данных на стороне СУБД — в результате «бэкап есть», а сама база в него не попадает.
Признаки, что бэкап 1С не защитит, когда понадобится
1. Выгрузку .dt никогда не пробовали загрузить обратно.
Файл .dt может создаваться без единой ошибки — и при этом оказаться неполным или несовместимым с текущей версией платформы при попытке восстановления. Единственный способ узнать это заранее — хотя бы раз загрузить .dt в тестовую базу и открыть её.
2. Бэкап запускается, пока в базе есть активные сессии.
И для выгрузки .dt, и для копирования файла 1CD требуется, чтобы база была свободна от подключений. Если расписание бэкапа не учитывает, что кто-то может работать допоздна или что запущена фоновая обработка, копия может создаться с ошибкой доступа — или, что хуже, тихо получиться неполной.
3. Бэкапится файл базы, но не бэкапится сама СУБД — или наоборот.
На серверном варианте нужен именно бэкап базы данных средствами СУБД. Копирование файлов каталога сервера 1С само по себе базу не сохраняет. Обратная ситуация тоже встречается: настроен бэкап СУБД, но забыты внешние файлы — например, каталог с присоединёнными к документам сканами и вложениями, если они хранятся не внутри базы.
4. Копия хранится на том же сервере, что и рабочая база.
Тот же риск, что и с любым другим бэкапом: при поломке диска или атаке шифровальщика копия погибает вместе с оригиналом. Резервная копия базы 1С должна физически или логически находиться в другом месте.
5. После восстановления не выполняется «Тестирование и исправление».
Штатная процедура 1С «Тестирование и исправление информационной базы» проверяет и по возможности исправляет внутреннюю структуру базы. Пропускать её после восстановления из бэкапа — рискованно: база может открыться и выглядеть рабочей, но содержать структурные ошибки, которые проявятся позже, в самый неподходящий момент.
6. Версия платформы или конфигурации в момент восстановления не совпадает с той, что была на момент бэкапа.
Если рабочая база успела обновиться до новой версии конфигурации, а восстанавливать приходится из более старой резервной копии, после восстановления может понадобиться повторно накатывать обновления — и это стоит учитывать заранее, а не выяснять в момент аварии.
| Что настроено | Где чаще всего слабое место | Что проверить |
|---|---|---|
| Выгрузка .dt по расписанию | Никогда не проверяли загрузку обратно | Пробное восстановление в тестовую базу |
| Копирование файла 1CD (файловая база) | Бэкап идёт при активных сессиях пользователей | Расписание бэкапа и время закрытия сессий |
| Серверная база на SQL/PostgreSQL | Бэкапится каталог сервера 1С, а не сама СУБД | Настройки регулярного бэкапа именно в СУБД |
| Есть присоединённые файлы (сканы, вложения) | Хранятся вне базы и не попадают в бэкап | Где физически лежат внешние файлы |
| Восстановление из бэкапа | «Тестирование и исправление» пропускается | Порядок действий после восстановления |
Чек-лист самопроверки
- Уточнить, каким именно способом делается бэкап базы — .dt, копия файла или бэкап СУБД
- Проверить, что бэкап запускается, когда в базе нет активных пользовательских сессий
- Хотя бы раз загрузить резервную копию в тестовую базу и открыть её
- Уточнить, попадают ли в бэкап присоединённые файлы вне базы, если они есть
- Убедиться, что копия хранится не на том же сервере, что рабочая база
- Прописать «Тестирование и исправление» как обязательный шаг после любого восстановления
Пример (условная ситуация, не описание конкретного клиента). В компании были уверены, что база 1С защищена: каждую ночь на сервере создавался архив папки с базой данных. При попытке восстановления после сбоя диска выяснилось, что в архив копировался каталог сервера 1С, а сама база данных на отдельном SQL-сервере отдельным бэкапом не была настроена вовсе. После настройки штатного бэкапа СУБД и тестового восстановления ситуация была исправлена — но узнать об этом стоило заранее, а не в момент реальной аварии.
Что делать прямо сейчас
Не обязательно сразу перестраивать всю схему резервного копирования. Начните с одного шага: возьмите последнюю резервную копию базы 1С и попробуйте развернуть её в тестовую базу. Если это удалось без ошибок — хороший знак. Если нет, лучше узнать об этом сейчас, чем в день, когда рабочая база действительно откажет.
Частые вопросы
База 1С — это активно используемая база данных, а не статичный файл. Копировать её «на живую», без остановки сессий или без штатного механизма бэкапа СУБД, — риск получить несогласованную, повреждённую копию.
Для серверной базы (SQL/PostgreSQL) — штатный бэкап средствами самой СУБД, он не требует остановки пользователей. Для файловой базы — копирование файла 1CD строго при отсутствии активных подключений либо выгрузка .dt.
Да — хотя бы раз загрузить копию в тестовую базу и открыть её. «Бэкап создался без ошибки» и «из него можно восстановить рабочую базу» — разные утверждения.
Штатная процедура 1С, проверяющая внутреннюю структуру базы. После восстановления из бэкапа база может открыться и выглядеть рабочей, но содержать структурные ошибки — процедура помогает их выявить и по возможности исправить.
Только если они хранятся внутри самой базы. Если для хранения вложений настроено внешнее хранилище на диске, его нужно бэкапить отдельно — это частая слабая точка, которую забывают проверить.