Вложения в 1С: когда держать их в базе, когда выносить на диск
Содержание
Для небольшой базы, где вложений до нескольких гигабайт, файлы лучше хранить прямо в информационной базе. Когда сканы, договоры и фото начинают занимать десятки гигабайт, их выносят в тома хранения файлов на сетевом диске, а при тысячах документов в день с согласованиями и версиями подключают отдельную ECM-систему. Частое заблуждение: «в базе хранить нельзя, это всегда тормозит». Тормозит не само хранение в базе, а разросшаяся база, которую долго копировать, тестировать и восстанавливать.
Выбор места хранения файлов в 1С — это компромисс между простотой резервного копирования и размером базы. Ниже по каждому варианту: как он устроен, где включается, чем грозит и как его обслуживать.
Три способа хранения файлов в 1С и быстрый выбор
В типовых конфигурациях на Библиотеке стандартных подсистем (Бухгалтерия 3.0, ЗУП 3.1, УТ 11, Документооборот, ERP) работу с вложениями ведёт подсистема «Работа с файлами». Она умеет класть файл в одно из двух мест: в саму базу или в том на диске. Третий путь — внешнее хранилище через интеграцию.
| Вариант | Где лежит файл | Когда подходит | Главный риск |
|---|---|---|---|
| 🗄️ В информационной базе | В таблицах базы (для файлового варианта — внутри 1Cv8.1CD, для клиент-серверного — в СУБД) | До 5–10 ГБ вложений, мало пользователей, нет администратора | Рост базы и резервных копий |
| 📁 В томах на диске | В папке на диске или сетевом ресурсе, в базе — только ссылка и описание | Десятки и сотни гигабайт сканов, клиент-серверная база | Копия базы и папки расходится |
| 🌐 Во внешней ECM | В системе документооборота или хранилище контента | Тысячи документов в день, версии, согласования, юридически значимый архив | Стоимость и сложность интеграции |
Есть и четвёртый, «самодельный» вариант — хранить в реквизите только путь к файлу на общем диске. Он кажется простым, но ломается при первом переименовании папки или переезде сервера. Для учёта такой способ не подходит.
Хранение файлов внутри информационной базы
Это режим по умолчанию. Пользователь прикрепляет скан к документу, и двоичные данные файла записываются в таблицу базы. Вместе с ними хранится карточка: имя, расширение, размер, автор, версии.
Плюсы такого хранения:
- ✅ Одна копия — всё сохранено. Выгрузка
.dtили бэкап СУБД содержит и данные учёта, и вложения. - ✅ Транзакционность. Файл и документ записываются согласованно: нет «висячих» ссылок на удалённый файл.
- ✅ Права из коробки. Кто видит документ, тот видит его вложения, без настройки прав на папки.
- ✅ Ничего не нужно настраивать на сервере и в сети.
Минусы проявляются с ростом объёма:
- ⚠️ База растёт быстрее, чем учётные данные. 200 сканов в день по 500 КБ — это около 100 МБ в день, примерно 25 ГБ за год при 250 рабочих днях.
- ⚠️ Выгрузка и загрузка
.dt, тестирование и исправление, обновление конфигурации с реструктуризацией идут дольше. - ⚠️ Каждая ночная копия заново содержит все гигабайты вложений, даже если за день добавили пару файлов.
Как хранить файл в базе в своей доработке
Если вы пишете свой справочник или регистр с вложением, используйте реквизит типа ХранилищеЗначения и включайте сжатие:
// Запись файла в реквизит типа ХранилищеЗначения со сжатием
ДвоичныеДанные = Новый ДвоичныеДанные(ПолноеИмяФайла);
Объект.Файл = Новый ХранилищеЗначения(ДвоичныеДанные, Новый СжатиеДанных(9));
// Получение файла обратно и запись на диск
ДанныеФайла = Объект.Файл.Получить();
Если ДанныеФайла <> Неопределено Тогда
ДанныеФайла.Записать(ИмяФайлаДляСохранения);
КонецЕсли;
Сжатие хорошо работает на документах Word, XML и текстах. PDF, JPEG и архивы уже сжаты — на них выигрыш близок к нулю, а время записи растёт.
Ещё одно правило для доработок: не храните вложение в реквизите самого документа или справочника, который часто читают в списках. Выносите двоичные данные в отдельный объект — регистр сведений или подчинённый справочник. Иначе при открытии формы или обходе выборки платформа может тянуть лишние мегабайты.
Тома хранения файлов на диске сервера
Том — это описание папки, куда подсистема «Работа с файлами» складывает вложения. В базе остаётся карточка файла и ссылка на его положение в томе. Сам файл лежит на диске в подкаталогах, имя часто отличается от исходного.
Как включить хранение в томах
В типовых конфигурациях на БСП настройка находится в разделе Администрирование → Общие настройки, в группе, посвящённой работе с файлами (название группы может немного отличаться от релиза к релизу). Порядок:
- Включите вариант хранения файлов в томах на диске. В свежих версиях подсистемы можно выбрать смешанный режим: часть файлов в базе, часть в томах.
- Откройте список томов хранения файлов и создайте том.
- Укажите полный путь к папке для Windows и, если сервер 1С работает на Linux, для Linux.
- Задайте максимальный размер тома. Когда он заполнится, файлы пойдут в следующий том по порядку заполнения.
- Сохраните том и прикрепите тестовый файл к любому документу. Проверьте, что он появился в папке.
Какой путь указывать
В клиент-серверном варианте файл в том записывает рабочий процесс сервера 1С, а не компьютер пользователя. Поэтому:
- 📌 путь указывайте в формате UNC:
\\fileserver\1c_volumes\buh\, а не буквой дискаZ:\; - 📌 права на запись в эту папку нужны учётной записи, от которой запущена служба сервера 1С (по умолчанию
USR1CV8, если при установке не выбрали другую); - 📌 если в кластере несколько рабочих серверов, папка должна быть доступна с каждого из них по одному и тому же пути.
В файловом варианте базы запись идёт от имени пользователя, который работает в программе. Значит, каждому пользователю понадобятся права на папку тома. Это одна из причин, почему тома удобнее именно в клиент-серверной базе.
Не указывайте в томе папку, в которую пользователи ходят через проводник. Ручное переименование или удаление файла в томе не попадает в базу: карточка останется, а открыть файл будет нельзя.
Внешние ECM-системы и хранилища документов
ECM (системы управления корпоративным контентом) берут на себя то, что учётной базе не свойственно: версии, маршруты согласования, сроки хранения, полнотекстовый поиск по архиву, разграничение доступа по делам и папкам.
Типичные сценарии интеграции:
- 🔗 1С:Документооборот рядом с учётной базой. Бухгалтерия хранит у себя ссылку на документ, а сканы, версии и визы живут в Документообороте. Он сам хранит файлы в базе или томах, но нагрузка уходит из учётной базы.
- 🔗 Сторонняя ECM по протоколу CMIS или REST API. Из 1С файл отправляют HTTP-запросом и сохраняют в учётной базе только идентификатор объекта в ECM. Такая интеграция пишется программистом: типовых настроек под конкретную внешнюю систему в учётных конфигурациях обычно нет.
- 🔗 Архив электронных документов ЭДО. Входящие и исходящие пакеты оператор ЭДО хранит у себя, учётная база держит их копии для работы. Оригинал с подписями при этом остаётся у оператора.
Когда ECM оправдана:
| Признак | Достаточно томов | Нужна ECM |
|---|---|---|
| Объём вложений | До сотен гигабайт | Терабайты |
| Версии файла | Несколько, редко | Постоянно, с историей правок |
| Согласование | Не нужно или в 1С | Маршруты, визы, сроки |
| Кто работает с файлами | Пользователи учётной базы | Весь офис, включая тех, у кого нет 1С |
Перед интеграцией определите, где «главная» копия файла. Если файл можно изменить и в 1С, и в ECM, через полгода у вас будут две разные версии договора.
Производительность и нагрузка на сеть при работе с вложениями
Место хранения влияет на три вещи: размер базы, время резервного копирования и путь, по которому файл идёт к пользователю.
Путь файла до пользователя
При хранении в базе файл идёт из СУБД через сервер 1С на клиент. При хранении в томе сервер 1С читает файл с сетевого ресурса и тоже отдаёт его клиенту. Пользователь напрямую к папке тома не обращается. Отсюда два практических вывода:
- Файловый сервер с томами ставьте в той же сети, что и сервер 1С, с хорошим каналом между ними. Медленный канал «сервер 1С — хранилище» замедлит открытие каждого скана.
- Удалённым пользователям через интернет вариант хранения почти не помогает: файл всё равно передаётся по их каналу. Помогает ограничение размера и сжатие сканов.
Что реально снижает нагрузку
- 📉 Ограничение размера файла. В настройках подсистемы файлов задаётся максимальный размер вложения. Значение 20–50 МБ отсекает случайные видео и многостраничные цветные сканы.
- 📉 Запрет расширений. В тех же настройках есть список запрещённых расширений. Добавьте туда исполняемые файлы (
exe,bat,cmd,js,vbs) — это и безопасность, и меньше мусора. - 📉 Настройка сканера. Чёрно-белый скан первички в 200–300 dpi в PDF весит 50–150 КБ на страницу. Цветной в 600 dpi — в десятки раз больше. Настройка сканера экономит больше, чем любая настройка 1С.
| Параметр | В базе | В томах |
|---|---|---|
| Размер базы | Растёт вместе с вложениями | Растут только карточки |
Время выгрузки .dt | Увеличивается | Почти не меняется |
| Резервное копирование | Одна операция | Две согласованные операции |
| Тестирование и исправление | Дольше | Быстрее |
| Настройка | Не нужна | Сетевой ресурс, права службы |
Права доступа к файлам и безопасность хранилища
Внутри 1С права на вложения в типовых конфигурациях следуют правам на объект-владелец. Видит пользователь документ — видит и прикреплённые к нему файлы. Если включено ограничение доступа на уровне записей, оно действует и на вложения.
С томами появляется второй уровень — права на папку в файловой системе. Здесь задача обратная: дать доступ только тому, кому нужно.
Рекомендованная схема прав на папку тома:
- Учётная запись службы сервера 1С — полный доступ (чтение, запись, удаление).
- Администраторы, которые делают резервные копии, — чтение, либо доступ только у учётной записи службы резервного копирования.
- Обычные пользователи домена — никакого доступа. Иначе любой сотрудник откроет зарплатные ведомости и паспорта из папки напрямую, минуя права 1С.
Отдельно о персональных данных. Сканы паспортов, СНИЛС, трудовых договоров — это персональные данные. При хранении в томах папка должна быть защищена не хуже, чем сама база: с ограничением доступа, журналированием и шифрованием диска, если сервер стоит вне защищённого помещения.
Антивирус на файловом сервере может блокировать или помещать в карантин файлы из тома. Для 1С это выглядит как пропавший файл. Если антивирусная проверка нужна, сканируйте файлы при загрузке, а действие «удалить» замените на уведомление администратора.
Обслуживание томов: перенос, проверка, резервные копии
Тома требуют регулярного обслуживания. Без него через год появляются файлы без карточек и карточки без файлов.
Резервное копирование базы и тома
Главное правило — копировать базу и том в одно и то же окно времени. Если копия базы сделана в 01:00, а копия папки в 03:00, при восстановлении в томе окажутся файлы, о которых база не знает. Это не страшно. Хуже обратная ситуация: копия папки старше базы. Тогда часть карточек будет ссылаться на отсутствующие файлы.
Рабочая схема:
- Ночью копируется база (бэкап СУБД или выгрузка
.dt). - Сразу после неё — инкрементная копия папки тома. Файлы в томе не изменяются после записи, поэтому инкремент маленький.
- Раз в месяц делается контрольное восстановление на тестовый сервер: база плюс том, открытие нескольких случайных вложений.
Выгрузка .dt содержит только данные базы. Файлы из томов в неё не попадают. Перенос базы на другой сервер через .dt без копирования папки томов оставит вас без вложений.
Перенос файлов между базой и томами
Когда переходите на тома в работающей базе, новые файлы сразу начнут записываться в том, а старые останутся в базе. Для переноса уже накопленных файлов в подсистеме есть штатная обработка переноса файлов между местами хранения. Найти её проще всего поиском по слову «перенос» в разделе Администрирование.
Перед переносом:
- 🔸 сделайте полную копию базы ;
- 🔸 запускайте перенос вечером или в выходной: операция долгая и нагружает сервер, пользователи будут работать медленнее;
- 🔸 после переноса освободившееся место в СУБД вернётся не сразу — для файлового варианта поможет сжатие таблиц при тестировании и исправлении, для MS SQL — сжатие файла базы средствами СУБД.
Проверка целостности тома
В карточке тома есть команда проверки целостности. Она сравнивает карточки файлов в базе с реальным содержимым папки и показывает:
- файлы, которые есть в папке, но не известны базе (обычно остаются после сбоев записи или восстановления из разных копий);
- карточки, файлы которых в папке не найдены;
- файлы с другим размером или контрольной суммой.
Запускайте проверку раз в квартал и после любого восстановления из резервной копии.