Как бэкапить базу 1С: пошаговое руководство для файловых и клиент-серверных баз

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

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

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

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

Прежде чем настраивать копирование, выясните, где физически лежат данные. Откройте в конфигураторе меню «Администрирование» → «Информационная база» или посмотрите строку подключения в списке баз стартера 1С. Если путь выглядит как папка на диске или сетевом ресурсе (например, D:\Bases\Trade или \\Server\Bases\Trade), база файловая. Если указан сервер 1С и имя базы в кластере — клиент-серверная.

Файловый режим типичен для небольших баз с несколькими пользователями. Клиент-серверный используется при большом объёме данных и десятках одновременных сеансов. От режима зависит всё: инструменты копирования, необходимость останавливать работу пользователей и способ восстановления.

Промежуточный вариант — файловая база, опубликованная на веб-сервере. Физически это тот же файл .1CD, поэтому бэкапится она как файловая, но перед копированием нужно убедиться, что все сеансы завершены.

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

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

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

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

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

Способ 2. Копирование файловой базы 1Cv8.1CD

Файловая база целиком находится в файле 1Cv8.1CD внутри каталога базы. Чтобы сделать копию, достаточно скопировать этот файл в другое место. Это самый быстрый способ для файловых баз: копирование идёт со скоростью дисковой системы, без нагрузки на механизмы 1С.

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

Копию удобно делать ночью по расписанию простым скриптом. Например, командный файл с xcopy или robocopy, запускаемый планировщиком заданий Windows, копирует файл в папку с датой в имени. Храните несколько поколений копий — минимум недельную глубину, чтобы можно было откатиться не только на вчерашний день.

robocopy "D:\Bases\Trade" "E:\Backup\Trade_%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%" 1Cv8.1CD /R:2 /W:5

Способ 3. Бэкап клиент-серверной базы средствами СУБД

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

На MS SQL Server настройте план обслуживания: полная копия ежедневно, при интенсивной работе — дифференциальные копии в течение дня. Команда для полного бэкапа выглядит так:

BACKUP DATABASE [TradeBase] TO DISK = N'E:\Backup\TradeBase_full.bak' WITH COMPRESSION, CHECKSUM

На PostgreSQL используйте pg_dump или pg_basebackup. Важно: модель восстановления базы в MS SQL влияет на рост журнала транзакций. При полной модели (Full) журнал нужно регулярно бэкапить и усекать, иначе он разрастётся и заполнит диск. Для баз 1С часто выбирают простую модель (Simple), если достаточно ежедневных копий.

Не копируйте файлы данных СУБД (mdf/ldf или каталог data PostgreSQL) простым файловым копированием при работающем сервере — получите несогласованные файлы. Только штатные средства: BACKUP DATABASE, pg_dump, либо остановка службы СУБД перед копированием.

Автоматизация: расписание, хранение и правило 3-2-1

Ручной бэкап рано или поздно забывают сделать. Настройте автоматику: планировщик заданий Windows для скриптов копирования файловых баз, план обслуживания или скрипт sqlcmd для MS SQL, cron для pg_dump на Linux. Для выгрузки .dt по расписанию используйте запуск конфигуратора в пакетном режиме с параметрами /DumpIB и /DumpResult.

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

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

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

Бэкап, который ни разу не восстанавливали, нельзя считать рабочим. Раз в месяц или после изменения схемы резервирования выполняйте тестовое восстановление: загрузите .dt в пустую базу, подключите копию .1CD как новую базу в списке или разверните bak-файл на тестовом SQL-сервере. Откройте базу, запустите несколько отчётов, сверьте итоги с рабочей системой.

При восстановлении файловой базы из копии файла просто подмените 1Cv8.1CD в каталоге базы, предварительно сохранив текущий файл. При загрузке .dt помните: загрузка полностью замещает данные существующей базы. Восстановление бэкапа СУБД выполняется командой RESTORE DATABASE или pg_restore в новую базу, после чего её подключают в консоли кластера 1С.

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

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

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

Третья группа ошибок связана с отсутствием контроля: планировщик отключился после обновления Windows, диск для бэкапов переполнился, пароль учётной записи скрипта истёк. Копирование молча перестаёт работать, и обнаруживается это спустя месяцы. Регулярный просмотр журналов и тестовые восстановления закрывают этот риск.

Отдельно отметим: бэкап не заменяет контроль целостности базы. Если база повреждена, а копирование работает, вы аккуратно бэкапите повреждённую базу. При подозрениях на ошибки прогоните «Тестирование и исправление» в конфигураторе (только с предварительной копией) и убедитесь, что восстановление берёт копию до момента повреждения.

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