Хостинг для картинок: свой сервер или фотохостинг

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

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

Чем хостинг картинок отличается от обычного хостинга сайта

Сайт с текстом и картинками нагружает сервер по-разному. Страница блога — это работа процессора: PHP собирает HTML, база отдаёт записи, всё занимает 30–80 мс и весит 50–100 КБ. Отдача изображения — работа диска и сетевой карты: процессор почти не участвует, зато в канал уходит несколько мегабайт.

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

Второе следствие касается трафика. У обычного корпоративного сайта на 3000 посетителей в месяц исходящий трафик редко превышает 5–10 ГБ. Галерея на тех же 3000 посетителей, где каждый листает по 20 снимков весом 400 КБ, отдаёт 24 ГБ. Разница в два-пять раз, и она растёт линейно вместе с посещаемостью.

Третье отличие — рост рывками. Текст добавляется медленно, а одна фотосессия или импорт каталога — это сразу минус 30 ГБ на диске. Поэтому под хостинг изображений тариф берут с запасом 40–50 % от текущего объёма.

Сколько весит одна фотография и как из этого получить объём диска

Вес файла зависит от разрешения и формата. Снимок с 12-мегапиксельной камеры смартфона в JPEG занимает 3–5 МБ. Тот же кадр, пересохранённый в WebP с визуально таким же качеством, весит 1,5–2,5 МБ — формат сжимает фотографии примерно вдвое эффективнее. Превью шириной 400 пикселей, которое показывают в списке товаров или в сетке галереи, укладывается в 20–40 КБ.

Считать нужно не по одному файлу, а по комплекту. Практически всегда одно изображение живёт на сервере в трёх-четырёх версиях: оригинал, крупная версия для страницы, среднее превью и миниатюра. Комплект из оригинала 4 МБ, версии 1200 px на 300 КБ, превью 400 px на 30 КБ и миниатюры 150 px на 8 КБ даёт около 4,34 МБ на одну карточку.

Ориентир для быстрой прикидки: 100 тысяч изображений по 2 МБ занимают 200 ГБ. Если оригиналы тоже остаются на сервере, к этому числу прибавляется ещё 300–500 ГБ — и задача из «недорогого VPS» превращается в отдельное хранилище. Поэтому многие проекты держат оригиналы в холодном хранилище — дешёвом архиве, откуда файлы достают редко, — а на боевом сервере оставляют только сжатые версии.

Трафик заканчивается раньше, чем место на диске

Диск покупается один раз, а трафик расходуется каждый день. Считается он просто: количество просмотров умножается на средний вес отданного файла. Тысяча посетителей, по 15 картинок весом 300 КБ на каждого, — это 4,5 ГБ в сутки и около 135 ГБ в месяц.

Второе ограничение — ширина канала, то есть сколько мегабит в секунду сервер может отдавать одновременно. Полоса пропускания измеряется в Мбит/с, и её легко перевести в картинки: канал 100 Мбит/с при отдаче файлов по 300 КБ выдаёт примерно 40–50 изображений в секунду. Подробнее термин разобран в статье про пропускную способность канала.

Именно канал, а не процессор, становится потолком. Nginx с включённой опцией sendfile отдаёт файл из дискового кеша прямо в сеть, минуя лишнее копирование в память приложения, и загрузка процессора на такой раздаче держится в пределах 5–15 %. Сервер выглядит незанятым, а страницы при этом грузятся медленно — упёрлись в 100 Мбит/с.

Если посещаемость скачет (рассылка, публикация в СМИ, распродажа), смотрите тарифы с честным безлимитом: подборка VPS с безлимитным трафиком собрана как раз под такие проекты. При лимитных тарифах перерасход обычно тарифицируется отдельно, и счёт за месяц вырастает непредсказуемо.

Три способа хранить изображения и когда какой дешевле

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

Второй — объектное хранилище. Это отдельный сервис, куда файлы кладутся по протоколу S3, а платить нужно за фактически занятые гигабайты и за исходящий трафик. Устройство и логика такого хранилища разобраны в материале про объектное хранилище. Годится, когда объём непредсказуем и растёт скачками.

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

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

Сколько стоит хранение у российских провайдеров

В разделе хранилищ нашего каталога сейчас восемь провайдеров, и разброс цен между ними трёхкратный. Минимальная цена входа по разделу — 140 ₽/мес, причём за эти деньги в младшем тарифе дают 100 ГБ SSD, что для галереи полезнее, чем лишнее ядро.

Данные проверены 03.09.2026.

