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

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

Критично различать два понятия: выгрузка базы в файл .dt через конфигуратор и полноценный бэкап средствами СУБД. Первый способ универсален и прост, второй — быстрее, лучше подходит для больших баз и позволяет настроить регулярное расписание. В большинстве компаний используют оба подхода одновременно.

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

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

Способ резервного копирования полностью определяется типом базы. Файловая база — это один файл 1Cv8.1CD в каталоге на диске или сетевом ресурсе. Клиент-серверная база хранится в СУБД (MS SQL Server, PostgreSQL, IBM Db2, Oracle), а каталог на диске содержит только служебные файлы, копирование которых бесполезно.

Узнать режим можно в конфигураторе: меню «Администрирование» → «Сведения об информационной базе», либо в списке баз при запуске 1С — там указан путь к каталогу либо имя сервера и кластера. Если в строке подключения есть имя SQL-сервера, база клиент-серверная.

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

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

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

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

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

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

Учтите: выгрузка .dt не является транзакционно-консистентной копией в строгом смысле, если в базе во время выгрузки есть активность. Именно поэтому завершение сеансов обязательно. Также файл .dt нельзя «приоткрыть» и посмотреть — только загрузить целиком в пустую базу.

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

Файловую базу можно скопировать как обычный файл. Достаточно скопировать 1Cv8.1CD из каталога базы в другое место — это полноценная копия. Остальные файлы каталога (журналы, индексы полнотекстового поиска) для восстановления не нужны.

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

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

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

Для баз на MS SQL Server используйте штатные механизмы СУБД: полный бэкап (FULL) через SQL Server Management Studio или агент SQL Server с расписанием. Правой кнопкой по базе → «Tasks» → «Back Up», тип — Full, затем укажите целевой файл .bak.

Для PostgreSQL применяйте утилиту pg_dump или pg_dumpall, запуская её по расписанию через cron или планировщик. Бэкап средствами СУБД выполняется «на горячую», без остановки работы пользователей, и гарантирует согласованность данных на момент снятия копии.

BACKUP DATABASE [BuhBase] TO DISK = N'D:\Backup\BuhBase_full.bak' WITH COMPRESSION, CHECKSUM;

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

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

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

Храните копии по правилу ротации: несколько последних ежедневных копий, несколько еженедельных и хотя бы одну месячную. Так вы сможете откатиться не только на «вчера», но и на состояние до ошибки, которую заметили спустя недели.

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

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

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

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

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