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

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

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

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

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

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

Копирование файла 1Cv8.1CD — самый быстрый способ для файловых баз, но требует, чтобы в базе не было активных сеансов: иначе файл скопируется в несогласованном состоянии и может не открыться. Резервная копия средствами СУБД (для клиент-серверных баз) — основной рабочий инструмент: она выполняется «на горячую», без отключения пользователей, и позволяет восстановить базу на момент времени при использовании полной модели восстановления.

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

Это базовый способ, который должен освоить каждый, кто отвечает за 1С. Откройте конфигуратор под пользователем с полными правами, перейдите в меню «Администрирование» → «Выгрузить информационную базу» и укажите путь и имя файла. Удобно включать в имя файла дату, например UT_2026-06-15.dt — так проще разбирать архив.

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

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

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

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

Файловая база — это папка, в которой главный файл 1Cv8.1CD содержит все данные и конфигурацию. Чтобы сделать резервную копию, достаточно скопировать этот файл в другое место. Главное условие — в базе не должно быть открытых сеансов, включая фоновые задания и подключения через веб-сервер. Проверить это можно по наличию файла блокировок 1Cv8.1CL рядом с базой: если он есть, кто-то подключён.

Автоматизировать копирование можно простым скриптом и планировщиком заданий Windows. Скрипт запускается ночью, когда пользователей нет, копирует файл и складывает копии в папку с датой в имени.

robocopy "D:\Bases\Trade" "E:\Backups\Trade_%date:~-4%-%date:~3,2%-%date:~0,2%" 1Cv8.1CD /R:2 /W:5

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

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

Если база работает на Microsoft SQL Server, резервные копии создаются средствами самой СУБД — через SQL Server Management Studio или скриптом T-SQL. Простейшая команда полного бэкапа выглядит так:

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

Для автоматизации используют планы обслуживания (Maintenance Plans) или задания SQL Server Agent: полная копия — ежедневно ночью, дифференциальные — несколько раз в день. Если база переведена в полную модель восстановления (Full recovery model), дополнительно настраивают бэкап журнала транзакций — это позволяет восстановить базу на произвольный момент времени, а не только на момент последней копии.

Важные ограничения: не используйте простое копирование файлов .mdf/.ldf при работающем SQL Server — файлы заблокированы и копия будет битой. Также помните, что бэкап должен складываться на диск, физически отличный от дисков с данными SQL Server, иначе отказ массива уничтожит и базу, и копии.

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

Минимально разумный регламент для небольшой базы: автоматическая копия ежедневно в нерабочее время, хранение ежедневных копий за последние 7–14 дней, еженедельных — за 1–2 месяца, ежемесячных — за год. Конкретная глубина зависит от требований учёта: иногда нужно поднять данные полугодовой давности для сверки или проверки.

Ключевой принцип хранения — правило «3-2-1»: минимум три копии данных, на двух разных носителях, одна — вне основной площадки (другой офис, облачное хранилище, сетевое хранилище NAS). Копии на том же диске, где лежит база, защищают только от случайного удаления, но не от отказа диска, шифровальщика или пожара.

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

Проверка восстановления: как убедиться, что копии рабочие

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

Для SQL-базы тестовое восстановление выполняется командой RESTORE в отдельную базу с другим именем — ни в коем случае не поверх рабочей. Дополнительно полезно периодически запускать проверку целостности: для файловых баз — утилиту chdbfl.exe из каталога платформы (только на копии файла, не на рабочей базе), для SQL Server — команду DBCC CHECKDB.

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

Частые вопросы о резервных копиях 1С