Строительная фирма: 400 ГБ фотоотчётов с объектов в год — куда их девать

MAATRIX

Если у вас три-пять одновременных объекта и на каждом прораб или мастер каждый день фотографирует этапы работ, актированные скрытые работы, обмеры и косяки субподрядчиков — цифра в 400 ГБ за год набегает незаметно и без всякого преувеличения. Проблема не в том, что фото «много весят» — проблема в том, что вся эта масса обычно лежит где попало: в личных телефонах, в чатах WhatsApp и Telegram, на диске «Иван Петрович, у него есть флешка». А когда через два года заказчик или суд спрашивает «покажите, как выглядела гидроизоляция перед заливкой на объекте на Строителей, 14», выясняется, что фото либо удалены за давностью в мессенджере, либо лежат на телефоне уволившегося прораба. Разберём, сколько на самом деле накапливается фото со стройки, почему обычное облако на этом объёме начинает мешать, а не помогать, и как выстроить хранение на своём сервере так, чтобы через пять лет вы могли поднять любой снимок за 30 секунд.

Сколько на самом деле копится: считаем не по объекту, а по компании

Ловушка в том, что владелец компании обычно думает «у нас же не завод, фоток немного» — оценивая по одному объекту. Но если у вас пять активных площадок, на каждой минимум один человек снимает не для соцсетей, а для дела: приёмка материалов, разметка, армирование перед заливкой, скрытые работы под актирование, дефекты подрядчиков, финальная приёмка помещений. Современный смартфон отдаёт файл JPEG на 3-8 МБ, а если бригадир снимает видео обхода объекта — ролик в минуту-две на телефоне легко даёт 150-300 МБ. При активной стройке один объект генерирует в месяц несколько тысяч файлов суммарно, и годовой объём в несколько сотен гигабайт на компанию с параллельными объектами — вполне ожидаемая, а не завышенная величина. Здесь и далее мы отталкиваемся именно от заголовочной цифры 400 ГБ в год как от иллюстративного ориентира: у вас может быть 200 ГБ или 700 ГБ в зависимости от числа объектов, привычки снимать видео и требований заказчиков к фотофиксации — принцип хранения от этого не меняется.

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

Почему обычное облако на этом объёме начинает мешать, а не помогать

Личные и «домашние» облака — Google Диск, Яндекс.Диск, Dropbox — прекрасно работают, пока объём укладывается в бесплатный или базовый платный тариф. Проблема стройфирмы в другом: у вас не один аккаунт, а десяток — у каждого прораба свой телефон и своя учётная запись, синхронизация идёт вразнобой, и в какой-то момент выясняется, что общий тариф на команду упирается в лимит, а следующий тариф — это шаг в сторону объёма, который компании не нужен целиком, но платить приходится за весь пакет. Плюс к этому у публичных облаков нет естественного способа разложить фото по структуре «объект → дата → раздел работ» так, чтобы в этом мог ориентироваться не только тот, кто снимал, а любой сотрудник компании через два года.

Второй момент — доступ и права. Прораб объекта на Строителей, 14 не должен видеть архив объекта на Заречной — это чужой контракт, чужие сметы, иногда чужие NDA от заказчика. В личных аккаунтах разграничить это неудобно: либо всё в одной общей папке видно всем, либо у каждого свой изолированный аккаунт — и тогда компания не видит общей картины и теряет данные при увольнении сотрудника вместе с его личным облаком.

Третий момент — деньги. Тариф на облачное хранилище растёт ступенями и привязан к объёму данных, которые вы никогда не «выкупаете» — вы их арендуете бессрочно, и цена почти всегда идёт вверх по мере роста архива, а не вниз. Через пять лет, когда накопится не 400 ГБ, а 1,5-2 ТБ архива с пяти-шести годов работы компании, вы будете платить за облако кратно больше, чем платите сегодня — и это будет длиться вечно, а не один раз.

Как это выглядит в реальности до наведения порядка

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

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

Структура на своём сервере: как раскладывать фото, чтобы через два года в них можно было найти нужный кадр

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

