Резервное копирование 1С: файловая и клиент-серверная база, автоматизация и проверка

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

Файловая база

Есть три варианта, и они не равнозначны.

Выгрузка в .dt — Конфигуратор → «Администрирование → Выгрузить информационную базу». Формат платформы, переносится между файловым и клиент-серверным вариантом, сжатый. Требует монопольного доступа: все пользователи должны выйти. Это основной способ для файловой базы.

Копия каталога базы — файл 1Cv8.1CD целиком. Быстро, но копировать можно только при полностью закрытой базе: копия работающей базы почти гарантированно окажется битой. Зато восстановление мгновенное — положить файл обратно.

Штатное копирование из конфигурации — в типовых на БСП есть «Администрирование → Обслуживание → Резервное копирование», с расписанием и хранением заданного числа копий. Удобно, когда нет админа: пользователи ничего не настраивают руками. Работает только с файловым вариантом.

Клиент-серверная база

Здесь .dt — не средство резервного копирования, а средство переноса. Основной бэкап делает СУБД:

• PostgreSQL — pg_dump для логической копии базы, pg_basebackup плюс архивирование WAL, если нужна точка восстановления на момент времени.
• MS SQL Server — полная копия по расписанию, разностные в течение дня и копии журнала транзакций. Модель восстановления FULL, иначе журнал не архивируется и восстановление «на момент до ошибки» невозможно.

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

Автоматическая выгрузка .dt по расписанию

Пакетный режим конфигуратора запускается из планировщика задач Windows. Файл backup.cmd:

@echo off
set V8="C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe"
set BASE="D:\bases\unf"
set OUT=D:\backup\unf_%date:~6,4%-%date:~3,2%-%date:~0,2%.dt

%V8% CONFIG /F%BASE% /N"Архивариус" /P"пароль" /DumpIB "%OUT%" /Out"D:\backup\last.log" /DisableStartupMessages

if errorlevel 1 (
  echo ОШИБКА выгрузки >> D:\backup\errors.log
  type D:\backup\last.log >> D:\backup\errors.log
)

forfiles /p D:\backup /m *.dt /d -14 /c "cmd /c del @path"

Что здесь важно:

• пользователь «Архивариус» — отдельная учётная запись с правами администратора и без интерактивной работы;
• пароль в открытом виде в .cmd — плохо. Ограничьте доступ к файлу на уровне NTFS или используйте аутентификацию ОС;
• /DumpIB требует монопольного доступа. Если в базе кто-то есть, выгрузка не выполнится, поэтому проверка errorlevel обязательна;
• последняя строка удаляет копии старше 14 дней, иначе диск закончится в самый неподходящий момент.

Для клиент-серверной базы путь к базе задаётся иначе:

%V8% CONFIG /S"srv-1c\unf" /N"Архивариус" /P"пароль" /DumpIB "%OUT%"

Что забывают положить в бэкап

Сама база — это ещё не всё, что нужно для запуска после аварии:

• внешние отчёты, обработки и печатные формы, подключённые в базе;
• тома хранения файлов, если присоединённые файлы вынесены на диск — без них база откроется, но вложения исчезнут;
• каталоги обмена и настройки синхронизации;
• файлы публикации на веб-сервере (default.vrd) и конфигурация Apache/IIS;
• nethasp.ini и информация о лицензиях;
• список пользователей ОС, если используется аутентификация Windows.

Правило, без которого всё остальное бессмысленно

Копия, которую ни разу не разворачивали, — это не копия, а надежда. Раз в квартал:

1. возьмите свежий .dt, загрузите в отдельную тестовую базу;
2. запустите её, откройте несколько документов, постройте ОСВ;
3. запишите в журнал дату проверки и время, которое заняло восстановление.

Время восстановления — это и есть ваш реальный простой при аварии. Обычно оно оказывается втрое больше ожидаемого.

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