Как сохранять базу данных 1С: резервное копирование без потерь

Резервная копия базы 1С — единственная страховка от потери учётных данных при сбое диска, вирусе-шифровальщике, ошибке обновления или случайном удалении документов. Способ сохранения зависит от режима работы: файловая база копируется иначе, чем клиент-серверная на SQL, и путать эти сценарии нельзя.

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

Ниже разобраны рабочие методы: выгрузка в файл DT через конфигуратор, копирование файловой базы, штатные средства MS SQL Server и PostgreSQL, автоматизация по расписанию и проверка того, что копия действительно восстанавливается.

Какие способы сохранения базы 1С существуют

Существует три основных подхода, и у каждого своё назначение. Выгрузка в DT — универсальный механизм платформы, который сохраняет данные вместе со структурой конфигурации в один переносной файл. Копирование файлов базы — быстрый способ для файлового режима, когда нужен точный снимок каталога. Резервное копирование средствами СУБД — стандарт для клиент-серверных развёртываний, где объёмы велики и важна скорость.

Эти методы не исключают друг друга. Практичная схема для серверной базы — ежедневный бэкап средствами СУБД плюс периодическая выгрузка DT перед обновлениями конфигурации. Для файловой базы достаточно регулярной выгрузки DT и копирования каталога, если сеансы корректно завершаются.

Выгрузка базы в файл DT через конфигуратор

Выгрузка в DT выполняется через конфигуратор и подходит как для файловых, так и для клиент-серверных баз. Откройте конфигуратор под пользователем с административными правами, перейдите в меню «Администрирование» и выберите пункт «Выгрузить информационную базу». Укажите путь и имя файла, после чего дождитесь окончания процесса.

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

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

1. 1
   Завершите сеансы пользователей или установите блокировку соединений
2. 2
   Откройте конфигуратор под администратором
3. 3
   Выберите «Администрирование» → «Выгрузить информационную базу»
4. 4
   Укажите путь к файлу DT на диске с достаточным свободным местом
5. 5
   Дождитесь завершения и проверьте, что файл создан и имеет ненулевой размер

Копирование файловой базы данных

Файловая база хранится в каталоге, ключевой файл — 1Cv8.1CD. Чтобы сохранить такую базу, достаточно скопировать весь каталог целиком, но только когда в ней никто не работает. Активный сеанс держит файл открытым, и скопированный «на живую» файл может содержать несогласованные страницы данных.

Проверить отсутствие сеансов можно через список активных пользователей в конфигураторе или просто убедившись, что все коллеги вышли из программы. Также убедитесь, что не запущены фоновые задания, регламентные операции и что база не открыта в другом конфигураторе.

Если база размещена на сетевом ресурсе, копирование лучше выполнять на самом сервере, а не по сети с рабочей станции — так быстрее и меньше шанс обрыва посреди процесса. После копирования сверьте размер исходного и скопированного файла: они должны совпадать.

Резервное копирование клиент-серверной базы

В клиент-серверном режиме данные хранятся не в файле 1Cv8.1CD, а в базе СУБД — чаще всего MS SQL Server или PostgreSQL. Копировать файлы СУБД вручную нельзя: корректный бэкап делается штатными средствами самой СУБД, которые обеспечивают согласованность данных без остановки работы пользователей.

MS SQL Server

Для MS SQL Server используют полную резервную копию (FULL backup) через SQL Server Management Studio: правый клик по базе → «Задачи» → «Создать резервную копию». Для регулярной работы настраивают план обслуживания с ежедневным полным бэкапом и, при необходимости, копиями журнала транзакций, позволяющими восстановить базу на конкретный момент времени.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_full.bak' WITH COMPRESSION, CHECKSUM;

PostgreSQL

Для PostgreSQL применяют утилиту pg_dump или pg_dumpall. Команда pg_dump с ключом -Fc создаёт сжатую копию в собственном формате, которую затем восстанавливают через pg_restore. Как и в случае с MS SQL, выгрузку можно выполнять без остановки работы пользователей — СУБД обеспечит согласованный снимок.

pg_dump -U postgres -Fc -f /backup/mybase1c_$(date +%Y%m%d).dump mybase1c

Обратите внимание: бэкап СУБД не заменяет выгрузку DT полностью. DT нужен, когда базу переносят между разными СУБД или платформами, а также как дополнительная страховка перед обновлением конфигурации — восстановление из DT проще контролировать на уровне прикладного решения.

Автоматизация: расписание и ротация копий

Разовая копия не защищает от типичных сценариев потери данных. Настройте автоматическое создание копий по расписанию: для файловых баз — скрипт, который проверяет отсутствие сеансов и копирует каталог; для серверных — план обслуживания в СУБД или задание планировщика с pg_dump.

Храните несколько поколений копий: например, ежедневные за последнюю неделю, еженедельные за месяц и ежемесячные за более длинный срок. Это позволит откатиться не только на «вчера», но и на момент до того, как ошибка попала в данные — иногда порчу обнаруживают спустя дни или недели.

Обязательно размещайте копии на физически другом носителе или в другом сетевом расположении, а в идеале — с копией вне основной площадки. Бэкап, лежащий на том же диске, что и база, не спасёт ни от отказа диска, ни от шифровальщика, который добирается до всех доступных сетевых папок.

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

Копия, которая не проверялась восстановлением, считается отсутствующей. Периодически разворачивайте свежий бэкап в тестовую базу и убеждайтесь, что она открывается, проходит тестирование и исправление и содержит актуальные документы.

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

Типичные ошибки и ограничения

Самая частая ошибка — копирование файловой базы при открытых сеансах. Вторая по распространённости — хранение всех копий на том же диске или в той же сетевой папке, что и рабочая база. Третья — отсутствие ротации: одна-единственная копия каждый раз перезаписывается, и если в момент копирования что-то пошло не так, работоспособной копии не остаётся вовсе.

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

Частые вопросы