При работе с крупными информационными базами 1С администраторы часто приходят к решению выносить присоединенные файлы (сканы документов, изображения, отчеты) из самой базы данных на жесткий диск. Это позволяет существенно уменьшить размер базы и ускорить ее работу. Однако возникает закономерный вопрос: как ведет себя стандартный механизм выгрузки конфигурации и данных в файл .dt в таком случае? Попадают ли внешние файлы в этот архив?
Рассмотрим этот вопрос подробно, проанализируем технические нюансы работы платформы 1С и определим правильную стратегию резервного копирования для систем, использующих внешние тома.
Для начала разберем природу формата .dt. Выгрузка в этот формат представляет собой логический дамп всех данных, которые физически находятся внутри таблиц базы данных — будь то файловая версия (1Cv8.1CD) или клиент-серверный вариант под управлением СУБД (MS SQL, PostgreSQL и др.).
Когда в настройках программы включен механизм «Тома хранения файлов», физические двоичные данные файлов перемещаются из таблиц базы данных в обычные папки на диске или сетевом ресурсе. В самой информационной базе при этом остаются только записи в справочнике ПрисоединенныеФайлы (или аналогичном), содержащие метаданные и ссылку (путь) на файл во внешнем хранилище. Поскольку платформа при создании .dt оперирует только содержимым таблиц, внешние объекты, на которые ссылается база, просто игнорируются. Таким образом, ваш .dt файл будет содержать информацию о том, что файл существует, но самого «тела» файла в архиве не будет.
Рассмотрим ситуацию, когда необходимо перенести базу на другой сервер или восстановить ее из копии. Если вы восстановите базу только из .dt, вы получите полностью работоспособную конфигурацию и все учетные данные. Однако при первой же попытке пользователя открыть скан-копию договора или любой другой прикрепленный файл, система выдаст критическую ошибку «Файл не обнаружен».
Это происходит потому, что база ищет файл по старому пути, который был прописан в настройках томов на исходном сервере. Для корректной работы необходимо не только развернуть .dt, но и вручную скопировать все папки с томами на новый сервер, соблюдая структуру вложенности.
Одной из самых серьезных опасностей раздельного хранения является рассинхронизация (разрыв во времени) между бэкапом базы и бэкапом томов. Проанализируем типичный сценарий:
.dt.В итоге мы получаем ситуацию, когда в томах есть файлы, о которых база из 12-часовой выгрузки еще «ничего не знает». Еще хуже обратная ситуация: если восстановить старую базу, она может ссылаться на файлы, которые уже были удалены или перемещены в процессе очистки томов. Именно поэтому крайне важно фиксировать состояние базы и файлов на один и тот же момент времени.
Выясним, что нужно сделать сразу после того, как база была развернута из .dt на новом оборудовании. Поскольку пути к томам хранятся внутри базы как строковые значения (например, \\Server-Old\1C_Files), они останутся старыми. Если на новом сервере структура дисков или сетевое имя изменились, вам необходимо выполнить следующие шаги:
Для систем, использующих тома, выгрузки в .dt категорически недостаточно для обеспечения отказоустойчивости. Мы рекомендуем использовать комбинированный подход:
.bak в MS SQL). Это быстрее и надежнее, чем .dt.При переносе томов на новый диск важно не забыть о правах доступа на уровне операционной системы. Посмотрим, кто должен иметь доступ к папкам:
Пользователь, под которым запущен процесс rphost сервера 1С (обычно это системная учетная запись USR1CV8), должен обладать правами «Полный контроль» (чтение, запись, изменение) на все папки, используемые как тома. Если права настроены некорректно, пользователи смогут видеть список файлов в программе, но не смогут их открывать или добавлять новые.
В типовых конфигурациях 1С, построенных на базе Библиотеки Стандартных Подсистем (БСП), предусмотрен мощный инструмент — отчет «Проверка целостности томов». Рассмотрим, как он работает:
После любого восстановления из копии или переноса данных обязательно запустите эту проверку. Программа проанализирует соответствие записей в базе данных и физических файлов на диске. Отчет покажет две группы ошибок:
Своевременная проверка позволит избежать накопления «мусора» и вовремя обнаружить потерю важных данных.