Битрикс: требования к хостингу и установка

Как понять, подходит ли хостинг для установки 1С-Битрикс?

Хостинг подходит для 1С-Битрикс, если одновременно соответствует требованиям CMS по PHP, СУБД, веб-серверу, расширениям PHP и рабочим лимитам. Проверять лучше до загрузки дистрибутива. Тогда проблема обнаружится на этапе выбора тарифа, а не после того, как сайт уже начали собирать.

На виртуальном хостинге большую часть параметров можно увидеть в панели: активную версию PHP, доступные модули, базы данных, лимит диска, настройки cron. Если тариф выбирается до покупки, эти же параметры стоит искать в техническом описании услуги или уточнять у поддержки.

На VPS первичная проверка начинается с нескольких команд:

php -v
php -m
php --ini
mysql --version
df -h
df -i

php -v показывает версию PHP в командной строке, php -m — загруженные расширения, mysql --version — версию клиента MySQL, а df помогает быстро исключить нехватку места и inode. Здесь есть ловушка: версия PHP в SSH ещё не доказывает, что сайт работает на той же версии.

Обычно проблема обнаруживается не на уровне «PHP есть или нет», а на один слой глубже. Версия подходящая, но не загружен нужный модуль. База создана, но сервер или кодировка не подходят. На аккаунте свободно несколько гигабайт, а отдельный PHP-процесс зажат маленьким memory_limit.

Ещё один характерный случай: панель хостинга показывает PHP 8.4, команда в SSH тоже показывает PHP 8.4, а системная проверка сайта видит другую версию. Тогда спорить с цифрами в панели бессмысленно — нужно выяснить, какой PHP реально обслуживает HTTP-запрос.

Надпись «поддерживает PHP и MySQL» сама по себе почти ничего не говорит. Нужны параметры окружения.

Какие версии PHP, базы данных и веб-сервера нужны 1С-Битрикс?

Для новой установки 1С-Битрикс нужно ориентироваться на актуальные требования производителя, а не на старую инструкцию из поиска. На сентябрь 2026 года минимальная версия PHP — 8.2, рекомендуемая — 8.4 и выше. Для MySQL минимальное требование — версия 8.0.

Старая статья по Битрикс может прекрасно находиться в поиске и при этом описывать уже мёртвый стек с PHP 7.x. На новый сервер такую конфигурацию переносить не стоит.

Какую версию PHP выбирать для Битрикс?

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

Проверить CLI-версию можно так:

php -v

На существующем сайте ситуация другая. Ядро Битрикс может быть готово к более новой версии PHP, а старый модуль Marketplace или собственный код — нет. Поэтому рабочий проект сначала обновляют и проверяют, делают резервную копию, а уже затем меняют PHP.

Что делать, если хостинг предлагает только старую версию PHP?

Если для новой установки доступна только версия PHP ниже текущего минимума Битрикс, продолжать установку на ней не стоит. Сначала нужно проверить, можно ли переключить PHP в панели, доступна ли нужная версия на другом тарифе или требуется перенос на другое окружение.

На уже работающем старом проекте нельзя просто поменять PHP и надеяться, что всё поднимется. Сначала проверяются версия ядра, обновления модулей и собственный код. Здесь две противоположные ошибки: годами держать CMS на устаревшем PHP или резко переключить рабочий сайт без проверки совместимости.

Если php -v показывает новую версию, а сам Битрикс видит старую, проблема уже не в системных требованиях. Скорее всего, CLI и веб-сайт используют разные обработчики или конфигурации PHP.

Какие СУБД подходят для Битрикс?

Для типовой установки используется MySQL 8.0 и выше. В актуальной конфигурации MySQL и MariaDB используется utf8mb4. Старую utf8mb3 для нового проекта выбирать не нужно.

Версию сервера удобнее проверять из самой базы:

SELECT VERSION();

Это точнее, чем ориентироваться только на вывод mysql --version: последняя команда показывает версию клиентской программы, а клиент и сервер не обязаны совпадать.

Если провайдер использует MariaDB, совместимость лучше подтверждать проверкой окружения конкретного проекта, а не делать вывод только по совместимому протоколу. PostgreSQL тоже нельзя считать универсальной заменой MySQL для любой редакции Битрикс.

Apache или Nginx — что требуется Битрикс?

