Фотограф отдал клиенту 4 ТБ съёмок и не разорился на облаке

MAATRIX

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

За что на самом деле берут деньги публичные облака

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

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

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

Почему именно фотограф чувствует это острее других профессий

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

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

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

Свой сервер вместо облака: что меняется в экономике

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

Что это даёт на практике:

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

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

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

Как физически раздавать фото клиенту с сервера

Здесь у фотографа реально четыре рабочих варианта, и они закрывают разные сценарии.

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

location /gallery/ {
    secure_link $arg_md5,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri secret_key";

    if ($secure_link = "") {
        return 403;
    }
    if ($secure_link = "0") {
        return 410;
    }

    root /var/www/photo-delivery;
}

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

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

Nextcloud как универсальный файлообменник. Больше подходит, когда нужно отдать не только фотогалерею, но и разнородный архив — RAW-дамп, документы по договору, видео. Ссылки с паролем и сроком действия настраиваются в интерфейсе, клиент видит привычный файловый менеджер в браузере. Как поднять — в материале про настройку Nextcloud на VPS.

S3-совместимое хранилище для больших RAW-архивов. Когда речь о цельном дампе на несколько террабайт, который клиент скачивает одним архивом, удобнее объектное хранилище с временными подписанными ссылками (presigned URL) — файл отдаётся напрямую, без нагрузки на веб-приложение. Это же хранилище закрывает и вашу внутреннюю задачу — единую точку, куда синхронизируются файлы с рабочих машин. Подробнее — в статье про S3-совместимое хранилище у себя.

Что выбрать под какую задачу

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

Перенос архива с облака на сервер без паузы в работе

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

1. Поднимите сервер и хранилище заранее, до того как понадобится отдавать следующую съёмку — так вы успеете обкатать раздачу на некритичном материале.
2. Синхронизируйте архив утилитой вроде rclone — она умеет работать и с Google Drive, и с Dropbox, и с вашим новым S3-совместимым хранилищем в одном инструменте:

rclone config          # один раз настроить remote для облака и для своего сервера
rclone copy gdrive:Клиенты/2026 myserver:archive/2026 \
  --progress --transfers 8 --checkers 16

1. Не удаляйте копию в облаке сразу. Держите её как подстраховку минимум до момента, пока не убедитесь, что все файлы перенеслись целиком — сверьте контрольные суммы (rclone check) или хотя бы количество и суммарный размер файлов.
2. Новых клиентов заводите сразу на сервере, старых — переводите на новые ссылки постепенно, по мере того как истекают старые сроки доступа в облаке.
3. Заложите резерв по месту — планируйте диск с запасом минимум на пару сезонов вперёд, чтобы не разбираться с расширением тома в разгар свадебного сезона.

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

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