Страховое агентство: фотофиксация осмотров и архив сканов, который растёт каждый месяц

MAATRIX

В страховом агентстве архив не бывает статичным: каждый новый осмотр — это десятки снимков, каждое новое дело — сканы паспорта, полиса, актов и переписки. Это не разовая загрузка данных, а поток, который не прекращается, пока агентство работает. Рано или поздно вы упираетесь в лимит текущего тарифа хранилища — и вопрос не в том, случится ли это, а когда именно и что вы будете делать в моменте, когда это случится.

Что именно копится: фотофиксация и сканы — это разные по смыслу данные

В агентстве обычно смешивают в одну кучу два потока данных, у которых на самом деле разные требования к хранению.

Фотофиксация осмотра — это доказательство состояния объекта на конкретный момент времени. Царапина на бампере, протечка на потолке, состояние кровли до урагана и после. Это не иллюстрация к делу, это доказательная база: если дело дойдёт до суда, экспертизы или спора с перестраховщиком, важна не только сама фотография, но и то, что она не менялась с момента съёмки и у неё есть проверяемая дата и привязка к делу. На практике это означает: снимки нужно хранить в исходном виде (не пересжатыми мессенджером), с метаданными, и желательно с журналом — кто загрузил, когда, к какому делу привязано.

Сканы документов клиента — паспорт, СНИЛС, полис, справки из ГИБДД или МЧС, акты осмотра, переписка — это персональные данные и одновременно юридически значимые документы. Здесь на первый план выходит не столько неизменность, сколько доступ: кто может открыть скан паспорта клиента, как это логируется, и что происходит с этими данными, если сотрудник уволился или доступ к облачному сервису кто-то передал по недосмотру.

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

Почему архив не останавливается: механика роста, которую легко недооценить

Ключевая особенность архива страхового агентства — он не "наполняется до какого-то объёма и стабилизируется", как, например, каталог товаров интернет-магазина. Он растёт монотонно, пока агентство ведёт дела, и практически ничего из него нельзя удалить.

Причина в том, что срок, за который дело может "вернуться" — оспаривание выплаты, повторная экспертиза, запрос от перестраховщика, судебный иск — измеряется годами, а не месяцами. Дело, закрытое три года назад, может внезапно понадобиться целиком: и фотографии осмотра, и сканы, и переписка. Это означает, что горизонт хранения архива страхового агентства реально считается годами вперёд, и удаление старых дел "чтобы освободить место" — решение, которое создаёт больше риска, чем экономит.

Если взять для примера агентство, которое ведёт несколько десятков дел в месяц, где на каждое дело в среднем приходится по несколько десятков фотографий осмотра плюс сканы 5-10 документов — за год это уже заметный объём, и он не выходит на плато. Каждый следующий месяц архив просто больше, чем предыдущий, без исключений. Конкретные цифры у каждого агентства свои — зависят от специализации (авто, недвижимость, имущество юрлиц), среднего числа фото на дело и того, сканируете ли вы документы в высоком разрешении для читаемости мелкого текста. Но направление роста всегда одно — вверх, без сезонных "просадок" объёма.

Как это выглядит на практике: упирание в лимит каждые несколько месяцев

Классический сценарий: агентство подключило облачное хранилище или CRM с фотоархивом на определённом тарифном плане — условно "500 ГБ" или "1 ТБ". Первые месяцы всё работает штатно. Потом кто-то из сотрудников получает уведомление "хранилище заполнено на 90%" или, хуже, дело не загружается, потому что место кончилось прямо в момент, когда нужно было прикрепить фото с выездного осмотра.

Дальше — выбор из двух плохих вариантов. Первый: срочно перейти на следующий тарифный план, который часто стоит непропорционально дороже, а не line­арно больше за пропорционально больше места — вендоры так строят линейку тарифов специально. Второй: начать вручную разбирать архив, выгружать старые дела куда-то ещё, тратить время сотрудников на то, что не приносит агентству ни рубля дохода.

Проблема в том, что этот сценарий повторяется. Апгрейднули тариф — через несколько месяцев архив снова упирается в новый потолок, потому что рост не остановился, просто сдвинулся порог. Агентство оказывается в режиме постоянного реагирования на нехватку места вместо того, чтобы один раз спланировать инфраструктуру под непрерывный рост.

Почему готовые облачные тарифы с фиксированным лимитом плохо подходят под этот профиль