1С-Битрикс работает с Apache и Nginx. На VPS часто встречается связка из нескольких компонентов: один сервер принимает запрос, другой слой передаёт PHP в PHP-FPM или обрабатывает динамическую часть по иной схеме. Само наличие Nginx проблемой не считается.

Проверить версии можно командами:

nginx -v
apache2ctl -v

На системах семейства RHEL вместо второй команды может использоваться:

httpd -v

Для сайта важнее не название веб-сервера, а корректная обработка PHP и маршрутов. Главная страница может открываться нормально, а /catalog/ или другая ЧПУ-страница возвращать 404. В таком случае версия PHP тут ни при чём — смотреть нужно rewrite и конфигурацию виртуального хоста.

Какие PHP-расширения и лимиты проверить перед установкой Битрикс?

Подходящая версия PHP — только половина проверки: Битрикс нужны PHP-расширения и достаточно свободные лимиты для обработки запросов, загрузки файлов и установки обновлений. Именно здесь появляется ситуация «PHP 8.4 есть, а проверка системы всё равно красная».

Среди используемых продуктом расширений — GD, XML, OpenSSL, Hash, mbstring, DOM, ZIP и драйвер выбранной СУБД. Некоторые дополнительные расширения требуются только отдельным модулям, поэтому устанавливать весь доступный набор PHP-модулей без разбора не нужно.

Посмотреть загруженные модули:

php -m

Для быстрой точечной проверки:

php -m | grep -Ei 'gd|mbstring|xml|openssl|dom|zip|mysqli|pdo_mysql'

В текущих рекомендациях серверного окружения Битрикс фигурируют, в частности, следующие значения PHP:

Эти параметры нельзя воспринимать как повод механически выкрутить всё ещё выше. Если установка падает с Allowed memory size exhausted, имеет смысл проверить память. Если соединение с базой получает отказ, увеличение memory_limit ничего не изменит.

Проверить значения в CLI можно так:

php -i | grep memory_limit
php -i | grep max_execution_time
php -i | grep max_input_vars
php -i | grep post_max_size
php -i | grep upload_max_filesize

Почему PHP в SSH и PHP сайта могут показывать разные настройки?

На VPS встречается классическая ловушка: php -i показывает нужный memory_limit, администратор считает вопрос закрытым, а сайт продолжает ругаться. Причина — CLI и PHP-FPM могут читать разные конфигурационные файлы.

Сначала смотрим конфигурацию CLI:

php --ini

Затем проверяем pool PHP-FPM и файлы конфигурации именно той версии PHP, которая обслуживает сайт. После изменения параметров PHP-FPM обычно требуется перезапуск или reload службы.

Для диагностики через браузер допустимо временно создать файл с phpinfo() и сравнить активный php.ini и значения параметров. После проверки файл нужно удалить: публичный phpinfo раскрывает слишком много сведений об окружении.

После установки Битрикс часть этой проверки удобнее делать встроенными средствами CMS, не оставляя диагностический файл в корне сайта.

Сколько CPU, RAM и места на диске действительно нужно сайту на Битрикс?

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

У Битрикс нет одной универсальной цифры RAM и CPU для корпоративного сайта, небольшого магазина и проекта с большим каталогом. Нагрузка складывается из PHP-процессов, СУБД, фоновых задач, кеша, операций с файлами и самой ОС.

Как понять, что Битрикс упирается именно в RAM?

Смотреть память нужно в момент проблемы. Если импорт уже закончился и нагрузка ушла, спокойный free -h мало что расскажет о том, что происходило пять минут назад.

free -h
top

В free -h смотрят не только поле free, но прежде всего доступную память и использование swap. Linux активно использует свободную RAM под кеш, поэтому само по себе маленькое значение free ещё не означает нехватку памяти.

Настораживает другая комбинация: во время тяжёлой операции доступной памяти почти не остаётся, активно растёт swap, а PHP-FPM и MySQL занимают основную часть RAM. Если процесс уже был убит ядром, это можно подтвердить системным журналом:

journalctl -k | grep -Ei 'oom|out of memory|killed process'

Запись об OOM — уже прямое подтверждение нехватки памяти на уровне VPS. Здесь увеличение memory_limit PHP способно сделать ситуацию хуже, а не лучше.

Как отличить нехватку CPU от медленного диска?

Высокая загрузка сервера ещё не означает, что ему «не хватает процессора». Во время backup или массового импорта процессы могут ждать диск, а CPU при этом не быть настоящим узким местом.

