Резервное копирование базы 1С 8: все рабочие способы

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

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

Какой способ сохранения подойдёт вашей базе

Сначала определите тип базы. Откройте окно запуска 1С: в списке баз выделите нужную и посмотрите строку под списком. Если там путь к каталогу на диске — база файловая. Если указан Srvr=...;Ref=... — база клиент-серверная, лежит в СУБД.

От этого зависит метод:

• 📁 Файловая база — выгрузка в .dt или простое копирование каталога с файлом 1Cv8.1CD.
• 🖥️ Клиент-серверная база — резервная копия средствами СУБД (PostgreSQL или MS SQL). Выгрузка в .dt тоже работает, но на больших базах идёт медленно.

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

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

Порядок действий:

1. Завершите работу всех пользователей — выгрузка требует монопольного доступа, при активных сеансах система выдаст ошибку.
2. Запустите базу в режиме Конфигуратор.
3. Меню Администрирование → Выгрузить информационную базу.
4. Укажите путь и имя файла, например base_2026-10-07.dt. Нажмите «Сохранить».
5. Дождитесь окончания — на файловой базе это занимает от секунд до нескольких минут.

Как загрузить .dt обратно. В Конфигураторе — Администрирование → Загрузить информационную базу, выберите файл. При загрузке текущая база полностью заменяется содержимым файла, поэтому загружайте либо в пустую базу, либо туда, где данные не жалко перезаписать.

Выгрузка из командной строки. Для автоматизации тот же .dt делается без открытия Конфигуратора вручную. Команда для файловой базы:

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER /F"C:\Bases\Buh" /DumpIB "D:\Backup\buh_2026-10-07.dt" /Out"D:\Backup\log.txt"

Для серверной базы вместо /F"путь" укажите /S"сервер\имя_базы", а при необходимости добавьте /N"пользователь" /P"пароль". Путь к 1cv8.exe подставьте свой — номер версии платформы смотрите в каталоге C:\Program Files\1cv8.

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

Самый быстрый способ для файловой базы — просто скопировать её каталог. Все данные лежат в одном файле 1Cv8.1CD, он и есть ваша база.

Шаги:

1. Узнайте путь к базе: окно запуска 1С → выделите базу → путь показан внизу.
2. Завершите все сеансы — копировать файл, пока с ним работают, нельзя, копия получится битой.
3. Скопируйте весь каталог базы на другой диск или в сетевую папку. Копируйте папку целиком: кроме 1Cv8.1CD там бывают служебные файлы.
4. Для восстановления — скопируйте каталог обратно (или подключите скопированную папку как новую базу в окне запуска).

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

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

Резервное копирование серверной базы на уровне СУБД

Для клиент-серверной базы правильный бэкап делает не 1С, а сама СУБД. Такая копия снимается быстрее, чем .dt, и не требует монопольного доступа в 1С.

PostgreSQL. Логическую копию снимают утилитой pg_dump. Пример для базы buh:

pg_dump -U postgres -F c -b -f /backup/buh_2026-10-07.dump buh

Флаг -F c даёт сжатый формат, который восстанавливают командой pg_restore. Имя базы в PostgreSQL совпадает с тем, что указано в строке Ref= при подключении.

MS SQL Server. Полную копию делают через SQL Server Management Studio (правый клик по базе → Tasks → Back Up) либо запросом:

BACKUP DATABASE [buh] TO DISK = N'D:\Backup\buh_2026-10-07.bak' WITH INIT, COMPRESSION;

Полная копия или с историей изменений. На рабочей базе полного ежедневного бэкапа часто мало: между ночными копиями набегают данные за целый день, и при сбое днём они теряются. Обе СУБД умеют это закрывать.

В MS SQL за это отвечает модель восстановления базы. При модели FULL помимо полной копии снимают копии журнала транзакций (BACKUP LOG) — например, раз в час. Тогда базу можно восстановить на любой момент, а не только на время ночного бэкапа. При модели SIMPLE журнал не копируется, и доступна только точка последней полной копии.

