Что такое резервирование в 1С и как его настроить

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

Важно понимать: резервирование и архивация внутри программы — разные вещи. Свертка базы или пометка объектов на удаление не создают копию, а выгрузка данных в обменные форматы (XML, CSV) не гарантирует полного восстановления. Настоящее резервирование — это регулярное создание полной копии базы с проверкой, что из неё реально можно поднять рабочую систему.

Способ резервирования зависит от режима работы базы. Файловая база — это один файл 1Cv8.1CD, который можно скопировать напрямую или выгрузить в DT. Клиент-серверная база хранится в СУБД (MS SQL, PostgreSQL, IBM DB2, Oracle), и копировать надо средствами самой СУБД или через выгрузку из конфигуратора.

Какие данные нужно резервировать

Минимальный объект резервирования — сама информационная база. В файловом варианте это файл 1Cv8.1CD плюс прилегающие каталоги, если используются внешние хранилища файлов. В клиент-серверном варианте — база данных на сервере СУБД.

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

Способы резервного копирования

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

Для файловой базы допустимо простое копирование файла 1Cv8.1CD, но только при полном закрытии базы всеми пользователями. Копирование открытого файла даёт повреждённую копию, из которой база не откроется или откроется с ошибками целостности.

Для клиент-серверных баз основной метод — штатные средства СУБД: полные и разностные бэкапы в MS SQL, pg_dump или физические копии в PostgreSQL. Такие копии создаются «на горячую», без остановки работы пользователей, и подходят для больших баз.

Сравнение способов

Как настроить выгрузку DT вручную

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

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

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

Автоматизация резервирования

Ручное копирование быстро перестаёт выполняться регулярно, поэтому резервирование должно быть автоматическим. Для файловых баз используют планировщик Windows со скриптом, который запускает конфигуратор в пакетном режиме с командой выгрузки или копирует файл базы в нерабочее время.

"C:\Program Files\1cv8\platform\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Admin" /P"пароль" /DumpIB"E:\Backups\trade_%date%.dt"

Для клиент-серверных баз автоматизация строится средствами СУБД: план обслуживания в MS SQL Server или задание cron/Task Scheduler с pg_dump для PostgreSQL. Типовая схема — полная копия ежедневно в нерабочее время, разностные копии или копии журнала транзакций в течение дня.

В типовых конфигурациях есть встроенный механизм «Резервное копирование и восстановление» (раздел «Администрирование» → «Обслуживание»). Он удобен для файловых баз небольших компаний: настраивается расписание, каталог хранения и глубина хранения копий. Ограничение — копирование выполняется только при запущенном сеансе пользователя с соответствующими правами.

Сколько копий хранить и как проверять восстановление

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

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

Типичные ошибки и риски

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

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

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