Фото и видео квартир на 500 ГБ: где риелтору держать медиатеку

MAATRIX

Каждый выход на объект — это полсотни фото, видео-проходка, а если повезло с бюджетом клиента — ещё и облёт дрона или 3D-тур. Через год активной работы это легко набегает на 500 ГБ и больше, и однажды телефон отказывается снимать, потому что памяти нет, а бесплатное облако давно упёрлось в лимит и предлагает купить подписку. Разберём, как вместо связки «телефон — ноутбук — платное облако» держать все объекты в одном месте на своём сервере: с понятной структурой по объектам и доступом с любого устройства.

Почему у риелтора вообще накапливается такой объём

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

Один нормальный выход на объект для листинга — это не 10 фото, а 40-80: общие планы каждой комнаты, детали (кухня, санузел, вид из окна), несколько дублей одного и того же кадра при разном освещении, видео-проходка на 3-5 минут. Если объект премиальный — добавляется облёт дрона, отдельная видеосъёмка для соцсетей, иногда RAW-файлы от приглашённого фотографа, которые весят на порядок больше готовых JPEG.

Дальше это умножается на количество объектов в работе. У активного риелтора это не один-два объекта, а десятки в год, часть из которых висит в базе месяцами до продажи. И вот здесь возникает вторая причина роста архива: материалы по проданным и снятым с продажи объектам никто не удаляет. Они нужны для портфолио, для сравнения при оценке похожих квартир, иногда — как доказательство состояния объекта на момент показа, если возникает спор с покупателем или страховая история. В итоге накопленный объём не уменьшается со временем, а только растёт — и 500 ГБ из заголовка это не гипербола, а реалистичная цифра для риелтора с двух-трёхлетним стажем активной работы.

Где это лежит сейчас и почему это тупик

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

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

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

Медиатека на сервере: что меняется

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

Практическая разница в трёх вещах:

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

Из софта для такой задачи обычно берут Nextcloud или Seafile — оба разворачиваются на обычном VPS, дают веб-интерфейс, мобильные приложения для iOS и Android с автозагрузкой из камеры и десктопный клиент для синхронизации папки на ноутбуке. Разницу между ними и когда какой выбирать мы разбирали отдельно в сравнении Seafile и Nextcloud — для медиатеки риелтора, где важнее привычный интерфейс и простой шаринг ссылками, чаще выбирают Nextcloud, поэтому дальше разберём разворачивание именно на нём.

Структура: как разложить объекты, чтобы находить нужный кадр за секунды

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

Рабочая схема, которая снимает большинство вопросов «а где это лежит»:

/objects/
  2026/
    2026-03_ivanova_2k-lenina-14/
      original/        # необработанные фото и видео как есть
      ready/            # отобранное и обработанное для листинга
      video/             # проходка, дрон
      floorplan/          # планировка, если есть
      docs/                # выписка, фото документов объекта (если храните здесь)
      README.txt            # адрес, дата съёмки, кто снимал, статус объекта

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

Отдельная папка original важна не для порядка ради порядка: если через полгода понадобится пересобрать материалы под другой формат (например, для сайта агентства нужны кадры в другом кропе), вы не редактируете единственную копию, а берёте исходники заново.

Для поиска внутри такого архива хватает встроенного поиска по названию в Nextcloud, а если нужно найти файлы за конкретный период или по объекту с сервера напрямую по SSH — обычный find:

find /objects/2026 -iname "*lenina*" -type d

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

Разворачиваем медиатеку на сервере: Nextcloud шаг за шагом

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

На Ubuntu 24.04 ставим базовый стек:

apt update && apt install -y nginx mariadb-server php php-fpm php-mysql \
  php-gd php-curl php-mbstring php-xml php-zip php-intl php-bcmath \
  php-gmp unzip

Создаём базу и пользователя:

mysql -u root -p -e "CREATE DATABASE nextcloud;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'сложный_пароль';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;"

Данные для медиатеки — а это в первую очередь видео и RAW — стоит с самого начала держать на большом диске отдельно от системного раздела, а не в дефолтной папке /var/www/nextcloud/data. При установке через occ укажите путь на смонтированном диске:

sudo -u www-data php occ maintenance:install \
  --database "mysql" --database-name "nextcloud" \
  --database-user "nextcloud" --database-pass "сложный_пароль" \
  --admin-user "admin" --admin-pass "сложный_пароль" \
  --data-dir "/mnt/storage/nextcloud-data"

Для видео и облётов дрона важно поднять лимит загрузки файлов — по умолчанию PHP режет загрузку файлами в районе десятков мегабайт, а видео-проходка может весить несколько гигабайт. В /etc/php/8.3/fpm/php.ini:

upload_max_filesize = 8G
post_max_size = 8G
memory_limit = 512M
max_execution_time = 3600

И на стороне nginx в блоке конфига Nextcloud:

client_max_body_size 8G;
fastcgi_read_timeout 3600;

После перезапуска php-fpm и nginx большие видеофайлы будут заливаться без обрывов на середине — это частая причина, по которой у риелторов «не грузится проходка» именно на бесплатных облаках с их скрытыми лимитами на размер файла.

Домен и HTTPS настраиваются как для любого сайта на сервере — Let's Encrypt через certbot, добавление домена в trusted_domains в config.php. Дальше медиатека доступна по обычному адресу вида https://media.вашдомен.ru.

Доступ с телефона, для клиентов и коллег, и что с бэкапом

Мобильное приложение Nextcloud (iOS и Android) даёт то, ради чего всё затевалось: автозагрузку фото из камеры телефона прямо на сервер, без промежуточного шага «сначала скинуть на компьютер». Настраивается один раз — в приложении выбирается папка автозагрузки (например, objects/_inbox/), и дальше свежие кадры с выезда попадают на сервер ещё до того, как вы сели в машину. Раскладка по конкретной папке объекта — это уже ручное перемещение файлов из inbox, но это дело пяти минут вечером, а не разбора завала раз в квартал.

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

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

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

Отдельно — про бэкап. Перенос архива с бесплатного облака на свой сервер снимает проблему лимитов, но не снимает ответственности за резервную копию: диск сервера тоже может выйти из строя. Здесь не стоит полагаться на «мы же теперь на своём сервере, значит, безопасно» — регулярная резервная копия нужна в любом случае, и проще всего настроить её через готовый инструмент вроде BorgBackup, который умеет инкрементальные копии без повторной прогонки всего архива каждый раз — подробнее в материале про установку BorgBackup на VPS.

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

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