Дело не в том, что облачные сервисы хранения плохие — они отлично подходят под предсказуемую, ограниченную по объёму задачу. Проблема именно в характере роста архива страхового агентства: он непрерывный и не имеет верхней границы, пока агентство работает.

У тарифов с фиксированными ступенями (500 ГБ → 1 ТБ → 2 ТБ и так далее) есть системная особенность: вы всегда либо платите за место, которым ещё не пользуетесь (взяли тариф с запасом на будущее), либо периодически упираетесь в лимит и переходите на следующую ступень в режиме "уже нужно было вчера". Спланировать заранее, когда именно наступит следующий переход, сложно — это зависит от загрузки агентства, сезонности страховых случаев (после стихийных бедствий, например, поток дел скачком растёт), от того, сколько фотографий делает конкретный агент на осмотре.

Есть и второй момент, отдельный от объёма: доступ к архиву в общем облачном хранилище часто устроен по принципу "у всех, у кого есть ссылка на папку". Для сканов паспортов и полисов клиентов это не то разграничение доступа, которое хочется иметь, если агентство серьёзно относится к тому, что происходит с персональными данными клиентов.

Альтернатива: собственный сервер с наращиваемым диском по мере роста архива

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

На практике на VPS с диском на базе LVM это выглядит так. Сначала смотрите текущее состояние:

df -h /data
lsblk

Когда провайдер увеличил размер виртуального диска (это делается в панели управления сервером, без даунтайма), нужно сначала расширить раздел, затем физический том LVM, затем логический том, и в конце — файловую систему:

growpart /dev/vda 1
pvresize /dev/vda1
lvextend -l +100%FREE /dev/mapper/vg-data-archive
resize2fs /dev/mapper/vg-data-archive

Если файловая система XFS, а не ext4, последний шаг вместо resize2fs будет xfs_growfs /data. Вся операция для растущего архива, который активно пишется, обычно проходит без остановки сервиса — расширение online, сервис даже не нужно перезапускать. Это принципиально отличается от сценария "переезжай на новый тариф облака", где часто требуется перезалить весь архив на новую точку доступа.

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

Отдельно стоит отметить: с ростом объёма имеет смысл периодически проверять, не растёт ли архив быстрее, чем ожидалось — например, если агентство начало снимать осмотры в более высоком разрешении или добавило видеофиксацию к фотографиям. Мониторинг занятого места — не разовая настройка, а постоянная практика: простой crontab-скрипт с уведомлением при достижении 80% занятого места избавляет от сюрпризов гораздо надёжнее, чем надежда вспомнить проверить вручную.

Как организовать архив на сервере: структура, доступ и резервные копии

Наращиваемый диск решает вопрос объёма, но не решает вопрос порядка — а без порядка архив на своём сервере превращается в ту же "папку с фотками", только уже не на чужом облаке, а на своём железе.

Разумная структура каталогов строится вокруг дела, а не вокруг типа файла — это упрощает и поиск, и разграничение доступа:

/data/archive/2026/08/case-104582/
  photos/            # фотофиксация осмотра
  scans/              # сканы документов клиента
  acts/                # акты осмотра, экспертные заключения
  correspondence/  # переписка по делу

Доступ к каталогу scans (персональные данные клиентов) стоит разграничить отдельно от photos — не всем сотрудникам, которые работают с фотографиями осмотра, обязательно нужен доступ к сканам паспортов. На Linux-сервере это делается через группы и права на каталоги, либо, если агентство уже выросло из простого файлового доступа, через отдельный портал с ролевой моделью поверх того же хранилища.

Резервное копирование растущего архива — отдельная задача, и наращивание основного диска её не заменяет. Практичный вариант — инкрементные бэкапы инструментом вроде restic или borgbackup, которые копируют только изменения, а не весь архив целиком при каждом запуске:

restic -r /mnt/backup-disk/archive-repo backup /data/archive --tag daily

Для страхового архива имеет смысл держать копию не только на другом диске того же сервера, но и физически в другом месте — если сервер выйдет из строя целиком, доказательная база по открытым делам не должна пропасть вместе с ним. Отдельный недорогой сервер под задачи бэкапа или объектное хранилище у другого провайдера здесь вполне оправданы как страховка (в буквальном смысле) для самого архива.

Шифрование сканов документов клиентов на уровне диска или отдельного зашифрованного раздела — разумная базовая мера, особенно если сервер физически стоит не в вашем офисе, а в дата-центре провайдера. Restic и borgbackup, кстати, шифруют бэкапы "из коробки" на уровне репозитория, это не требует отдельной настройки.

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

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