Фотостудия: 5 ТБ съёмок в год и клиентские галереи на своём сервере

MAATRIX

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

Почему у студии эта задача сложнее, чем у одного фотографа

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

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

Во-вторых, разные фотографы работают в разных жанрах с разным весом материала: предметная съёмка для интернет-магазина — это сотни лёгких JPEG, а свадьба или репортаж — тысячи RAW по 30-60 МБ каждый плюс видео с подготовки. Годовой объём всей студии — сумма очень неровных по весу потоков, и у студии на несколько человек условные 5 ТБ в год набегают буднично, даже без экстремальных объёмов у отдельного фотографа.

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

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

Куда упирается облако и общий диск на практике

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

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

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

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

Один сервер, две задачи: архив студии и клиентские галереи

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

Общая схема такая:

/data/
  archive/                # внутренний архив студии, полный доступ только сотрудникам
    2026/
      08/
        2026-08-15_ivanovy-svadba_fotograf-petrov/
          raw/
          selects/
          delivered/
      ...
  galleries/               # публикуемые клиентские галереи
    2026-08-ivanovy-svadba/
      preview/             # уменьшенные копии с водяным знаком
      full/                # оригиналы, открываются после оплаты

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

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

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

Архив студии: как не потерять то, что отсняли пять человек

Для внутреннего архива на 5+ ТБ в год определяющий вопрос — не «где хранить», а «как не потерять при отказе диска и как быстро найти нужную съёмку через два года».

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

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

# первый полный бэкап архива студии
borg init --encryption=repokey-blake2 /mnt/backup/studio-repo
borg create --stats --progress \
  /mnt/backup/studio-repo::archive-{now:%Y-%m-%d} \
  /data/archive

# дальше — только изменения, инкрементально
borg create --stats --progress \
  /mnt/backup/studio-repo::archive-{now:%Y-%m-%d} \
  /data/archive

# ротация старых копий, оставить последние 4 недели и 6 месяцев
borg prune --keep-weekly=4 --keep-monthly=6 /mnt/backup/studio-repo

Структура папок архива — отдельный разговор, но правило простое: дата съёмки + тип события + фамилия ответственного фотографа в имени папки экономит часы поиска через полгода, когда клиент вернётся за допечаткой или пересъёмкой. Плоская папка «Фото 2026» с тысячами файлов без иерархии — гарантированная головная боль администратора студии.

Клиентские галереи: каждый клиент видит только свою съёмку

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

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

Пример структуры доступа через Nextcloud с публичными ссылками на отдельные папки:

occ files:transfer-ownership --path="galleries/2026-08-ivanovy-svadba"
occ sharing:create \
  --path="/galleries/2026-08-ivanovy-svadba" \
  --shareType=3 \
  --password="сгенерированный-пароль" \
  --expireDate="2026-11-15"

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

Водяные знаки на превью решают отдельную проблему: пока клиент не подтвердил выбор или не оплатил финальную сдачу, он листает уменьшенные превью с лёгкой полупрозрачной подписью, а не оригиналы в полном разрешении. Автоматизировать наложение знака можно экспортным пресетом в Lightroom или Capture One — тогда ретушёр экспортирует прямо в папку preview/ уже со знаком, без ручной обработки каждой съёмки.

Как это выглядит в рабочем процессе студии день за днём

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

1. Фотограф после съёмки подключается по VPN или из локальной сети студии и выгружает карту памяти напрямую в свою папку внутри archive/2026/08/. Структура папок предсказуема, дата и название съёмки задаются по единому шаблону.
2. Ретушёр или сам фотограф отбирает кадры, экспортирует финальную выборку в подпапку selects/ внутри архива — это всё ещё внутренняя часть, клиент её не видит.
3. Из selects/ готовая подборка публикуется в galleries/, с автоматическим наложением водяного знака на превью.
4. Администратор или фотограф генерирует ссылку на галерею с паролем и сроком действия, отправляет клиенту.
5. Клиент заходит по ссылке, листает превью, отмечает понравившиеся кадры — либо сразу видит финальные фото, если студия работает по модели «всё отобрано и оплачено на этапе брони».
6. После оплаты открывается доступ к оригиналам в полном разрешении из папки full/.
7. Через оговорённый срок (по умолчанию 60-90 дней) ссылка истекает автоматически, файлы остаются только во внутреннем архиве — их всегда можно переопубликовать, если клиент вернулся за допечаткой через полгода.

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

Инфраструктура: что реально нужно серверу под такой объём

Оценивать конфигурацию сервера имеет смысл не по разовому снимку «сколько места нужно сейчас», а по траектории роста студии на пару лет вперёд, потому что 5 ТБ в год — это накопительная величина.

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

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

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