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

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

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

Ниже разобраны оба сценария — файловый и клиент-серверный, а также автоматизация копирования, правила хранения и проверка того, что копия действительно восстанавливается.

Определите режим работы базы: файловый или клиент-серверный

От режима работы зависит вся процедура. Откройте список информационных баз в окне запуска 1С: в строке подключения файловая база указывается путём к каталогу (например, File="D:\Bases\Trade"), а клиент-серверная — через сервер 1С и кластер (Srvr="server1c";Ref="trade").

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

Если база опубликована на веб-сервере или используется через тонкий клиент, это не меняет физический формат хранения: смотрите именно на строку подключения в списке баз.

Резервная копия файловой базы через конфигуратор

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

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

Имя файла удобно формировать с датой, например trade_2026-05-14.dt, — тогда копии не перезаписывают друг друга и легко понять, какая из них свежая.

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

Копирование файла 1Cv8.1CD напрямую

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

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

Резервная копия клиент-серверной базы через СУБД

Для баз на MS SQL Server, PostgreSQL или другой СУБД выгрузка в .dt тоже возможна, но для больших баз она медленная и создаёт нагрузку. Основной механизм — штатное резервное копирование самой СУБД.

В MS SQL Server копию делают через SQL Server Management Studio: правый клик по базе → «Tasks» → «Back Up», тип «Full», указание файла назначения. Такой бэкап выполняется «на горячую», без остановки работы пользователей, и занимает заметно меньше времени, чем выгрузка в .dt.

Для PostgreSQL используется утилита pg_dump или pg_basebackup в зависимости от задач. Важно: копируется база данных в СУБД, а не каталог на сервере 1С — последний не содержит данных.

BACKUP DATABASE [trade] TO DISK = N'D:\Backups\trade_full.bak' WITH COMPRESSION, CHECKSUM;

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

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

Ручное копирование рано или поздно забывается, поэтому резервные копии должны создаваться по расписанию. Для файловых баз используют планировщик заданий Windows и командный файл, который копирует 1Cv8.1CD в каталог с датой в имени.

Для выгрузки в .dt из командной строки конфигуратор поддерживает пакетный режим с параметром /DumpIB, что позволяет запускать выгрузку по расписанию. Учётная запись, от имени которой выполняется задание, должна иметь право запуска 1С и доступ к каталогу назначения.

Для MS SQL Server расписание настраивается через планы обслуживания (Maintenance Plans) или задания агента SQL Server. Распространённая схема — полная копия ежедневно ночью и копии журнала транзакций в течение дня, если база работает в полной модели восстановления.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Администратор" /P"пароль" /DumpIB"E:\Backup\trade_%date%.dt" /DisableStartupDialogs

Правила хранения копий и защита от типовых угроз

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

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

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

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

Единственный способ убедиться, что копия рабочая, — восстановить её. Периодически (хотя бы раз в месяц и обязательно после изменения схемы копирования) разворачивайте копию на тестовом компьютере: файл .dt загружается через «Администрирование» → «Загрузить информационную базу», бэкап SQL Server — через Restore Database.

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

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

Типичные ошибки при организации резервного копирования

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

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

Частые вопросы о резервном копировании 1С