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

Самый надёжный ручной способ — выгрузить базу в файл .dt: в Конфигураторе Администрирование → Выгрузить информационную базу. Для файловой базы можно просто скопировать файл 1Cv8.1CD, но только когда из базы вышли все пользователи. Для серверной базы на SQL правильнее делать резервную копию средствами самого SQL Server.

Разберём все три способа — ручную выгрузку, копирование файлов и автоматический скрипт по расписанию, — а в конце покажу, как из такой копии восстановить базу 1С обратно. Платформа — 8.3 с интерфейсом «Такси».

Резервное копирование 1С спасает не только от сбоя диска. Чаще его поднимают после неудачного обновления, случайного группового перепроведения или когда база «разъехалась» после правок — и откатиться можно только на вчерашнюю копию.

Почему копировать папку базы на ходу нельзя

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

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

С серверной базой ещё строже. Данные лежат в СУБД (MS SQL или PostgreSQL), а не в файле, который видно в проводнике. Копировать файлы .mdf/.ldf работающего SQL Server бесполезно — они заблокированы службой, и копия будет нерабочей.

Три способа сделать резервную копию базы 1С

Выбор зависит от того, файловая у вас база или серверная, и нужна ли копия руками или по расписанию.

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

Копия 1Cv8.1CD делается за секунды, но подходит только для файлового режима и тоже требует, чтобы все вышли.

Резервная копия средствами SQL снимается без остановки работы и на большой базе кратно быстрее .dt. Это основной способ для серверных баз.

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

Это универсальный способ: работает и для файловой, и для серверной базы.

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

Готовый .dt сразу переносите на другой диск или в облако — копия, лежащая на том же диске, что и база, не защищает от отказа этого диска.

Пакетный запуск выгрузки

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

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER /F "C:\bases\Buh" /N "Администратор" /P "пароль" /DumpIB "D:\backup\base_%date%.dt"

Для серверной базы вместо /F указывается /S "сервер\имя_базы". Путь к 1cv8.exe подставьте свой — номер версии платформы в пути свой у каждого. Этот вызов и используется в автоматизации ниже.

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

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

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

Для копирования по скрипту удобнее robocopy: он копирует только изменившееся и умеет логировать.

robocopy "C:\bases\Buh" "D:\backup\Buh_2026-10-07" /E /R:2 /W:5

Серверную базу файлами не копируют. Резервную копию снимают средствами СУБД:

• MS SQL Server — план обслуживания (Maintenance Plan) с задачей Backup Database, либо команда BACKUP DATABASE по расписанию SQL Agent. Копия снимается на работающей базе, пользователей выгонять не нужно.
• PostgreSQL — утилита pg_dump (или pg_basebackup для бинарной копии кластера) по расписанию.

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

Автоматизация резервного копирования по расписанию

Руками делать копии каждый день никто не будет — настройте автоматический бэкап. Для файловой базы это связка: пакетный скрипт + Планировщик заданий Windows.

Скрипт делает три вещи: снимает копию, кладёт её с датой в имени и удаляет старые.

@echo off
set DEST=D:\backup
set STAMP=%date:~6,4%-%date:~3,2%-%date:~0,2%

rem 1. Выгрузка базы в .dt
"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER /F "C:\bases\Buh" /N "Администратор" /P "пароль" /DumpIB "%DEST%\base_%STAMP%.dt"

rem 2. Удаление копий старше 30 дней
forfiles /p "%DEST%" /m *.dt /d -30 /c "cmd /c del @path"

rem 3. Запись отметки в лог
echo %STAMP% backup done >> "%DEST%\backup.log"

Разберём по шагам, что здесь происходит.

Снимаем копию. Пакетный вызов 1cv8.exe … /DumpIB создаёт .dt с датой в имени. Для серверной базы, напомню, вместо выгрузки лучше поставить задачу резервного копирования в самой СУБД, а этот скрипт оставить для файловой.

Удаляем копии старше 30 дней. Команда forfiles с ключом /d -30 отбирает файлы .dt старше 30 дней и удаляет их. Иначе за полгода диск под бэкапами забьётся. Срок хранения подставьте свой.

Ставим на расписание. Откройте Планировщик заданий Windows (Пуск → Средства администрирования), создайте задачу, укажите запуск .bat-файла и время — например, 23:00, когда в базе никого нет. Поставьте галочку «Выполнять с наивысшими правами» и укажите учётную запись, у которой есть доступ к каталогам базы и бэкапа.

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

Пара практических деталей. Задачу запускайте от учётной записи, у которой есть права и на каталог базы, и на каталог бэкапа — если компьютер в домене, это чаще отдельная служебная учётка, а не ваша личная. А если сервер на ночь выключают, поставьте в свойствах задачи галочку «Запускать задачу как можно скорее после пропуска запланированного запуска» — иначе в дни простоя копия не создастся совсем. Строка в backup.log после каждого запуска помогает быстро увидеть, в какую ночь бэкап не отработал.

Облачное и внешнее хранение: плюсы и риски

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

Варианты:

• 🗄️ Второй физический диск или NAS — простейшая защита от отказа основного диска.
• ☁️ Облачное хранилище (Яндекс Диск, облачные диски хостеров, S3-совместимые) — копия уезжает за пределы офиса автоматически.
• 💽 Съёмный диск, который увозят домой — дёшево, но зависит от дисциплины.

Риски облака, о которых стоит помнить:

• данные базы уходят к стороннему провайдеру — для бухгалтерии это чувствительно, выбирайте хранилище с шифрованием;
• восстановление зависит от скорости интернета: большой .dt будет качаться обратно не минуты, а часы;
• если доступ к облаку завязан на один аккаунт, его потеря = потеря бэкапов.

Восстановление базы 1С из резервной копии

Как восстановить базу, зависит от того, в каком виде лежит копия.

Из файла .dt:

1. Создайте в списке баз пустую базу (или используйте существующую, но помните — её содержимое затрётся).
2. Войдите в неё через Конфигуратор.
3. Меню — Администрирование → Загрузить информационную базу и выберите нужный .dt.
4. Подтвердите замену. Платформа предупредит, что текущая база будет перезаписана.

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

Из копии файла 1Cv8.1CD: просто подключите каталог с восстановленным файлом как новую базу в списке (Добавить → Добавление в список существующей и путь к папке). Рабочий файл заменять на копию можно только когда из базы все вышли.

Из копии СУБД: восстановление делает администратор средствами SQL Server или PostgreSQL (RESTORE DATABASE / pg_restore), после чего база снова доступна через ту же строку подключения.

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

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

Типичные ошибки при резервном копировании

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

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