Хостинг для портала: роли, вложения и фоновые задачи

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

Паспорт портала начинается с операций

Запишите CMS и точный выпуск, дополнения, базу, публичные и закрытые файлы, задачи расписания и доставку уведомлений. Отдельно укажите, кто обслуживает приложение и кто управляет сервером. Это исходные требования, не готовый список подходящих провайдеров.

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

Роль в CMS не системный root

На 6 октября 2026 года прочитано руководство Drupal о ролях и разрешениях. Права определяют просмотр, редактирование и изменение настроек. Они объединяются в роли; вошедший пользователь получает Authenticated user, а дополнительные роли дают дополнительные разрешения.

Это пример модели приложения, не доступ к VPS. Редактору новостей не нужен общий root-пароль только потому, что он публикует материалы. В другом движке проверьте его собственные разрешения, не переносите названия Drupal механически.

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

Системный вход рассматривается на странице SSH. Права CMS требуют отдельной проверки. Никакие учетные записи или разрешения пользователя здесь не менялись.

Закрытый файл проверяют по прямому адресу

Выделите документы, которые нельзя отдавать анонимному посетителю. Запишите расположение и способ выдачи. В приемку включите прямой запрос без сессии, а не только отсутствие ссылки в меню.

У открытого изображения и закрытого документа разные критерии. Первое должно загрузиться у читателя; второе - выдаваться по согласованным правилам. Не назначайте всем вложениям один публичный путь ради удобства переноса.

Это проверочный сценарий, не утверждение, что папка с именем private автоматически защищена. Уточните реализацию CMS и веб-сервера. Реальные документы, токены и адреса секретных архивов не должны попадать в публичный отчет.

Cron от посещений может не запуститься

Руководство Drupal по cron предлагает проверить последний запуск в Status report. Automated Cron зависит от посещений: если долго нет посетителей, задачи могут не выполняться. Работа после генерации страницы также ограничена таймаутами и занимает процесс веб-сервера.

Запуск извне сайта описан отдельно. Пример интервала около трех часов для стандартной настройки - не гарантия времени обработки вашей очереди. Согласуйте расписание под нужную операцию.

Выберите контрольную задачу и проверьте ее без посещения сайта в согласованный период. Запишите завершение и результат, не только наличие строки расписания. Среда запуска разобрана в руководстве cron.

Не переносите вызов Drupal cron на другую CMS. Ее worker и scheduler могут работать иначе. В этой работе задания, службы и процессы пользователя не запускались.

База, файлы и код должны совпадать

Официальное руководство Drupal по backup разделяет снимок БД, пользовательские файлы, рабочее состояние кода и процедуру отката. Private-файлы могут находиться отдельно; их тоже включают в опись.

Git хранит код, но не заменяет копию загрузок и содержимого базы. Возврат старой записи без ее документа неполон. Код должен соответствовать состоянию схемы и данных.

Руководство предлагает пробное восстановление в среде разработки и защищенное внешнее хранение. Приведенные сроки ежедневных и месячных копий - примеры, не SLA хостера. Для проекта подтвердите состав, глубину, время и доступ к завершенным архивам.

Общие правила независимой копии есть на странице backup. Приемку выполняйте отдельно, сохраняя рабочие файлы и изображения. Здесь ничего не удалялось и не импортировалось.

Порядок переключения и возврата разобран в руководстве переноса сайта: проверочная копия, финальные данные, DNS, почта и SSL принимаются отдельно.

Shared и VPS: разные обязанности

На shared уточните версии PHP и БД, расписание, ограничения процессов и загрузок. Для собственной службы нужно подтверждение возможности запуска, а не предположение по названию тарифа.

VPS требует обновлений ОС, управления доступом и служебными процессами. Узнайте, выполняет их хостер или ваша команда. Root расширяет возможности, но не дает готовую настройку ролей и закрытых документов.

Drupal здесь только пример механизмов портала. Версии его PHP/БД и совместимость тарифов не подтверждались; для внедрения нужны требования выбранного выпуска. CMS, пакеты и интеграции не устанавливались.

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