Обратите внимание на разницу в подходах. У одних провайдеров младший тариф — это 10 ГБ NVMe за 200 ₽/мес, то есть быстрый диск маленького объёма под систему и базу. У других за 140 ₽/мес сразу дают 100 ГБ SSD: скорость ниже, зато под картинки места в десять раз больше. Для галереи второй вариант выгоднее, если только вы не отдаёте сотни файлов в секунду.

Терабайт собирается двумя путями: доплатой за расширение диска либо переносом файлов в объектное хранилище с поштучной тарификацией гигабайтов. Цену расширения смотрите в карточке провайдера — она отличается даже внутри одной линейки.

Какую конфигурацию брать под 100 тысяч изображений

Возьмём типовой каталог: 100 тысяч товарных фотографий, у каждой сжатая версия и два превью, оригиналы вынесены в отдельное хранилище. Занятый объём — около 230 ГБ вместе с системой, базой и логами. Посещаемость 2000 человек в сутки, по 12 картинок на визит.

Считаем трафик: 2000 × 12 × 300 КБ ≈ 7 ГБ в сутки, примерно 210 ГБ в месяц. Пиковая нагрузка приходится на 2–3 часа, и в эти часы канал должен вытягивать 25–35 картинок в секунду, то есть 60–90 Мбит/с. Стандартных 100 Мбит/с хватает впритык, 200 Мбит/с дают запас.

Процессор и память: 2 ядра и 4 ГБ RAM закрывают такую задачу с большим запасом, потому что nginx на раздаче статики держит около 2–5 МБ памяти на рабочий процесс. Больше памяти помогает косвенно — свободная RAM уходит под кеш файловой системы, и часто запрашиваемые превью читаются не с диска, а из памяти.

Тип диска подбирают по профилю нагрузки. Крупные файлы читаются последовательно, и здесь разница между SSD и NVMe почти не видна; она проявляется на тысячах мелких превью. Сравнить тарифы по типу накопителя можно в подборке VPS с SSD.

Как настроить отдачу картинок на nginx: пошагово

Ниже минимальная последовательность для сервера, который принимает загрузки и раздаёт файлы. Она предполагает Ubuntu или Debian и уже установленный nginx — веб-сервер, специально заточенный под быструю отдачу статических файлов.

1. Создайте отдельный каталог под файлы, например /var/www/media, и раскладывайте изображения по подпапкам вида /2026/09/. В одной директории не должно накапливаться больше 10–20 тысяч файлов: файловая система замедляется на листинге.
2. В секции сервера включите sendfile on; и tcp_nopush on; — первая директива отдаёт файл из кеша ядра напрямую в сокет, вторая склеивает заголовки с началом файла в один пакет.
3. Задайте срок кеширования в браузере: expires 30d; для каталога с картинками. Повторный визит перестаёт грузить сервер вообще.
4. Ограничьте типы файлов, которые отдаются из каталога загрузок, и запретите там выполнение скриптов директивой location ~ .php$ { deny all; }. Это закрывает классическую дыру с загрузкой вредоносного файла под видом фотографии.
5. Включите лимит на размер загружаемого файла: client_max_body_size 12m; — 12 МБ хватает на любой снимок со смартфона и отсекает попытки залить видео.
6. Проверьте конфигурацию командой nginx -t (она разбирает файл и сообщает об ошибках, ничего не перезапуская) и примените изменения через systemctl reload nginx.

После настройки проверьте заголовки ответа любым онлайн-инструментом или командой curl -I адрес_картинки — она запрашивает только служебные заголовки, не скачивая сам файл. В ответе должны быть Cache-Control с временем жизни и корректный Content-Type вида image/webp. Если тип определяется как application/octet-stream, браузер скачает файл вместо показа.

WebP, превью и кеш браузера: как срезать трафик втрое

Самая дешёвая оптимизация — не отдавать оригинал там, где он не нужен. В списке товаров пользователь видит картинку шириной 300–400 пикселей, и подставлять туда файл на 4 МБ вместо превью на 30 КБ — это стократный перерасход канала.

Второй шаг — формат. Перевод фотографий из JPEG в WebP сокращает вес примерно вдвое: было 3–5 МБ, стало 1,5–2,5 МБ при том же визуальном качестве. На каталоге из 100 тысяч файлов это экономия порядка 150–250 ГБ дискового места и такой же доли трафика.

Третий — кеш на стороне браузера. Заголовок с месячным сроком жизни означает, что вернувшийся посетитель не запрашивает картинки заново, и для аудитории с высокой долей повторных визитов расход канала падает на 40–60 %. Механика описана в справке про браузерное кеширование.

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

