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

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

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

Ниже разобраны три основных метода: выгрузка в файл .dt через конфигуратор, копирование файла 1Cv8.1CD файловой базы и резервное копирование SQL-базы штатными средствами СУБД. Для каждого метода указаны условия применения, ограничения и типичные ошибки.

Какие способы резервного копирования существуют в 1С

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

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

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

Это самый универсальный метод. Откройте конфигуратор: в окне запуска 1С выберите базу и нажмите «Конфигуратор». Войдите под пользователем с правами администратора. Перед выгрузкой завершите работу всех пользователей — выгрузка требует монопольного доступа, иначе конфигуратор выдаст ошибку.

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

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

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

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

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

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

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

copy "D:\Bases\Trade\1Cv8.1CD" "E:\Backup\Trade_%date:~6,4%-%date:~3,2%-%date:~0,2%.1CD"

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

Клиент-серверную базу копируют средствами самой СУБД — это быстрее и надёжнее выгрузки в .dt, а главное, не требует отключения пользователей. В MS SQL Server резервная копия создаётся через SQL Server Management Studio: правый клик по базе → «Tasks» → «Back Up», тип «Full», указание файла назначения.

Для регулярных копий в MS SQL настраивают план обслуживания (Maintenance Plan) с ежедневным полным бэкапом и, при необходимости, копиями журнала транзакций в течение дня. В PostgreSQL используется утилита pg_dump или pg_basebackup, запускаемая по расписанию через cron или планировщик.

У метода есть ограничение: восстановить такой бэкап можно только в ту же СУБД совместимой версии. Если планируется переезд, например, с MS SQL на PostgreSQL, потребуется выгрузка в .dt.

Как организовать копирование по расписанию

Разовая копия защищает только на момент её создания. Рабочая схема — автоматическое ежедневное копирование с хранением нескольких последних копий. Минимальный практичный вариант: ежедневная копия, хранение копий за последние 7–14 дней плюс ежемесячные архивы.

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

Храните копии не на том же диске, где лежит база. Оптимально — отдельный сервер, NAS или облачное хранилище. При атаке шифровальщика копии на том же компьютере будут зашифрованы вместе с базой, поэтому важен также офлайн-носитель или хранилище, недоступное на запись с рабочих машин.

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

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

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

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

Часто задаваемые вопросы