Сначала удобно посмотреть процессы:

top

Если доступен iostat, дисковую подсистему можно проверить отдельно:

iostat -xz 1

Интересен не один случайный снимок, а поведение во время проблемной операции. Если тормоза начинаются вместе с активным чтением и записью, нужно разбираться с I/O. Если ядра постоянно заняты PHP или MySQL, направление другое. Если CPU и диск выглядят спокойно, а запрос зависает на базе, стоит уже смотреть SQL и состояние СУБД.

Одна метрика редко даёт диагноз. Она только сужает поиск.

Сколько места оставлять для резервных копий?

Проверить файловую систему можно так:

df -h
df -i

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

Для Битрикс нужно учитывать не только текущий размер файлов сайта. Место занимают база, кеш, временные данные, загружаемые документы и резервные копии. Если backup формируется на том же разделе, свободного места должно хватить ещё и на создаваемый архив и промежуточные файлы.

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

Как проверять нагрузку во время импорта, индексации или backup?

Типичная ошибка — запустить импорт, увидеть тормоза, дождаться завершения и только потом открыть top. Сервер уже вернулся в норму, и диагностика ничего не показывает.

Откройте второй SSH-сеанс до начала тяжёлой операции и оставьте в нём мониторинг:

top

или, если установлен:

htop

Параллельно можно следить за памятью, диском и системным журналом. Смысл не в красивом графике, а в совпадении по времени: пользователь запускает импорт, админка начинает тормозить, и именно в этот момент видно, что произошло с PHP, MySQL, RAM и I/O.

Когда для Битрикс достаточно обычного хостинга, а когда нужен VPS?

Небольшой корпоративный сайт работает на обычном хостинге без ошибок, но владелец всё равно планирует VPS только потому, что «Битрикс тяжёлый». Здесь сначала стоит задать простой вопрос: какое конкретное ограничение должен снять VPS?

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

Сценарий 1: небольшой корпоративный сайт на Битрикс

Несколько десятков или сотен страниц, стандартные компоненты, нет тяжёлого товарного импорта, собственных демонов и необычных интеграций. Если такой сайт проходит системную проверку и не упирается в лимиты CPU, памяти и процессов, хороший shared-хостинг обычно закрывает задачу без отдельного VPS.

Переезд только ради root-доступа здесь редко что-то исправляет.

Сценарий 2: магазин с регулярным импортом и фоновыми задачами

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

Сначала стоит подтвердить ограничение: посмотреть статистику тарифа или серверные метрики во время пика. Если shared режет процессы, память или CPU и изменить это нельзя, VPS уже решает понятную проблему, а не выступает абстрактным «ускорителем Битрикс».

Сценарий 3: нужны свои PHP-FPM, СУБД или дополнительные службы

Если проекту требуется управлять pool PHP-FPM, менять системные настройки базы, ставить дополнительные пакеты, очереди, Redis или другие серверные службы, shared-хостинг может просто не дать такой возможности. Это уже нормальная причина выбирать VPS.

Но VPS придётся администрировать. Установить Linux и Nginx недостаточно: нужны обновления, резервное копирование, контроль диска, журналов, PHP-FPM и базы.

Root-доступ — это не производительность. Это контроль.

Отдельный вариант — готовое окружение BitrixVM/BitrixEnv. Оно снимает часть вопросов совместимости и содержит конфигурацию, ориентированную на продукты 1С-Битрикс. Установка и сопровождение такого окружения — самостоятельная тема.

Что подготовить на хостинге до запуска установщика Битрикс?

До запуска BitrixSetup нужно подготовить домен, PHP, каталог сайта, базу данных и права записи. Чем больше этих вещей проверено заранее, тем меньше потом ошибок вида «установщик не работает», за которыми на самом деле скрываются совершенно разные причины.

Подключить домен и проверить DNS

Домен должен указывать именно на сервер, где лежит будущий сайт. Проверить A- и AAAA-записи можно через панель DNS или командой:

dig example.com
dig www.example.com

Если IPv6 на сервере не настроен, но в DNS осталась старая AAAA-запись, часть пользователей может получать ошибки соединения. Поэтому смотреть стоит оба типа записей, если они существуют.

