Сайты на Debian 11 продолжают открываться, но актуальная HestiaCP эту систему уже не поддерживает. Практичный способ переезда — подготовить отдельный VPS, восстановить на нём пользователей из резервных копий, проверить сайты и почту и только затем переключить домены. Старый сервер понадобится до завершения переноса свежих данных.
Что изменилось и какую ОС выбрать
В HestiaCP 1.10.5, выпущенной 14 сентября 2026 года, удалена поддержка Debian 11 Bullseye. Кроме того, 31 августа 2026 года закончилась стандартная LTS-поддержка Debian 11: с сентября проект Debian больше не выпускает для него обновления безопасности. Сторонняя расширенная поддержка отдельных пакетов не возвращает совместимость с актуальной HestiaCP.
Это не означает немедленного отключения установленной панели. Однако откладывать обновление окружения на неопределённый срок уже не стоит. По текущим требованиям HestiaCP подходит чистая установка Debian 12 или 13, а также Ubuntu 22.04, 24.04 или 26.04 LTS. Выбирайте систему, для которой доступны нужные сайту версии PHP, расширения и компоненты базы данных.
Обновление Debian на работающем VPS возможно, но затрагивает сразу панель, веб-сервер, базу и почту. В документации HestiaCP отдельно предупреждают о рисках такого обновления. Новый VPS удобнее для поэтапного переноса: старое окружение остаётся доступным для сравнения и восстановления. Расходы — временная аренда двух серверов, место для копий и работа администратора. Полное клонирование старого диска само по себе задачу не решает: вместе с данными переедет Debian 11.
Что проверить до заказа нового VPS
Этот порядок рассчитан на перенос HestiaCP → HestiaCP, когда есть SSH-доступ с правами root или sudo к обоим серверам, доступ к управлению DNS и возможность настроить PTR у владельца нового IP. Для внешней почты или внешней базы данных нужен отдельный план: пользовательский архив панели не переносит сторонний сервис.
| Что записать | Где посмотреть | Зачем это нужно |
|---|---|---|
| Пользователи, домены и поддомены | Разделы пользователей и WEB в HestiaCP | Восстанавливать лучше под прежними именами пользователей, чтобы сохранить пути и имена баз. |
| PHP, расширения, Apache или Nginx, собственные шаблоны | Настройки каждого веб-домена и конфигурация сервера | Версия PHP в командной строке может отличаться от версии конкретного сайта. |
| Базы данных и подключения к ним | Раздел DB и конфигурационные файлы приложений | Нужно знать тип СУБД, её версию и расположение базы. Замена MySQL на MariaDB требует проверки совместимости. |
| Почтовые ящики, алиасы, пересылки, фильтры | Раздел MAIL, Roundcube и настройки почтовых клиентов | Перенос писем не подтверждает перенос адресной книги и всех пользовательских настроек. |
| Фоновые задания и внешние связи | CRON, службы systemd, очереди приложения, настройки платёжных и других интеграций | Две копии сайта не должны одновременно рассылать письма, обрабатывать заказы или списывать оплату. |
Проверьте свободное место на старом сервере. Если каталог резервных копий изменён, вместо /backup используйте его фактический путь:
df -h /home /backup
sudo du -sh /home/*В стандартной схеме HestiaCP проверка места для резервного копирования учитывает удвоенный объём данных пользователя. Это запас для процесса создания копии, а не обещание размера готового архива. На новом VPS одновременно должны помещаться ОС, восстановленные данные, архив и временные файлы. Если места не хватает, сначала подготовьте дополнительное хранилище; не исключайте почту или базу из единственной копии ради уменьшения архива.
Для подбора VPS HSTQ передайте объём сайтов и почты, размер баз, текущую нагрузку и список компонентов. Отдельно согласуйте условия работы почтового сервера, PTR и необходимую помощь с миграцией. Работы инженера, их объём и стоимость согласуются отдельно от базовой аренды VPS.
Подготовьте новый сервер и сохраните настройки вне архива
Устанавливайте HestiaCP на чистую ОС по актуальной инструкции HestiaCP. При установке сохраните нужный состав служб: например, сайт с правилами в .htaccess нельзя без проверки переносить с Apache на один Nginx. Для собственной почты нужны Exim и Dovecot. Рекомендованные панелью 4 ядра и 4 ГБ RAM — ориентир для окружения, а ресурсы конкретного проекта определяются его нагрузкой.
Задайте новому серверу отдельное полное имя, например panel-new.example.com, направьте его A-запись на новый IP и настройте сертификат панели. Рабочие домены сайтов пока оставьте на старом сервере. Если сайты принадлежат старому пользователю admin, удобно выбрать другое имя администратора при новой установке, чтобы избежать совпадения учётных записей.
Отдельно сохраните собственные шаблоны из /usr/local/hestia/data/templates/web/, настройки SMTP-реле, firewall, дополнительные службы и изменения системных конфигураций. Не переносите каталог /etc целиком поверх новой системы: старые настройки могут быть несовместимы с новыми версиями программ.
Пользовательские веб-шаблоны могут находиться в архиве HestiaCP, но автоматически не восстанавливаются. Перенесите нужные шаблоны вручную, проверьте совместимость и выберите их в настройках домена. Правки только в сгенерированном конфигурационном файле ненадёжны: при перестроении домена панель создаёт его заново из шаблона.
В Roundcube экспортируйте важные адресные книги через «Контакты → Экспорт» в файлы vCard. После переезда их можно импортировать и сверить количество записей. Подписи, фильтры и плагины также проверьте отдельно. Архив писем и адресная книга — разные данные.
Создайте архив и выполните пробное восстановление
Ниже client — пример имени пользователя HestiaCP, BACKUP_FILE.tar — точное имя созданного архива, NEW_IP — адрес нового VPS. Замените их своими значениями. Команды создания копии выполняются на старом сервере:
sudo /usr/local/hestia/bin/v-backup-user client
sudo ls -lh /backup/client.*.tarДождитесь завершения команды. Проверьте дату архива и исключения в разделе резервного копирования пользователя: нужные домены, базы и почтовые ящики должны входить в копию. Наличие файла ещё не доказывает возможность восстановления.
На новом сервере подготовьте каталог:
sudo mkdir -p /backupЗатем со старого сервера передайте архив по SSH. Пример предполагает разрешённый вход root по ключу; при другой политике доступа используйте административную учётную запись и sudo на целевом сервере.
sudo scp /backup/BACKUP_FILE.tar root@NEW_IP:/backup/Выполните на обоих серверах:
sudo sha256sum /backup/BACKUP_FILE.tarХеши должны совпасть. Разные значения означают, что получена другая или повреждённая копия: передачу нужно повторить. Ещё один экземпляр архива сохраните вне старого VPS, в закрытом хранилище.
На новом сервере восстановите пользователя, пока без заданий cron:
sudo /usr/local/hestia/bin/v-restore-user client BACKUP_FILE.tar '*' '*' '*' '*' no '*'Аргументы после имени архива соответствуют WEB, DNS, MAIL, DB, CRON и UDIR. Значение no пропускает восстановление cron; остальные разделы выбраны целиком. Кавычки вокруг звёздочек обязательны. Отсутствующего пользователя панель создаёт сама.
После восстановления сравните списки доменов, баз и почтовых ящиков с исходными. Если команда завершилась ошибкой, часть объектов могла восстановиться, а часть — нет. Сохраните сообщение об ошибке и устраните причину до переключения доменов.
Этот вариант предотвращает запуск восстановленных заданий cron, но не отключает встроенный планировщик сайта или самостоятельно установленные обработчики очередей. Тестовую копию держите закрытой от посетителей, а её интеграции переведите в тестовый режим. При конфликте домена с другим пользователем сначала разберитесь с владельцем; удалять существующую учётную запись наугад нельзя.
Проверьте сайты и службы до изменения DNS
На своём компьютере временно добавьте в файл hosts новый IP и рабочие имена сайта:
203.0.113.20 example.com www.example.comАдрес здесь условный. В Linux и macOS файл находится в /etc/hosts, в Windows — в C:\Windows\System32\drivers\etc\hosts. Изменение действует только на вашем компьютере. Открывайте сайт по домену: запрос по одному IP может показать другой виртуальный хост.
Для отдельной проверки HTTPS можно обойтись без редактирования файла:
curl --resolve example.com:443:203.0.113.20 -I https://example.com/Ожидается нормальный ответ сайта или предусмотренное перенаправление, без ошибки проверки сертификата. Код 200 подтверждает доступность страницы, но не работу магазина или CRM. Проверьте вход в кабинет, запись в базу, загрузку файла, поиск и тестовый сценарий заказа. Реальные списания и рассылки на пробной копии отключите. Если сайт возвращает 500, откройте журналы домена в разделе WEB и сравните PHP, расширения, шаблон и параметры подключения к базе с прежним сервером.
Отдельно проверьте почтовые службы:
sudo systemctl status exim4 dovecot --no-pager
sudo doveconf -nСлужбы должны работать, а Dovecot — читать конфигурацию без ошибок. Если он не запускается, подробности покажет sudo journalctl -u dovecot -n 50 --no-pager. Ошибка конфигурации требует исправления до переключения почты; изменением MX её не устранить.
Для HestiaCP 1.10.5 есть отдельный повод внимательно проверить восстановление на Dovecot 2.4: в исходнике v-restore-user присутствует параметр sssl_server_cert_file с лишней буквой. Если журнал указывает именно на него, остановите миграцию и проверьте исправление для установленной версии панели. Если исправленного пакета ещё нет, для чистого целевого VPS можно рассмотреть поддерживаемый Debian 12 со штатным Dovecot 2.3 и заново проверить восстановление. До этого старый сервер оставьте основным.
Как перенести письма, пришедшие после создания копии
Пользовательский архив переносит почтовые данные на момент копирования. Пока вы восстанавливаете и проверяете новый сервер, на старом могут появиться новые письма. Поэтому нужен отдельный завершающий перенос сообщений.
В обсуждении миграции 150 ГБ почты на форуме HestiaCP пользователь сначала восстановил архив, для которого пришлось добавить диск, а затем синхронизировал изменения через Dovecot. Его опыт показывает, зачем отделять основное копирование от переноса новых писем; указанное в обсуждении время не подходит для расчёта любой другой миграции.
Для ящиков с известными паролями можно использовать imapsync. Он копирует письма и папки по IMAP и допускает повторные запуски. Почтовые аккаунты и их настройки предварительно восстанавливаются через HestiaCP. При неизвестных паролях потребуется отдельная настройка административного доступа или перенос средствами Dovecot: универсальную команду для любых его версий применять нельзя.
Пример ниже рассчитан на установленный imapsync, доступный IMAPS на обоих серверах и действующие сертификаты. Имена old-mail.example.com и new-mail.example.com должны постоянно вести на разные, соответствующие серверы и быть покрыты их сертификатами. Пароли сохраните редактором в два отдельных файла в /root, по одному паролю в первой строке:
sudo chmod 600 /root/mail-old.pass /root/mail-new.pass
sudo imapsync \
--host1 old-mail.example.com --ssl1 \
--user1 user@example.com --passfile1 /root/mail-old.pass \
--host2 new-mail.example.com --ssl2 \
--user2 user@example.com --passfile2 /root/mail-new.pass \
--sslargs1 SSL_verify_mode=1 \
--sslargs2 SSL_verify_mode=1 \
--dryСначала проверьте пробный запуск с --dry: подключение, авторизацию и соответствие папок. Ошибки входа или TLS исправьте до копирования, не отключая проверку сертификатов. Затем уберите только --dry и повторите команду для переноса. В итоговом отчёте должны быть успешное завершение, ноль ошибок и подтверждение, что все распознанные сообщения источника присутствуют на приёмнике. Проверьте старые и новые письма с вложениями в нескольких папках. Файлы с паролями удалите после завершения всех синхронизаций.
Используйте направление со старого сервера на новый, без параметров удаления сообщений. Не организуйте таким способом постоянную работу пользователей в двух копиях одного ящика. На время переключения приостановите почтовые клиенты, затем подключите их к новому серверу. Старый может ещё принимать письма от отправителей с закэшированным DNS: такие сообщения нужно дополнительно перенести. Контакты, календари и письма, оставшиеся только в локальном POP3-архиве компьютера, через IMAP не переедут.
Финальное переключение: одна рабочая копия сайта
Заранее уменьшите TTL изменяемых DNS-записей, например до 300 секунд, если это позволяет DNS-провайдер. TTL задаёт срок кэширования ответа. После уменьшения нужно выждать прежний TTL: уже сохранённые ответы не исчезают немедленно. Это сокращает переходный период, но не гарантирует переключение всех клиентов за пять минут.
- На старом сайте включите режим обслуживания, запрещающий изменения. Остановите его cron, обработчики очередей, импорты и другие источники записи. Продумайте приём или повторную обработку уведомлений платёжных систем: одной заглушки для браузера недостаточно.
- Создайте свежий архив пользователя, перенесите его и повторите восстановление на новом VPS с пропуском cron. На этом этапе новый сайт ещё не должен принимать рабочие заказы или изменения пользователей.
- Проверьте последнюю запись в базе и последние загруженные файлы. Повторное восстановление может вернуть настройки из архива: снова проверьте IP, PHP, шаблоны и тестовые ограничения интеграций.
- После этого выполняйте завершающую синхронизацию почты и переключайте DNS. Разрешите рабочие изменения только на новом сайте. Старый сайт оставьте в режиме обслуживания, пока к нему ещё могут обращаться клиенты.
- В разделе CRON нового пользователя добавьте задания из сохранённого списка, сверив пути, версию PHP и расписание. Включите их и запустите очереди только на новом сервере; на старом они должны оставаться выключенными.
После начала работы пользователей на новом VPS не накатывайте на него полный старый архив. Восстановление базы заменяет её содержимое, поэтому так можно потерять новые заказы и изменения. Для следующих проходов переносите только необходимые новые данные выбранным инструментом.
Если повторный полный архив слишком велик для допустимого окна обслуживания, заранее разрабатывайте раздельный перенос файлов, базы и почты. Короткое окно достигается предварительным копированием и финальной синхронизацией; длительность определяют объём изменений, скорость дисков и требования приложения.
Какие DNS-записи и почтовые настройки менять
Редактируйте записи у действующего DNS-провайдера. Наличие зоны в HestiaCP не означает, что именно она обслуживает домен. Проверить назначенные серверы имён можно командой dig +short NS example.com.
| Настройка | Что сделать и проверить |
|---|---|
| A и AAAA сайтов | Укажите новые адреса для домена, www и нужных поддоменов. Если IPv6 не используется, старую AAAA нельзя оставлять направленной на прежний сервер. |
| MX и адрес почтового узла | MX содержит имя сервера. Если оно остаётся прежним, например mail.example.com, обычно меняется его A/AAAA. При внешнем почтовом сервисе его MX сохраняются. |
| PTR | Настройте обратную запись у провайдера IP. Имя из PTR должно разрешаться обратно в тот же адрес. При отправке по IPv6 проверяйте и его. |
| SPF | Разрешите фактические источники отправки. Пока оба сервера законно отправляют почту, учитывайте оба; после завершения исключите старый. Не создавайте вторую отдельную SPF-запись. |
| DKIM и DMARC | Сверьте опубликованный DKIM-ключ с ключом нового сервера. Проверьте результат подписи и соответствие домена отправителя политике DMARC. Не ослабляйте политику вместо исправления ошибки. |
| TLS и почтовые клиенты | Проверьте сертификаты сайта, панели, SMTP и IMAP, включая имена, которые используют сотрудники. Работающий HTTPS сайта не подтверждает исправность TLS почты. |
Если DNS обслуживается на переезжающем VPS через собственные ns1/ns2, отдельно перенесите зоны и проверьте адреса серверов имён у регистратора, включая glue-записи. При DNSSEC согласуйте ключи и DS-запись. Старый DNS-сервер нельзя выключать только потому, что сайты уже открываются с нового IP.
До переключения почты убедитесь, что провайдер разрешает нужные соединения SMTP, включая порт 25 для прямого обмена между почтовыми серверами. Для проверки исходящего соединения с нового VPS можно выполнить nc -vz -w 5 ASPMX.L.GOOGLE.COM 25, если установлен netcat. Ответ succeeded подтверждает TCP-соединение; тайм-аут требует проверки сети, firewall и ограничений провайдера. Если исходящий порт закрыт, потребуется его разблокировка или настроенное SMTP-реле; повторный импорт ящиков это не исправит.
Когда можно отключить старый VPS
После изменения DNS удалите временные записи из своего файла hosts и повторите проверки через обычное подключение. Для прямого размещения команды ниже должны показывать новые адреса и нужный почтовый узел:
dig +short A example.com
dig +short AAAA example.com
dig +short MX example.com
dig +short A mail.example.com
dig +short -x 203.0.113.20При использовании CDN внешний A-ответ может содержать адрес CDN: адрес исходного сервера проверяется в его настройках. Отправьте письма с нового VPS на внешние ящики и ответы обратно. Проверьте доставку, папку «Спам» и результаты SPF, DKIM, DMARC в заголовках. Успешный обмен между двумя локальными ящиками не проверяет внешнюю доставку.
Посмотрите очередь исходящей почты командой sudo exim4 -bp на обоих серверах. Неудалённые сообщения в очереди требуют разбора; ошибки доставки ищите в /var/log/exim4/mainlog. Старый VPS должен оставаться доступным, пока туда ещё приходят письма, а их завершающий перенос не подтверждён.
Универсального срока «через сутки можно удалить» нет. Завершение определяется проверками: сайты сохраняют новые данные на новом сервере, задания работают в одном экземпляре, внешняя почта проходит в обе стороны, остаточные письма перенесены, новый резервный архив создан и проверен восстановлением. Срок параллельной аренды согласуйте заранее, оставив время на исправления.
Если проблема найдена до появления новых рабочих данных, можно сохранить старый сервер основным и отложить переключение. Если новый VPS уже принял заказы или письма, сначала остановите изменения и сохраните данные с обоих серверов. Возврат одного DNS-адреса не объединит две разошедшиеся базы: перенос новых записей обратно потребует отдельного плана. Поэтому старый VPS и независимую резервную копию удаляют последними.