В PostgreSQL ту же задачу решает архивация WAL вместе с базовой копией (pg_basebackup). Логический pg_dump историю внутри дня не хранит, поэтому для баз, где важна каждая проводка, его дополняют физической схемой с WAL. Настройку обычно делает администратор сервера один раз.

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

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

Ручные копии забываются — поэтому бэкап ставят на автомат. Способ зависит от того, где лежит база.

🗓️ Файловая база — Планировщик заданий Windows. Создайте задание, которое ночью запускает .bat с командой DESIGNER /DumpIB из раздела про .dt выше. Один нюанс: выгрузке нужен монопольный доступ, поэтому задание ставят на время, когда в базе никто не работает.

🗓️ Встроенное резервное копирование . В типовых конфигурациях на БСП (Бухгалтерия, ЗУП, УТ) для файловой базы есть собственная настройка. Откройте базу в режиме 1С:Предприятие и зайдите в раздел Администрирование, где собраны служебные операции, — там есть настройка резервного копирования с расписанием. Она сама делает копии по графику без Конфигуратора.

🗓️ PostgreSQL — cron (Linux). Добавьте в crontab ночной запуск pg_dump. Например, строка запуска в 02:00 каждый день:

0 2 * * * pg_dump -U postgres -F c -f /backup/buh_$(date +\%F).dump buh

🗓️ MS SQL — SQL Server Agent. Создайте Maintenance Plan или job с шагом BACKUP DATABASE и назначьте расписание. Agent входит в редакции Standard и выше (в Express его нет — там выручает Планировщик Windows с запуском скрипта через sqlcmd).

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

Как убедиться, что копия рабочая

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

🔍 Файловая база — утилита chdbfl. Программа chdbfl.exe лежит в каталоге bin платформы. Она проверяет физическую целостность файла 1Cv8.1CD. Перед запуском закройте базу во всех сеансах, укажите путь к файлу и запустите проверку. Галочку «исправлять обнаруженные ошибки» ставьте только на копии, а не на единственном экземпляре базы.

🔍 Тестирование и исправление. В Конфигураторе есть Администрирование → Тестирование и исправление. Проверяет и логическую, и ссылочную целостность, работает и для файловой, и для серверной базы. Требует монопольного доступа, на большой базе идёт долго, поэтому гоняйте его по копии.

🔍 Контрольная загрузка. Самая честная проверка .dt — загрузить его в отдельную тестовую базу (Администрирование → Загрузить информационную базу) и открыть. Если база открылась и документы на месте — копия точно живая.

🔍 Серверные копии. Для PostgreSQL сделайте тестовый pg_restore в отдельную базу. Для MS SQL — RESTORE VERIFYONLY FROM DISK = ... проверит, что файл .bak читается, а периодическое DBCC CHECKDB — что в самой базе нет нарушений.

Что именно смотреть после восстановления копии на тестовом стенде:

• открывается ли база без ошибок соединения;
• на месте ли последние проведённые документы за день перед копией;
• совпадают ли контрольные суммы в стандартных отчётах (например, оборотно-сальдовая ведомость) с рабочей базой;
• проходит ли вход под реальной учётной записью, а не только под администратором.

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

Где хранить копии и как чистить старые

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

Практичная схема ротации:

• 🗄️ ежедневные копии хранить 7–14 дней;
• 🗄️ еженедельные — месяц-два;
• 🗄️ ежемесячные — год.

Старые копии нужно удалять автоматически, иначе диск быстро заполнится. На Windows это делает forfiles — например, удалить .dt старше 14 дней:

forfiles /p "D:\Backup" /m *.dt /d -14 /c "cmd /c del @path"

На Linux тот же результат даёт find:

find /backup -name "*.dump" -mtime +14 -delete

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