Не нужно механически ждать «24–72 часа» после любого изменения DNS. Время зависит от TTL, кешей резолверов и того, какие записи менялись. Практический критерий проще: проверяемые резолверы уже возвращают адрес нужного сервера.

Создать базу данных и отдельного пользователя

До запуска мастера подготовьте четыре значения:

• имя сервера базы данных;
• имя базы;
• имя пользователя;
• пароль.

На виртуальном хостинге база и пользователь обычно создаются в панели. Имя может автоматически получать префикс аккаунта — это нормально. В установщик нужно вводить итоговое значение, которое показывает панель.

На VPS подключение можно проверить до установки Битрикс:

mysql -h HOST -u USER -p DATABASE

Если команда с теми же реквизитами получает Access denied или не может подключиться к серверу, многократный запуск BitrixSetup ничего не изменит. Сначала исправляем host, порт, пароль, права или доступность MySQL.

С localhost тоже бывают ошибки. Если СУБД расположена на отдельном сервере, localhost будет указывать на текущую машину, а не на удалённую базу.

Проверить каталог сайта и права записи

Установщик должен создавать файлы в Document Root. На обычном хостинге права обычно уже настроены. На VPS после ручной загрузки проблема нередко выглядит так: bitrixsetup.php положили от root, а PHP-FPM работает от пользователя сайта. Файл виден, но дальнейшая запись ломается.

Проверить владельца и права:

ls -la
stat bitrixsetup.php

Если проблема находится выше по дереву каталогов, пригодится:

namei -l /var/www/example.com/bitrixsetup.php

Не надо лечить любую ошибку записи командой chmod -R 777. Инсталлятору нужна возможность создавать файлы, а не всем пользователям сервера — полный доступ ко всему дереву. На VPS правильнее исправить owner/group и схему работы PHP.

Как установить 1С-Битрикс на хостинг пошагово?

Для чистой установки 1С-Битрикс можно использовать официальный BitrixSetup или заранее загруженный дистрибутив. В обоих случаях сначала готовят окружение и пустую базу, а после установки обязательно проверяют сайт. Восстановление существующего проекта через backup — другой сценарий.

BitrixSetup или полный дистрибутив?

BitrixSetup удобен, когда сервер имеет нормальный исходящий доступ и проще позволить установщику получить файлы продукта самостоятельно. В этом случае в Document Root помещается небольшой установочный файл, а основная загрузка выполняется уже через него.

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

Для большинства обычных установок смысл выбора прост: BitrixSetup уменьшает объём ручной работы, полный архив даёт больше контроля над доставкой файлов. Ни один вариант не отменяет проверку PHP, базы и прав.

Пошаговая чистая установка

1. Выберите домен и PHP. Домен должен быть привязан к нужному каталогу, для сайта должна работать поддерживаемая версия PHP.
2. Создайте пустую базу. Сохраните имя БД, пользователя, пароль и адрес сервера MySQL.
3. Загрузите bitrixsetup.php или подготовьте дистрибутив. Файлы должны находиться в реальном Document Root.
4. Откройте мастер через браузер. Для BitrixSetup адрес выглядит как https://example.com/bitrixsetup.php.
5. Выберите продукт и дистрибутив. В этой статье рассматривается «1С-Битрикс: Управление сайтом».
6. Дождитесь загрузки и распаковки. На этом этапе важны свободный диск, права и сетевой доступ.
7. Пройдите проверку окружения. Критические несоответствия лучше исправить сразу.
8. Укажите реквизиты базы. Используйте заранее проверенные host, database, user и password.
9. Дождитесь создания структуры БД. Здесь уже одновременно работают PHP, база и файловая система.
10. Создайте администратора. Пароль администратора не должен совпадать с паролем базы.
11. Выберите решение или шаблон, если мастер предлагает этот этап.
12. Проверьте публичную и административную части.

Если есть SSH и сервер уже подготовлен, файл установщика можно получить непосредственно в Document Root. Например:

cd /var/www/example.com
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php

Путь приведён как пример. На конкретном VPS корень сайта может находиться в /var/www/html, /home/user/public_html или другом каталоге, указанном в виртуальном хосте.

Что не нужно делать при чистой установке?

Не смешивайте чистую установку с восстановлением старого проекта. Если никакой резервной копии нет, restore.php для этой задачи не нужен.

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

И ещё одно: не меняйте одновременно PHP, права, базу и конфигурацию Nginx в надежде, что «что-то поможет». После четырёх изменений уже трудно понять, какое из них действительно исправило проблему.