/storage/objects/
  2024-obj-stroiteley-14/
    01-priemka-materialov/
    02-zemlyanye-raboty/
    03-fundament/
      2024-06-skrytye-raboty/
      2024-07-armirovanie/
    04-karkas/
    05-fasad/
    akty-skrytyh-rabot/
    itogovaya-priemka/
  2024-obj-zarechnaya-9/
    ...
  2025-obj-promzona-sever/
    ...

Год в названии объекта нужен, потому что объекты с похожими адресами повторяются у долгоживущей компании, и через три-четыре года без даты в имени папки легко перепутать «Заречная, 9» этого года и прошлого. Внутри объекта — разбивка по этапам работ, а не только по календарным месяцам: так проще собрать пакет для конкретного акта, не перебирая все даты подряд.

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

Права на уровне файловой системы стоит продублировать группами Linux, а не полагаться только на права Nextcloud:

groupadd obj-stroiteley14
useradd -G obj-stroiteley14 prorab_ivanov
chown -R root:obj-stroiteley14 /storage/objects/2024-obj-stroiteley-14
chmod -R 2770 /storage/objects/2024-obj-stroiteley-14

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

Сколько диска закладывать и как считать вместимость сервера

Отталкиваемся от иллюстративной цифры в 400 ГБ в год как от базового ориентира — у вас она может отличаться в разы, порядок расчёта от этого не меняется. Если компания рассчитывает хранить фотоархив пять лет (стандартный срок, актуальный для гарантийных случаев и возможных судебных споров по качеству работ), то при 400 ГБ/год без учёта роста числа объектов это около 2 ТБ на горизонте пяти лет. С поправкой на рост компании и на то, что диск никогда не заполняется под ноль — разумный запас в 2-2,5 раза от расчётного объёма.

Практическая конфигурация для такого архива — два диска по 4 ТБ в программном RAID1: это даёт 4 ТБ полезного объёма с защитой от отказа одного диска (для архива, который жалко потерять, зеркалирование обязательно, а не опционально):

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 /dev/md0
mount /dev/md0 /storage

Если ожидается рост за пределы горизонта в 5-7 лет или компания активно расширяется, разумнее сразу заложить LVM поверх RAID — тогда объём можно расширить, добавив диски, без переноса данных на новый раздел:

pvcreate /dev/md0
vgcreate storage_vg /dev/md0
lvcreate -l 100%FREE -n objects storage_vg
mkfs.ext4 /dev/storage_vg/objects

При добавлении нового диска в массив том расширяется командой lvextend -l +100%FREE /dev/storage_vg/objects && resize2fs /dev/storage_vg/objects без остановки сервиса. Здесь стоит сразу заложить мониторинг заполнения диска — правило «когда осталось меньше 20% свободного места, заказываем расширение», а не разбор ситуации постфактум, когда прораб не может загрузить фото с объекта, потому что диск полон.

Загрузка с площадки и бэкап архива

С точки зрения прораба на объекте всё должно быть не сложнее, чем отправка фото в мессенджер. Мобильное приложение Nextcloud с автозагрузкой фотографий из указанной папки телефона решает эту задачу: прораб фотографирует как обычно, а приложение в фоне заливает снимки в его папку на сервере при подключении к Wi-Fi или мобильному интернету — вручную ничего пересылать не нужно. Для площадок без стабильного интернета (частая ситуация на объектах за городом или в новых микрорайонах без покрытия) приложение докачивает накопленные фото при первом подключении, ничего не теряя.

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

rclone copy gdrive:Объект14 /storage/objects/2024-obj-stroiteley-14/ --progress

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

rsync -a --delete /storage/objects/ backup-user@backup-host:/backup/objects/

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

Экономика: фиксированная аренда сервера против растущей платы за облако

Здесь стоит честно проговорить границы сравнения. Свой сервер — это не бесплатно, и это не «раз настроил и забыл»: диски физически стареют, RAID нужно проверять, сервер нужно администрировать хотя бы по минимуму. Но структура затрат принципиально другая: аренда сервера с фиксированным объёмом диска — это предсказуемый ежемесячный платёж, который не растёт от того, что архив за пять лет вырос с 400 ГБ до 2 ТБ, — вы заранее берёте сервер с диском под пятилетний горизонт, и цена аренды остаётся одной и той же вне зависимости от того, заполнен диск на 20% или на 80%.

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

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

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