Как сделать бэкап 1С: все рабочие способы

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

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

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

Как определить тип базы и выбрать способ копирования

Перед настройкой бэкапа нужно понять, в каком режиме работает ваша база. Откройте список информационных баз в окне запуска 1С, выделите базу и нажмите «Изменить» — в параметрах будет указано «Файловый» (путь к каталогу на диске или сетевом ресурсе) или «Клиент-серверный» (указан сервер 1С и имя базы в СУБД). Этот же параметр виден в конфигураторе: Администрирование → Параметры информационной базы.

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

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

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

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

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

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

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

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

Критическое условие — во время копирования в базе не должно быть активных сеансов. Если копировать файл 1Cv8.1CD, пока пользователи работают, копия почти гарантированно будет повреждена или несогласована. Поэтому копирование планируют на ночь либо используют механизмы теневого копирования тома (VSS в Windows), которые позволяют снять согласованный снимок.

Автоматизировать копирование можно простым скриптом, запускаемым планировщиком заданий Windows. Ниже пример команды, которая копирует каталог базы в папку с текущей датой в имени:

robocopy "D:\Bases\Trade" "E:\Backup\Trade_%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%" /E /COPY:DAT /R:2 /W:5 /LOG:E:\Backup\copy_log.txt

Бэкап клиент-серверной базы средствами СУБД

Для базы на MS SQL Server основной способ — полная резервная копия средствами самой СУБД. В SQL Server Management Studio: правый клик по базе → Tasks → Back Up → тип Full, указать файл назначения. Для регулярного выполнения настраивают план обслуживания (Maintenance Plan) с ежедневной полной копией и, при необходимости, копиями журнала транзакций в течение дня — это позволяет восстановить базу на произвольный момент времени, а не только на момент ночного бэкапа.

Для PostgreSQL используется утилита pg_dump. Пример команды для выгрузки базы в сжатый файл:

pg_dump -U postgres -F c -f /backup/1c_base_$(date +%Y%m%d).dump base_name

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

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

Ручной бэкап рано или поздно забывают сделать, поэтому любой способ нужно автоматизировать. Для файловых баз — скрипт с robocopy или вызов конфигуратора в пакетном режиме с параметрами выгрузки, запускаемый планировщиком заданий. Для клиент-серверных — план обслуживания SQL Server или задание cron/Task Scheduler для pg_dump.

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

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

Проверка копий и восстановление

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

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

Отдельные сценарии и ограничения

Бэкап перед обновлением конфигурации

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

База в облачном сервисе 1С:Фреш

Если база работает в облачном сервисе, резервное копирование обычно выполняет оператор сервиса, но вы можете дополнительно выгружать копию базы на свой компьютер через личный кабинет сервиса. Это полезно как страховка и как способ получить локальную копию данных при отказе от сервиса.

Очень большие базы

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

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