Резервное копирование базы 1С: от файловой базы до клиент-сервера

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

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

Что проверить перед копированием

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

Главное условие надёжной копии — согласованность данных. Если в момент копирования кто-то проводит документ, в копию попадёт база «на середине» записи. Поэтому:

• 📁 Файловая база — все пользователи должны выйти, а лучше закрыть и саму платформу. Файл 1Cv8.1CD не должен быть занят процессом 1cv8.exe.
• 🖥️ Клиент-серверная база — копию снимают средствами СУБД, она умеет делать это на работающей базе без выгрузки людей. Выгрузка .dt из конфигуратора, наоборот, требует монопольного доступа.

Ещё пара моментов, из-за которых копия срывается уже на старте:

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

== Перед любым копированием убедитесь, что место назначения не на том же физическом диске, что и база. ==

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

Самый простой способ, если база лежит файлом на диске.

1. Закройте 1С у всех пользователей. Проверьте, что в каталоге базы нет признаков активного сеанса (файл блокировки 1Cv8.1CL — это журнал регистрации, он не мешает; занятость определяет сам 1cv8.exe).
2. Откройте каталог базы — путь берёте из окна запуска 1С.
3. Скопируйте файл 1Cv8.1CD. Этого файла достаточно для восстановления: в нём лежит вся база.
4. Положите копию в папку с понятным именем, например Бухгалтерия_2026-10-07.1CD, и упакуйте в архив (ZIP, 7z) — так она займёт в разы меньше места.

Чтобы восстановить такую копию, достаточно распаковать 1Cv8.1CD в пустой каталог и подключить его как новую базу в окне запуска кнопкой Добавить → Создание новой информационной базы → из существующей.

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

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

Это штатный способ платформы, и он единственный ручной, который одинаково работает и для файловой, и для серверной базы.

1. Запустите базу в режиме Конфигуратор.
2. Меню Администрирование → Выгрузить информационную базу.
3. Укажите имя и папку для файла .dt и дождитесь завершения.

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

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

Когда что выбирать:

Для типовых конфигураций (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) есть и встроенный механизм в режиме 1С:Предприятие: раздел Администрирование → Обслуживание → Резервное копирование и восстановление. По сути он делает ту же выгрузку, но из пользовательского режима и с возможностью задать расписание — об этом ниже.

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

В клиент-серверном варианте данные хранятся не файлом, а в СУБД. Скопировать папку здесь нельзя — базы как отдельного файла на диске нет. Способов два.

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

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

• PostgreSQL — утилита pg_dump делает логическую выгрузку одной базы в файл:

  pg_dump -U postgres -F c -f backup_1c.dump имя_базы
  

  Ключ -F c даёт сжатый формат, восстановление — утилитой pg_restore.
• MS SQL Server — команда BACKUP DATABASE или план обслуживания в SQL Server Management Studio:

  BACKUP DATABASE [имя_базы] TO DISK = N'D:\Backup\1c.bak' WITH COMPRESSION;
  

Копия средствами СУБД восстанавливается обратно в СУБД (pg_restore, RESTORE DATABASE), после чего база снова доступна через тот же сервер 1С. Это штатная практика для продуктивных серверов: быстрее .dt, не требует простоя и легко ставится на расписание.

Автоматическое копирование по расписанию

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

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

Скрипт для файловой базы. Для копирования файла по расписанию используют .bat-файл и Планировщик заданий Windows. Простой пример — копия файла базы с датой в имени и упаковкой архиватором 7-Zip:

@echo off
set SRC=D:\Bases\Buh\1Cv8.1CD
set DST=E:\Backup\buh_%date:~-4%-%date:~3,2%-%date:~0,2%.7z
"C:\Program Files\7-Zip\7z.exe" a "%DST%" "%SRC%"

Файл добавляют в Планировщик заданий (Создать задачу) с запуском в нерабочее время, когда база закрыта. Дата в имени архива (%date%) важна: без неё каждая новая копия затирала бы предыдущую, и вместо истории копий осталась бы одна. Отдельным заданием стоит удалять архивы старше заданного срока, иначе диск под копиями со временем заполнится.

Задание в СУБД. Для серверных баз бэкап планируют средствами самой СУБД: план обслуживания (Maintenance Plan) в MS SQL или вызов pg_dump из Планировщика заданий Windows / cron в Linux. Это самый надёжный вариант для рабочих серверов: копия снимается без простоя и по расписанию.

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

Сделать копию — половина дела. Вторая половина — чтобы она действительно восстановилась, когда понадобится.

Базовое правило хранения — три копии, на двух носителях, одна из них вне офиса (правило «3-2-1»). На практике это значит:

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

• Архив — после упаковки проверьте его тест-функцией архиватора (в 7-Zip — команда Тестировать). Если архив бьётся, копии фактически нет.
• Файл .dt — целостность проверяется только загрузкой. Раз в месяц загрузите свежий .dt в тестовую базу: если загрузка прошла и база открылась — копия рабочая.
• Бэкап СУБД — проверяется пробным восстановлением (pg_restore, RESTORE) в отдельную тестовую базу.

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

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

Частые ошибки при создании копий

Ниже — ошибки, из-за которых копия есть, а восстановиться не получается.

• ❌ Копирование файла при работающих пользователях. Файл 1Cv8.1CD копируется, но данные в нём рассогласованы. Снимайте копию только при закрытой базе.
• ❌ Хранение копии на том же диске, что и база. Диск вышел из строя — пропали и база, и копия. Копия должна жить на другом носителе.
• ❌ Единственная копия, которая перезаписывается. Ошибку в данных или шифровальщик заметят не сразу, а свежая копия уже затёрла последнюю правильную. Нужен архив за несколько дней.
• ❌ Ставка только на .dt для большой серверной базы. Выгрузка идёт долго и требует монопольного доступа — её не сделать ежедневно без простоя. Для серверных баз основной механизм — бэкап СУБД.
• ❌ Копия ни разу не проверена восстановлением. Самая опасная ошибка: о битом архиве узнают в момент аварии.
• ❌ Копирование каталога базы на сервере вместо бэкапа СУБД. В клиент-серверном варианте данные лежат в СУБД, а не файлом — копия папки бесполезна.