Что делать, если установка оборвалась после создания части таблиц?

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

Проверьте:

• появились ли файлы Битрикс в Document Root;
• созданы ли таблицы в базе;
• есть ли ошибка PHP или веб-сервера в момент остановки;
• не закончились ли место или inode;
• не было ли timeout или OOM.

Если это действительно чистая установка и база содержит только незавершённые данные от неудачного мастера, перед новой попыткой обычно проще вернуть окружение к чистому состоянию: устранить причину, очистить недоустановленный каталог и использовать пустую БД. Но делать это можно только когда точно известно, что в базе нет нужных данных существующего сайта.

После успешного завершения сделайте две быстрые HTTP-проверки:

curl -I https://example.com/
curl -I https://example.com/bitrix/admin/

Для главной ожидается нормальный HTTP-ответ без циклических редиректов и 5xx. Административная часть должна открыть авторизацию или перенаправить на неё.

Если установка остановилась на условных 30 или 50 процентах, сам процент почти ничего не диагностирует. Не нужно бесконечно нажимать Reload. Сначала выясните, на чём оборвался процесс: PHP, база, файлы или внешний запрос.

Почему установщик Битрикс не запускается или останавливается с ошибкой?

Ошибки установки Битрикс удобнее диагностировать по слоям: сначала HTTP и веб-сервер, затем PHP, файловая система, база данных и ресурсы. Белый экран или HTTP 500 сами по себе не называют причину.

500 Internal Server Error

HTTP 500 при запуске Битрикс нужно диагностировать по журналу ошибок, а не переустановкой CMS. На Nginx типичный путь выглядит так:

tail -n 100 /var/log/nginx/error.log

У Apache на Debian/Ubuntu часто используется:

tail -n 100 /var/log/apache2/error.log

На AlmaLinux, Rocky Linux и других системах семейства RHEL путь может быть другим, например /var/log/httpd/error_log. Поэтому путь лучше сверять с конфигурацией конкретного сервера.

Если запрос передаётся в PHP-FPM, смотрим и его журнал. Имя systemd-службы зависит от дистрибутива и способа установки PHP. Например:

systemctl list-units --type=service | grep -i fpm
journalctl -u php-fpm -n 100

Если служба называется php8.4-fpm, в journalctl нужно указывать именно это имя.

Полезно сопоставлять время ошибки в браузере с timestamp в журнале. Одна строка error.log в нужную секунду часто даёт больше информации, чем длинное описание «установщик просто перестал работать».

Битрикс не подключается к MySQL

Проверяем соединение теми же реквизитами вне установщика:

mysql -h HOST -u USER -p DATABASE

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

На shared-хостинге отдельный сервер базы может иметь имя вроде mysqlXX.provider.tld. Подставлять вместо него localhost только потому, что так было в другой инструкции, нельзя.

Установка завершается по timeout или memory limit

Если в PHP log есть строка с Allowed memory size exhausted, проверяем фактический memory_limit веб-версии PHP. Если встречается Maximum execution time exceeded, смотрим max_execution_time.

Nginx при слишком долгом ответе backend может записать upstream timed out. Но это ещё не означает, что нужно сразу увеличивать timeout Nginx. Сначала стоит понять, почему PHP отвечает так долго: запрос упёрся в базу, CPU, диск или действительно выполняет нормальную длительную операцию.

На маленьком VPS процесс может быть убит уже не PHP, а OOM Killer ядра Linux. Тогда в PHP log причина иногда вообще не успевает попасть. Проверить системный журнал можно так:

journalctl -k | grep -Ei 'oom|out of memory|killed process'

Если там есть запись об убийстве PHP-FPM или MySQL/MariaDB из-за нехватки памяти, увеличение одного memory_limit ситуацию только ухудшит. Узкое место находится на уровне всего VPS.

Что проверить сразу после установки Битрикс?

Главная страница открылась — это хороший знак, но ещё не доказательство, что установка закончена нормально. После мастера нужно проверить системную диагностику Битрикс, внутренние URL, HTTPS, загрузку файлов, почту, фоновые задания и резервное копирование.

Начните со встроенного инструмента «Настройки → Инструменты → Проверка системы». Если здесь остаются критические ошибки, лучше разобраться с ними до наполнения проекта.

