Прораб шлёт фотоотчёты с объекта в чат: своё хранилище с историей стройки

MAATRIX

Каждый день на объекте вы фотографируете котлован, арматуру перед заливкой, кладку, разводку под стяжкой — и всё это летит в общий чат с заказчиком или в рабочую группу с прорабами субподряда. Через месяц там уже тысяча сообщений, фото вперемешку с перепиской про завоз бетона и жалобами на погоду, и найти снимок конкретного дня — та ещё археология. А когда заказчик спрашивает «а где фото, что мы заливали фундамент по проекту» или начинается спор про скрытые работы, пролистывать чат уже некогда. Ниже — как собрать простое хранилище на своём сервере, где фотоотчёты лежат по датам и этапам, а не растворяются в ленте мессенджера.

Почему чат — это временное хранилище, а не архив

Мессенджер отлично годится для оперативной связи: скинул фото, обсудил, договорились. Но у него есть свойства, которые превращают его в ловушку, если вы держите там историю объекта:

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

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

Как выглядит собственное хранилище фотоотчётов

Идея простая: у вас есть сервер (арендованный VPS с достаточным диском под фото — обычно хватает конфигурации с SSD от 100–200 ГБ на старте, с возможностью расширить диск, когда объектов станет больше), на нём стоит файловое приложение с веб-интерфейсом и мобильным клиентом. Вы фотографируете на объекте как обычно — телефоном, — и фото сами уезжают в структурированные папки на сервере, без ручной пересылки.

Практическая связка, которая закрывает задачу без танцев с бубном — Nextcloud на VPS:

• сервер разворачивается один раз, дальше это просто ссылка вида https://storage.вашдомен.ru;
• у Nextcloud есть мобильное приложение с автозагрузкой фото из выбранной папки телефона в выбранную папку на сервере;
• есть веб-интерфейс, где заказчик или руководство смотрит фото прямо в браузере, без установки чего-либо;
• есть управление правами и ссылками на конкретные папки — можно дать доступ только к одному объекту или даже к одному этапу, не открывая весь архив.

Базовую установку Nextcloud на VPS мы разбирали отдельно, там всё по шагам: как установить и настроить Nextcloud на VPS. Ниже — то, что специфично именно для фотоотчётов с объекта: структура папок, автозагрузка с телефона и раздача доступа так, чтобы не открыть заказчику лишнего.

Если объектов у вас пока один-два и городить полноценный Nextcloud не хочется, тот же результат частично даёт связка WebDAV с обычной файловой структурой на сервере — но тогда вы теряете удобный мобильный аплоад и веб-просмотр в браузере, придётся заводить FTP/SFTP-клиент на телефоне. Для одного человека это ещё терпимо, но как только к отчётам подключаются два-три прораба субподряда, Nextcloud окупает время на установку почти сразу.

Структура папок: по объекту, потом по этапу и дате

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

/Storage/
  Объект_Ivanovka_15/
    01_Nulevoy_cikl/
      2026-08-03_kotlovan/
      2026-08-11_armatura_pered_zalivkoy/
      2026-08-14_zalivka_fundamenta/
    02_Karkas_i_kladka/
      2026-08-20_kladka_1_etazh/
      2026-08-28_peremychki_okonnye_proyomy/
    03_Krovlya/
    04_Inzhenernye_seti/
      2026-09-02_razvodka_otopleniya_2_etazh/
    05_Otdelka/
    06_Skrytye_raboty_akty/
  Объект_Beryozovaya_42/
    01_Nulevoy_cikl/
    ...

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

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

Автозагрузка с телефона: фото сами уезжают на сервер

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

В мобильном приложении Nextcloud это настраивается через раздел автозагрузки (Auto Upload):

1. Устанавливаете приложение Nextcloud на телефон прораба, авторизуетесь на своём сервере.
2. В настройках приложения включаете автозагрузку фото и указываете папку камеры телефона как источник.
3. Указываете целевую папку на сервере — например, общую папку _Vhodyashchie_foto, куда падают все снимки без разбора.
4. Раз в день (или после смены) прораб заходит в эту входящую папку и раскидывает свежие фото по нужным папкам этапов — это дело двух-трёх минут, если снимков за день не сотни.

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

Если на объекте фотографируют несколько человек (прораб, мастер, представитель заказчика), у каждого — свой логин в Nextcloud с автозагрузкой в свою входящую папку с именем сотрудника. Это не только удобство, но и ответ на вопрос «кто снимал», если фото окажется предметом спора.

Как быстро найти нужное фото

Структура папок закрывает 90% случаев — вы физически идёте по пути объект → этап → дата и находите снимок. Но для оставшихся 10% полезны ещё два приёма:

• Поиск по имени файла и папки. Веб-интерфейс Nextcloud ищет по названиям папок и файлов, поэтому если в имени папки есть и дата, и краткое описание («2026-08-14_zalivka_fundamenta»), поиск по слову «фундамент» найдёт нужную папку за секунду, даже если вы не помните точную дату.
• Файл-README на объект. В корне папки объекта держите один текстовый файл с краткой хронологией — какая дата какому событию соответствует, где какие акты подписаны, где были замечания заказчика. Полторы минуты на заполнение после смены экономят долгие поиски через месяцы, особенно если по объекту работает не один человек и то, что очевидно вам, для другого прораба — не очевидно.

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

Доступ для заказчика и руководства без риска за весь архив

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

Правильная модель доступа — раздельная:

• Ссылка на конкретную папку, а не на весь диск. В Nextcloud это делается через «Поделиться» на папке объекта (или даже отдельного этапа) — генерируется публичная ссылка, которую можно защитить паролем и ограничить сроком действия.
• Доступ только на просмотр (read-only). Заказчик смотрит и при необходимости скачивает, но не может случайно удалить или переместить файлы — такое право отдельно выставляется при создании ссылки на шаринг.
• Отдельная ссылка под каждый повод. Например, отдельная ссылка на папку «Скрытые работы» для представителя заказчика, который принимает эти работы, и отдельная — на общий прогресс для инвестора или руководства, который смотрит по субботам сводку за неделю.
• Срок действия ссылки. Если доступ нужен разово (например, для урегулирования конкретного спора), поставьте дату истечения — не придётся потом вспоминать, кому и что вы когда-то открыли.

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

При переезде с одного объекта на архив в разы больше (несколько сданных объектов, годы истории) имеет смысл заранее продумать, как данные будут расти на диске — эта тема разобрана в статье про перенос файлового хранилища на терабайтные объёмы, если фотоархив со временем перерастает стартовый диск.

Резервная копия — отдельно от самого хранилища

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

Минимальная схема для фотоархива объекта:

• ежедневный или еженедельный снапшот всей папки хранилища на отдельный диск или в объектное хранилище — регулярность зависит от того, сколько фото вы готовы потерять при сбое между копиями;
• хранение нескольких последних копий, а не перезапись одной и той же — на случай, если проблема (например, случайное удаление) обнаружится не сразу, а через день-два;
• проверка, что копия реально восстанавливается, а не просто создаётся — раз в квартал стоит попробовать поднять архивную копию и убедиться, что файлы читаются.

Если объектов и данных немного, для старта достаточно встроенных средств резервного копирования Nextcloud (экспорт данных и базы по расписанию через cron) на второй диск того же сервера или на отдельное хранилище. Когда объём вырастет, имеет смысл посмотреть в сторону VPS с отдельным диском под бэкапы — это разобрано в материале про выбор VPS под задачи бэкапов и архива.

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