Как сохранить базу 1С без конфигуратора

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

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

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

Как определить тип базы и где она лежит

Прежде чем копировать, нужно понять, с какой базой вы работаете. Откройте список информационных баз в окне запуска 1С, выделите нужную базу и посмотрите строку внизу окна: если там указан путь вида D:\Bases\Trade — база файловая, если указан сервер и имя базы вида Server=SQL01;Ref=trade — клиент-серверная.

Для файловой базы вся информация находится в одном каталоге, ключевой файл — 1Cv8.1CD. Рядом могут лежать служебные файлы: 1Cv8.1CL (журнал регистрации), папки 1Cv8Log, 1Cv8tmp. Для полноценной копии достаточно файла 1Cv8.1CD, но надёжнее скопировать каталог целиком, исключив временные файлы.

Для клиент-серверной базы путь в списке баз указывает на сервер 1С и имя базы в СУБД, а не на файлы. Физические файлы данных лежат на сервере СУБД, и копировать их напрямую (файлы .mdf и .ldf у MS SQL) без остановки службы нельзя — получите повреждённую копию. Правильный путь — средства резервного копирования самой СУБД.

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

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

Проверить, свободен ли файл, можно попыткой переименовать 1Cv8.1CD: если Windows не даёт этого сделать, значит, база кем-то открыта. Также открытые сеансы видны по наличию файла 1Cv8.1CL с блокировкой и по сетевым подключениям, если база лежит в общей папке.

1. 1
   Попросите пользователей выйти из базы и завершите обмены и фоновые задания
2. 2
   Проверьте, что файл 1Cv8.1CD не занят: попробуйте его переименовать и верните имя обратно
3. 3
   Скопируйте весь каталог базы или минимум файл 1Cv8.1CD в папку резервных копий
4. 4
   Добавьте в имя папки копии дату, например Trade_backup_15-03
5. 5
   Откройте скопированную базу в режиме Предприятие и убедитесь, что данные на месте

Если база лежит на сетевом ресурсе и пользователи работают через общую папку, гарантировать завершение всех сеансов сложнее. В этом случае временно отключите общий доступ к папке или используйте теневое копирование, о котором речь ниже.

Автоматизация копирования файловой базы скриптом

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

@echo off
set SRC=D:\Bases\Trade
set DST=E:\Backup\Trade_%date:~0,2%-%date:~3,2%-%date:~6,4%
robocopy "%SRC%" "%DST%" 1Cv8.1CD /R:3 /W:10 /LOG+:E:\Backup\copy_log.txt

Перед запуском такого скрипта по расписанию нужно решить вопрос с активными сеансами: либо организационно запретить работу в часы копирования, либо добавить в скрипт завершение процессов 1cv8.exe на сервере, либо использовать теневую копию. Учтите, что принудительное завершение процессов обрывает работу пользователей и может оставить незавершённые транзакции.

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

Копирование файловой базы через теневую копию тома (VSS)

Служба теневого копирования тома (Volume Shadow Copy) позволяет снять согласованный снимок файла, даже если он открыт. Это способ сохранить базу, не выгоняя пользователей, хотя с оговоркой: платформа 1С не регистрирует себя как VSS-aware приложение, поэтому снимок фиксирует состояние файла на момент времени, но не гарантирует завершения транзакций на уровне логики 1С.

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

# Создать теневую копию диска D:
$shadow = (Get-WmiObject -List Win32_ShadowCopy).Create("D:\", "ClientAccessible")
$shadowCopy = Get-WmiObject Win32_ShadowCopy | Where-Object { $_.ID -eq $shadow.ShadowID }
$shadowPath = $shadowCopy.DeviceObject + "\"
# Скопировать файл базы из теневой копии
cmd /c copy "$($shadowPath)Bases\Trade\1Cv8.1CD" "E:\Backup\1Cv8_shadow.1CD"

Многие программы резервного копирования (Veeam Agent, системные средства архивации Windows) используют VSS автоматически. Если файловая база попадает в такой архив, у вас уже есть копия — но её всё равно нужно периодически проверять восстановлением.

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

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

MS SQL Server

В MS SQL копию создают командой BACKUP DATABASE через SQL Server Management Studio или скриптом с планировщиком. Полная модель восстановления требует также бэкапа журнала транзакций, иначе файл журнала будет бесконечно расти.

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

PostgreSQL

Для баз на PostgreSQL используют утилиту pg_dump или pg_dumpall. Дамп получается согласованным и не требует остановки сервера:

pg_dump -U postgres -Fc -f /backup/trade_$(date +%Y%m%d).dump trade

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

Выгрузка данных без конфигуратора: альтернативные варианты

Если цель — не резервная копия, а перенос данных или доступ к ним без конфигуратора, есть дополнительные варианты. В типовых конфигурациях в режиме Предприятие есть обработка «Выгрузка и загрузка данных XML» (входит в состав Библиотеки стандартных подсистем): она выгружает данные в XML-файл без конфигуратора, но требует прав администратора и работает только внутри работающей базы.

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

Ещё один вариант — пакетный запуск конфигуратора из командной строки с параметрами /DumpIB. Формально конфигуратор при этом используется, но без интерактивного открытия: команда выполняется скриптом и подходит для автоматизации, когда интерактивный вход невозможен, а платформа работоспособна.

Проверка резервной копии и частые ошибки

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

Когда без конфигуратора не обойтись и что делать при повреждении базы

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

Если база не открывается из-за повреждения, порядок действий такой: сначала копируете файл 1Cv8.1CD как есть (это страховка), затем прогоняете chdbfl.exe на второй копии, и только потом, если физическая проверка не помогла, — тестирование и исправление через конфигуратор. Каждый следующий шаг выполняется на новой копии, исходник остаётся нетронутым.

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