Главная работает, а внутренние страницы дают 404

Такой симптом хорошо отделяет проблему маршрутизации от общей неисправности PHP. Если главная отвечает 200, административная часть открывается, а /catalog/ стабильно возвращает 404, сначала смотрят rewrite и настройки веб-сервера.

Проверить HTTP-ответы можно командой:

curl -I https://example.com/
curl -I https://example.com/catalog/
curl -I https://example.com/bitrix/admin/

Главная 200, каталог 404 — уже намного полезнее для диагностики, чем фраза «Битрикс работает неправильно».

Не загружаются изображения и файлы

Если административная часть работает, но загрузка файла завершается ошибкой, проверяются три группы причин: права на каталог назначения, временный каталог PHP и лимиты upload_max_filesize/post_max_size.

Если маленький файл загружается, а большой нет, это дополнительно указывает на лимиты запроса. Если не создаётся даже небольшой файл, больше внимания уделяем правам и временному каталогу.

Письмо не отправляется после установки

Не стоит сразу менять SPF, DKIM и DNS только потому, что письмо не пришло. Сначала нужно выяснить, произошло ли вообще отправление с сервера и каким способом приложение передаёт почту.

Если PHP не может передать сообщение локальной почтовой системе или SMTP, DNS домена ещё не объясняет первичную ошибку. Сначала транспорт и лог. Потом доставка.

Что такое агенты Битрикс и при чём здесь cron?

Часть фоновых задач Битрикс выполняется через механизм агентов. В зависимости от конфигурации их выполнение может быть связано с посещениями сайта или вынесено в cron. Для нагруженного проекта второй вариант часто удобнее, потому что выполнение фоновой работы не приходится ждать внутри пользовательского запроса.

На VPS текущий crontab пользователя можно посмотреть так:

crontab -l

Но эта команда показывает только задания текущего пользователя. Системные cron-задачи или systemd timers могут находиться в других местах.

Сам факт строки в crontab ничего не доказывает. Полезная проверка — убедиться, что задача действительно запускается нужным пользователем, использует правильный PHP и оставляет ожидаемый результат или запись в логе.

Первая резервная копия — тоже тест сервера

Backup проверяет сразу несколько вещей: свободный диск, права записи, продолжительность PHP-процессов, нагрузку на I/O и возможность читать все нужные файлы. Поэтому первую копию стоит сделать до того, как сайт наполнится данными и станет рабочим.

Если архив не создаётся, не нужно автоматически повышать timeout. Сначала смотрим конкретную ошибку и состояние диска.

После этих тестов полезно открыть error log и посмотреть, что происходило в фоне. Пользователь мог не увидеть ни одной ошибки в браузере, а журнал уже заполняется повторяющимися warning или сообщениями стороннего модуля.

Как выбрать хостинг для Битрикс без переплаты и скрытых ограничений?

Хостинг для Битрикс лучше выбирать по проверяемым параметрам окружения, а не по надписи «оптимизировано для CMS». Полезнее получить конкретные версии, лимиты и возможности тарифа, чем общее обещание совместимости.

• какая версия PHP доступна сейчас;
• можно ли самостоятельно переключать PHP;
• какие PHP-расширения включены;
• какая версия MySQL или другой СУБД используется;
• какой memory_limit доступен;
• можно ли менять необходимые параметры PHP;
• есть ли cron;
• какие ограничения CPU, RAM и процессов действуют на shared-хостинге;
• есть ли отдельный лимит I/O или inode;
• как подключается SSL;
• какой объём диска входит в тариф;
• как создаются и хранятся резервные копии.

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

Если shared-хостинг проходит системную проверку, но сайт всё равно медленный, это не противоречие. Проверка совместимости отвечает на вопрос «может ли Битрикс работать в этом окружении». Она не отвечает на вопрос «хватает ли этому магазину CPU, RAM, I/O и лимитов процессов во время импорта».

То же с VPS. Миграция на более дорогой сервер не исправит медленный SQL-запрос, конфликтующий модуль или ошибочную конфигурацию PHP. Мощность добавится, причина останется.

Чек-лист: готов ли сервер к установке Битрикс?

Не «сервер должен потянуть Битрикс», а вполне проверяемая картина: совместимый PHP, подходящая СУБД, нужные модули, рабочие права, понятные лимиты и запас ресурсов под конкретные операции сайта.

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