Резервные копии: что теряется при отказе диска

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

Рабочая схема простая. Полная копия каталога раз в неделю плюс ежедневная инкрементальная. Инкрементальная — это когда копируется не весь каталог, а только разница с предыдущей копией: новые и изменённые файлы. Такой режим экономит и время, и место: при 200 ГБ архива суточный прирост обычно составляет 1–3 ГБ.

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

И последнее: копию нужно хотя бы раз развернуть. Разверните архив в тестовую папку, откройте десяток случайных файлов, сверьте их количество с оригиналом. Проверка занимает 20–30 минут раз в квартал и снимает риск обнаружить битый архив в момент аварии.

Частые ошибки при переносе галереи на свой сервер

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

• Берут тариф впритык по диску. При заполнении накопителя выше 90 % начинаются сбои записи, а расширение занимает время и требует перезагрузки.
• Отдают картинки через PHP-скрипт ради «защиты от копирования». Процессор загружается в 10–20 раз сильнее, чем при прямой отдаче через веб-сервер.
• Не делают превью, а вставляют оригинал и просто ужимают его атрибутами ширины и высоты в HTML. Файл при этом качается целиком: пользователь скачивает 4 МБ, чтобы увидеть картинку размером со спичечный коробок.
• Забывают про лимит трафика в тарифе и узнают о нём из счёта за перерасход.
• Складывают все файлы в одну папку. При 200–300 тысячах объектов замедляются и бэкап, и любые операции со списком файлов.
• Не закрывают выполнение скриптов в каталоге загрузок — и получают чужой код на сервере через форму загрузки фотографии.

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

Сколько места нужно под 100 тысяч фотографий? Если хранить только сжатые версии в WebP по 2 МБ — около 200 ГБ. Если оставлять и оригиналы JPEG по 3–5 МБ, объём вырастает до 500–700 ГБ, поэтому оригиналы обычно выносят в отдельное хранилище.

Хватит ли одного ядра для раздачи картинок? Для сайта с посещаемостью до 2000–3000 человек в сутки — да, при условии что файлы отдаёт nginx напрямую. Нагрузка на процессор при такой раздаче держится в пределах 5–15 %, а потолком становится канал.

Что дешевле: диск на сервере или объектное хранилище? До 200–300 ГБ обычно дешевле диск VPS с фиксированной ценой от 140–200 ₽/мес. Выше этого объёма и при неровном росте выгоднее объектное хранилище, где вы платите за фактически занятые гигабайты.

Можно ли раздавать картинки с обычного виртуального хостинга? Можно, пока объём небольшой, но там жёстко ограничены и место, и число файлов, и нагрузка. Для галереи от 50 ГБ и при заметном трафике вариант с сервером управляемее — сравнить можно в разделе недорогих VPS.

Насколько WebP реально экономит трафик? При том же визуальном качестве снимок весит примерно вдвое меньше JPEG: 1,5–2,5 МБ против 3–5 МБ. На каталоге из 100 тысяч изображений экономия составляет 150–250 ГБ и места, и ежемесячной отдачи.

Какой канал нужен, чтобы галерея не тормозила в пик? Разделите пиковое число картинок в секунду на пропускную способность: 100 Мбит/с — это примерно 40–50 файлов по 300 КБ в секунду. Если в час пик вы отдаёте 60–70 файлов, нужен канал от 200 Мбит/с.

Как часто делать резервные копии медиа-каталога? Полную копию — раз в неделю, инкрементальную — ежедневно; суточный прирост при 200 ГБ архива редко превышает 1–3 ГБ. Раз в квартал архив разворачивают в тестовую папку и сверяют количество файлов.

Подойдёт ли такой сервер и под сайт, и под картинки сразу? Да, если развести их по разным каталогам и закрыть выполнение скриптов в папке загрузок. Разделять на два сервера имеет смысл при трафике выше 500 ГБ в месяц или когда галерея начинает мешать работе основного сайта.

Итог

Хостинг для картинок считается по двум числам: объём файлов и месячный трафик. Для 100 тысяч изображений по 2 МБ это 200 ГБ диска и порядка 200 ГБ отдачи в месяц, а закрывается такая задача конфигурацией из 2 ядер, 4 ГБ RAM и канала 100–200 Мбит/с. Экономия достигается не выбором тарифа подешевле, а превью, форматом WebP и месячным кешем в браузере — вместе они срезают трафик втрое.

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