В тарифе хостинга указано 20, 50 или даже 100 ГБ дискового пространства, а сам сайт занимает всего пару гигабайт. Возникает вполне разумная мысль: почему бы не загрузить в оставшееся место фотографии, архив документов, видео или резервные копии с компьютера?
Технически загрузить обычный файл на хостинг чаще всего можно. Серверу безразлично, находится внутри ZIP-архива тема WordPress или семейные фотографии. Но возможность загрузки еще не означает, что правила конкретного тарифа разрешают использовать веб-хостинг как обычное файловое хранилище.
Именно здесь появляется важное различие. Дисковое пространство предоставляется прежде всего для работы сайтов и связанных с ними данных. У некоторых провайдеров хранение посторонних файлов ограничено условиями оказания услуг. Кроме того, даже разрешенное хранение больших объемов может оказаться неудобным из-за лимитов трафика, количества файлов и особенностей самого веб-хостинга.
Какие файлы нормально хранить вместе с сайтом
Обычный сайт сам состоит из файлов. Поэтому фотографии, документы, архивы и видео на хостинге совершенно нормальны, если они являются частью проекта.
Интернет-магазин может хранить фотографии товаров и PDF-инструкции. Сайт строительной компании может предлагать посетителям скачать каталоги и сертификаты. У образовательного проекта могут находиться презентации и методические материалы. В блоге публикуются изображения, а на форуме пользователи загружают вложения.
Во всех этих случаях файлы непосредственно связаны с работой сайта.
Проблема начинается тогда, когда хостинг пытаются использовать для совершенно другой задачи.
Представим тариф с 50 ГБ дискового пространства. WordPress занимает 3 ГБ. Владелец видит свободные 47 ГБ и решает загрузить туда архив фотографий с телефона, образы программ, фильмы, резервные копии ноутбука и другие данные, которые никак не используются сайтом.
Технически файловый менеджер или FTP могут позволить это сделать. Но условия тарифа могут не разрешать подобное использование.
Поэтому первая вещь, которую нужно проверить, это не объем свободного диска, а правила провайдера.
Особенно внимательно стоит относиться к формулировкам об использовании дискового пространства только для файлов сайтов, размещенных в аккаунте. Могут существовать отдельные ограничения на архивы, резервные копии, видео, исполняемые файлы или материалы, предназначенные преимущественно для скачивания.
Правила у разных компаний отличаются. Нельзя считать, что если один хостер разрешает определенный сценарий, то его автоматически разрешает другой.
Есть и пограничные ситуации.
Например, владелец сайта создает ZIP со всеми файлами проекта перед обновлением WordPress и оставляет его рядом с сайтом. Это очевидно связано с обслуживанием проекта. Но если ежедневно создавать полный архив и никогда не удалять старые версии, через несколько месяцев резервные копии способны занять большую часть тарифа.
Даже когда подобное хранение не запрещено, оно не обязательно разумно.
Резервная копия, лежащая в том же аккаунте, что и оригинал, помогает после случайного удаления файла или неудачного обновления. Но если будет потерян весь аккаунт или возникнет серьезная проблема с площадкой, рабочий сайт и его копия окажутся в одном месте.
Поэтому важные резервные копии лучше дополнительно хранить независимо от основного хостинга.
С документами логика похожая.
Если посетитель открывает на сайте прайс-лист, договор, инструкцию или каталог в PDF, такой файл естественно хранить рядом с проектом. Если же сервер используется как архив бухгалтерии компании, доступный только сотрудникам и никак не связанный с сайтом, для этой задачи существуют более подходящие решения.
Почему свободные гигабайты не превращают хостинг в облачный диск
На первый взгляд обычный хостинг и облачное хранилище делают одно и то же. Пользователь отправляет данные через интернет, они оказываются на чужом сервере и занимают определенное количество гигабайт.
Но эти услуги создавались для разных задач.
Веб-хостинг предназначен прежде всего для обслуживания сайтов. На сервере работают веб-сервер, PHP, базы данных и другие компоненты. Провайдер рассчитывает тарифы исходя из характерной нагрузки веб-проектов.
Файловое или объектное хранилище изначально предназначено для размещения данных.
Разница становится заметна при увеличении объема.
Предположим, на сайте опубликована фотография размером 300 КБ. Ее открывают посетители страницы. Это совершенно обычная нагрузка.
Теперь представим архив размером 15 ГБ, который ежедневно скачивают десятки пользователей. Для сервера это уже другой профиль потребления ресурсов и сетевого трафика.
Еще один пример это видео.
Положить короткий ролик на обычный хостинг технически несложно. Но если сотни посетителей одновременно начнут смотреть большой видеофайл, серверу придется постоянно отдавать значительный поток данных.
Поэтому крупные видеосервисы не работают по принципу загрузим все ролики в папку обычного виртуального хостинга.
Для небольшого файла, который скачивают несколько раз в месяц, проблема может вообще не возникнуть. Для большой медиатеки архитектура должна быть другой.
Есть и менее очевидное ограничение — количество файлов.
Хостинг может предоставлять много свободных гигабайт, но ограничивать количество файлов и каталогов в аккаунте. Часто в таком контексте встречается термин inode.
Представим два архива одинакового объема.
Первый состоит из десяти видеофайлов. Второй содержит миллион маленьких изображений. По занимаемому диску они могут быть сопоставимы, но для файловой системы это совершенно разные ситуации.
Поэтому при большом количестве мелких объектов нужно смотреть не только на гигабайты.
Дополнительные ограничения могут касаться нагрузки на процессор, операций ввода и вывода, числа процессов и сетевого трафика. На виртуальном хостинге ресурсы сервера распределяются между множеством клиентов, поэтому провайдер не может позволить одному аккаунту бесконтрольно использовать всю машину.
Отсюда важный вывод: надпись 50 ГБ на тарифе говорит только о доступном объеме дискового пространства. Она не обещает, что эти 50 ГБ можно использовать для любой задачи любым способом.
Можно ли раздавать большие файлы посетителям сайта
Если файл относится к сайту, его скачивание посетителями обычно является естественной функцией веб-проекта.
Например, производитель оборудования публикует каталог продукции размером 40 МБ. Посетители скачивают его несколько десятков раз в день. Для современного хостинга такая задача вряд ли выглядит необычной.
Но увеличение размера файла и количества скачиваний постепенно меняет ситуацию.
Представим файл размером 2 ГБ. Если его скачали 10 раз, сервер передал около 20 ГБ данных. Если 1000 раз, речь идет уже примерно о 2 ТБ исходящего трафика.
При этом сам файл по-прежнему занимает на диске всего 2 ГБ.
Поэтому оценивать файловую раздачу только по свободному месту неправильно.
Нужно учитывать сетевой трафик, скорость канала, правила провайдера и влияние нагрузки на остальные сайты аккаунта.
Особенно это важно, если пользовательские файлы становятся основной функцией проекта. Например, сайт позволяет каждому посетителю загружать фотографии, документы или архивы, а другим пользователям их скачивать.
Такой проект уже больше похож на файловый сервис, чем на обычный информационный сайт.
Для него может понадобиться отдельное хранилище, а веб-сервер будет заниматься страницами, авторизацией, базой данных и логикой приложения.
Это дает еще одно преимущество: файлы и само приложение можно масштабировать независимо.
Допустим, код сайта и база занимают всего несколько гигабайт, а пользовательские фотографии выросли до нескольких терабайт. Нет необходимости увеличивать системный диск веб-сервера только ради медиатеки. Фотографии можно хранить отдельно, а сайт будет обращаться к ним по мере необходимости.
Такой подход часто используют и для изображений интернет-магазинов, больших архивов документов, резервных копий и других объемных данных.
Для обычного небольшого сайта усложнять архитектуру заранее не нужно.
Если на сайте 300 фотографий, несколько PDF и пара небольших архивов, переносить все это в отдельное хранилище только потому, что такая технология существует, обычно бессмысленно.
Отдельное решение становится полезным тогда, когда появляется реальная причина: заканчивается место, растет медиатека, увеличивается трафик, возникают ограничения хостинга или файлы требуется хранить независимо от веб-сервера.
Когда для файлов лучше выбрать отдельное хранилище
Главный вопрос здесь не можно ли загрузить файл на хостинг, а соответствует ли выбранная услуга задаче.
Для обычного корпоративного сайта вполне нормально хранить на хостинге изображения страниц, логотипы, документы для скачивания и другие материалы проекта.
Для WordPress нормально держать медиатеку внутри каталога uploads. Для небольшого интернет-магазина нормально хранить фотографии товаров на том же хостинге. Для сайта компании нормально разместить несколько PDF-каталогов.
Отдельное хранилище имеет смысл рассматривать, когда файлов становится действительно много или они начинают жить собственной жизнью независимо от сайта.
Типичные примеры:
- большая коллекция фотографий и видео;
- архив резервных копий нескольких серверов;
- пользовательские загрузки большого объема;
- программные дистрибутивы и другие крупные файлы для массового скачивания;
- медиатека, которая быстро растет;
- данные, к которым должны обращаться несколько серверов или приложений;
- архивы, которые нужно хранить независимо от жизненного цикла конкретного сайта.
Для подобных задач часто используется объектное хранилище. Вместо привычной структуры диска сайта данные помещаются в отдельное хранилище, а приложение получает к ним доступ через специальные адреса и API.
Пользователю небольшого сайта необязательно разбираться в архитектуре крупных облачных систем. Важно понимать сам принцип: веб-сервер занимается сайтом, а большое количество файлов можно вынести в систему, специально предназначенную для их хранения.
Иногда подойдет и обычное облачное хранилище, если файлы нужны только владельцу и сотрудникам, а сайт к ним вообще не обращается.
Например, хранить рабочие документы компании, фотографии с мероприятий и архивы компьютеров на веб-хостинге только потому, что там осталось свободное место, обычно нет особого смысла. Сервис синхронизации и хранения файлов удобнее хотя бы потому, что создавался именно для такой работы.
Отдельно стоит сказать о конфиденциальных данных.
Файл, загруженный внутрь публичного каталога сайта, потенциально может оказаться доступным по прямому адресу. Нельзя считать его защищенным только потому, что ссылка нигде не опубликована.
Если документы не предназначены для посетителей, нужно правильно ограничивать доступ либо использовать хранилище с подходящей моделью авторизации.
Это особенно важно для документов клиентов, внутренних архивов и любых данных, которые не должны быть публичными.
Перед тем как превратить свободное место на тарифе в файловый архив, полезно ответить на несколько вопросов.
- Связаны ли эти файлы с работой сайта?
- Разрешает ли их хранение провайдер?
- Сколько файлов будет через год, а не только сегодня?
- Какой объем трафика создадут скачивания?
- Нужен ли публичный или закрытый доступ?
- Есть ли независимая резервная копия важных данных?
- Что произойдет с файлами при смене хостинга?
Если речь идет о нескольких фотографиях, каталогах и документах сайта, скорее всего, ничего усложнять не нужно.
Если же ответ звучит как десятки тысяч пользовательских файлов, сотни гигабайт архивов или постоянная раздача больших объемов данных, обычный виртуальный хостинг постепенно перестает быть подходящим инструментом.
Поэтому хранить файлы на обычном хостинге можно, если они относятся к работе сайта и такое использование соответствует правилам провайдера. Но свободное дисковое пространство не стоит воспринимать как бесплатный аналог облачного диска.
Хостинг лучше использовать по его прямому назначению, а для больших архивов, резервных копий и активно раздаваемых файлов выбирать сервис, рассчитанный именно на хранение данных. Так и сайт будет чувствовать себя лучше, и судьба файлов не будет зависеть от ограничений обычного веб-тарифа.
