Вопрос создания резервных копий для файловых информационных баз 1С (формат .1cd) является критически важным для небольших организаций, где нет возможности использовать полнофункциональный SQL-сервер. Основная сложность заключается в том, что при активной работе пользователей файл базы данных постоянно открыт на запись, и обычное копирование может привести к получению битой копии. Разберем подробно, какие существуют способы решения этой задачи, проанализируем риски и выберем наиболее надежные инструменты.
Прежде чем мы перейдем к методам копирования, выясним причину, по которой «горячее» копирование считается опасным. В любой базе данных действует принцип ACID (Atomicity, Consistency, Isolation, Durability). Когда пользователь проводит документ, платформа 1С вносит изменения сразу в несколько таблиц файла 1Cv8.1cd. Если в этот момент внешняя программа начнет копировать файл, она может успеть скопировать часть обновленных данных и часть старых.
Проанализируем ситуацию: в результате такого копирования мы получим файл, который с точки зрения операционной системы выглядит нормально, но внутренняя логическая структура таблиц 1С окажется нарушена. Это может проявиться в ошибках типа «Файл базы данных поврежден» или в рассогласовании данных в отчетах. Поэтому наша задача — найти способ «заморозить» состояние файла на доли секунды, чтобы создать его точный снимок.
Рассмотрим наиболее технологичный метод для операционных систем семейства Windows — использование службы Volume Shadow Copy Service (VSS). Этот механизм позволяет создавать мгновенные снимки тома, даже если файлы на нем открыты и заблокированы приложениями. Рассмотрим, как это работает на практике.
Поскольку сама платформа 1С не имеет собственного модуля VSS Writer, служба VSS при создании снимка просто копирует файл «как есть» на конкретный момент времени. Для автоматизации этого процесса можно использовать консольные утилиты, такие как Hobocopy или встроенные средства PowerShell. Посмотрим на пример логики работы с теневыми копиями через командную строку:
# Создание символьной ссылки на теневую копию диска
vssadmin create shadow /for=D:
# Копирование файла базы из теневой копии в архивную папку
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\1C_Base\1Cv8.1cd E:\Backups\
# Удаление теневой копии после завершения операции
vssadmin delete shadows /for=D: /quiet
Выясним преимущества этого метода: мы получаем консистентный снимок на уровне файловой системы. Хотя риск незавершенной транзакции внутри бизнес-логики 1С сохраняется (согласно Сообщению 10 на форуме), вероятность повреждения структуры самого файла базы данных сводится к минимуму.
Если сервер с файловой базой работает под управлением Linux, мы можем использовать механизм LVM (Logical Volume Manager). Это, пожалуй, самый надежный способ сделать бэкап «на лету» без какого-либо влияния на пользователей. Разберем алгоритм действий:
1Cv8.1cd в хранилище бэкапов.Посмотрим на пример команд для реализации этого процесса:
# Создаем снимок объемом 1 ГБ для раздела с базой
lvcreate -L1G -s -n base_snapshot /dev/vg0/lv_data
# Монтируем снимок
mount /dev/vg0/base_snapshot /mnt/backup_source
# Копируем файл
cp /mnt/backup_source/1c_base/1Cv8.1cd /mnt/backup_storage/backup_$(date +%F).1cd
# Очищаем за собой
umount /mnt/backup_source
lvremove -f /dev/vg0/base_snapshot
Этот метод хорош тем, что для приложений (включая 1С) операция создания снимка проходит абсолютно незаметно и занимает миллисекунды.
Как отмечалось в Сообщении 2 и Сообщении 8, технически Windows позволяет просто скопировать файл 1Cv8.1cd через Проводник или команду copy, даже если база открыта. Однако, проанализируем последствия такого подхода. Если в базе работает несколько человек (как указано в Сообщении 4), риск получить нерабочую копию крайне высок.
Важный нюанс: при прямом копировании в бэкап неизбежно попадает файл блокировок 1Cv8.cfl. Если вы восстановите базу из такой копии, платформа 1С может ошибочно считать, что база заблокирована или сеанс аварийно завершен. Рекомендуем при восстановлении из «горячих» копий всегда удалять все файлы в папке, кроме основного 1Cv8.1cd.
Как предложил автор темы в Сообщении 0, использование механизма РИБ позволяет иметь вторую идентичную базу, которая синхронизируется с основной. Рассмотрим этот сценарий подробнее:
Мы создаем «периферийную» базу в том же расположении или на другом сервере. Настраиваем автоматический обмен данными (например, раз в час). Бэкапы в этом случае снимаются уже с периферийной базы, в которой в момент копирования нет активных пользователей. Это гарантирует 100% консистентность данных.
Однако, проанализируем минусы этого решения:
Существуют программные продукты, которые автоматизируют вышеописанные процессы и добавляют свои алгоритмы проверки. Разберем по шагам, что обычно делают такие программы (например, Effector Saver):
Flush для сброса буферов файловой системы на диск.chdbfl.exe.Применение таких инструментов — отличный компромисс между бесплатными скриптами и ручным копированием.
Если вам все же пришлось воспользоваться простым копированием без VSS или LVM, обязательно выполните проверку полученного файла. Для этого в платформе 1С предусмотрена утилита chdbfl.exe (находится в папке bin установленной платформы).
Выясним алгоритм проверки:
1. Запустите chdbfl.exe.
2. Выберите файл бэкапа.
3. Установите флаг «Исправлять обнаруженные ошибки».
4. Нажмите «Выполнить».
Только после успешного прохождения этой проверки можно считать, что резервная копия пригодна для использования. Если утилита находит множество ошибок, которые не удается исправить, значит, копирование произошло в момент интенсивной записи данных, и такой бэкап бесполезен.
Подведем итог: для обеспечения максимальной надежности в Windows используйте инструменты на базе VSS, в Linux — LVM снимки. Избегайте простого копирования через Проводник в многопользовательском режиме, так как это не дает никаких гарантий сохранности ваших данных.