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

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

Способ сохранения зависит от режима работы базы. Файловая база (каталог с файлом 1Cv8.1CD) копируется проще всего — достаточно выгрузки в dt или копирования файла. Клиент-серверная база на SQL Server, PostgreSQL или Oracle требует штатных средств СУБД: простое копирование файлов данных работающего сервера не даёт целостной копии. Ниже разобраны оба сценария с конкретными действиями и проверками.

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

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

Порядок действий: откройте базу в режиме «Конфигуратор» под пользователем с полными правами, затем выберите меню «Администрирование» → «Выгрузить информационную базу» и укажите путь и имя файла. В имя файла удобно включать дату, например buh_2026-05-15.dt, чтобы копии не перезаписывали друг друга. Во время выгрузки пользователи могут продолжать работать, но лучше выполнять её в нерабочее время: на больших базах процесс занимает заметное время и нагружает диск.

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

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

Копирование файловой базы напрямую

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

Чтобы гарантировать монопольность, либо договоритесь с пользователями о времени копирования, либо используйте скрипт, который сначала проверяет отсутствие блокировок. Альтернатива — плановая выгрузка в dt по ночам через пакетный режим конфигуратора: она безопаснее прямого копирования и не требует выгонять пользователей вручную.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /DumpIB"E:\Backup\buh_%date%.dt" /DisableStartupDialogs

Команда выше запускает конфигуратор в пакетном режиме и выгружает базу в dt без участия оператора. Путь к исполняемому файлу зависит от установленной версии платформы — проверьте каталог bin на своём компьютере. Такую строку добавляют в планировщик заданий Windows с ежедневным запуском в нерабочее время.

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

Если база работает на MS SQL Server, PostgreSQL или другой СУБД, правильный путь — штатные средства резервного копирования самой СУБД. В MS SQL Server это задача BACKUP DATABASE через план обслуживания (Maintenance Plan) или SQL-скрипт; в PostgreSQL — утилита pg_dump или pg_basebackup. Такие копии целостны, поддерживают сжатие и восстановление на момент времени.

Прямое копирование файлов .mdf и .ldf работающего SQL Server недопустимо: файлы заблокированы, а снятая «на горячую» копия через теневое копирование без понимания механизмов СУБД часто оказывается непригодной. Если администратора СУБД нет, безопасная альтернатива — та же выгрузка в dt через конфигуратор: она работает независимо от режима базы.

Расписание, ротация и места хранения копий

Разовая копия не защищает ни от чего: нужен график. Практичный минимум для активно используемой базы — ежедневная копия плюс более длительное хранение недельных и месячных срезов. Классическая схема ротации: 7 ежедневных копий, 4 недельных, 6–12 месячных. Так можно откатиться и на вчера, и на состояние до ошибочной свёртки базы квартал назад.

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

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

Единственный способ узнать, что копия рабочая, — восстановить её. Раз в месяц или хотя бы раз в квартал загрузите свежий dt в пустую базу на тестовом компьютере: «Конфигуратор» → «Администрирование» → «Загрузить информационную базу». После загрузки откройте базу в режиме «Предприятие», проверьте, что открываются журналы документов, строятся ключевые отчёты и данные соответствуют ожиданиям.

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

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

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

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

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