Полное руководство по миграции сервера Virtualmin: решение типичных ошибок и ограничений

Введение

Перенос с одного VPS на другой с Virtualmin запущенными 10+ доменами WordPress в теории выглядит просто: резервная копия на старом сервере, восстановление на новом — и готово. На деле это минное поле из скрытых системных лимитов, ограничений файловых дескрипторов и проблем с местом на диске, из-за которых можно застрять на много часов.

Недавно я завершил непростую миграцию Virtualmin с Debian 12 VPS во Франции на новый Debian 13 VPS в Нидерландах, перенеся более 4,4 ГБ резервных копий по более чем 10 доменам. В процессе я столкнулся со всеми основными ошибками, с которыми сталкиваются администраторы Virtualmin, — и решил их все. В этой статье описаны конкретные проблемы и решения, чтобы вам не пришлось учиться на своих ошибках.

Меняете ли вы провайдера VPS, масштабируетесь горизонтально или восстанавливаетесь после отказа сервера — это руководство проведёт вас через реальные ошибки и способы их устранения.

---

Часть 1: Планирование и подготовка к миграции

Выбор характеристик целевого VPS

Прежде чем что-либо трогать на текущем сервере, убедитесь, что у нового VPS хватает ресурсов. Частая ошибка — считать, что важен только объём диска. Это не так.

Минимальные характеристики для Virtualmin с 10+ доменами:

• Место на диске: 100 ГБ (не 50 ГБ — сайты WordPress с резервными копиями растут быстро)
• CPU: 6+ ядер (для 10+ доменов рекомендуется 8+ ядер)
• RAM: 8 ГБ минимум (15 ГБ+ для продакшена)
• Swap: 4 ГБ (добавляется после установки ОС, если не настроено заранее)

Новый сервер должен не уступать старому по CPU и RAM, а по месту на диске — превосходить его. При восстановлении Virtualmin сильно нагружает CPU и дисковую подсистему — слабый процессор заставит восстановление ползти.

Чек-лист перед миграцией

На старом сервере (за 48 часов до миграции):

1. Уменьшите DNS TTL до 300 секунд (5 минут), чтобы снизить проблемы с кэшем:

virtualmin modify-dns --all-domains --ttl 300

2. Создайте новую резервную копию в рекомендуемом формате Virtualmin:

mkdir /backup
virtualmin backup-domain \
  --dest /backup/ \
  --all-domains \
  --all-features \
  --newformat

3. Проверьте целостность резервной копии перед переносом:

tar -tzf /backup/backup_*.tar.gz > /dev/null && echo "Backup OK" || echo "Backup corrupted"

4. Запишите размеры баз данных для планирования:

mysql -e "SELECT table_schema AS 'Database', ROUND(SUM(data_length+index_length)/1024/1024,2) AS 'Size_MB' FROM information_schema.TABLES GROUP BY table_schema;"

5. Проверьте нестандартные настройки, которые могут не перенестись:
   • Собственные версии PHP
   • Изменённые конфигурации NGINX
   • Задания cron в /etc/cron.d/
   • Собственные сертификаты SSL

---

Часть 2: Процесс миграции

Шаг 1: Перенос файла резервной копии

Используйте SCP с контрольными суммами чтобы проверить целостность файлов:

# На старом сервере создайте контрольную сумму
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Перенесите копию и контрольную сумму
scp /backup/backup_*.tar.gz [email protected]:/Files/
scp /backup/backup.sha256 [email protected]:/Files/

# На новом сервере проверьте
cd /Files/
sha256sum -c backup.sha256

Если контрольные суммы не совпадают, немедленно остановитесь. Файл повредился при передаче. Перенесите его заново или используйте rsync с контрольными суммами:

rsync -avz --checksum /backup/backup_*.tar.gz [email protected]:/Files/

Шаг 2: Установка Virtualmin на новый сервер

Используйте официальный установщик Virtualmin:

curl https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh | sh

Важно: Устанавливайте ту же версию ОС (или близкую) — это важнее, чем кажется. Я мигрировал с Debian 12 на Debian 13 (не рекомендуется, но работоспособно). По возможности держитесь одной мажорной версии.

Шаг 3: Настройка системы перед восстановлением

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

Решение 1: увеличьте лимит открытых файловых дескрипторов

Это главная причина ошибок “No space left on device” при восстановлении, даже когда места на диске в избытке.

# Текущий лимит
ulimit -n
# Вероятно покажет: 1024 (слишком мало для Virtualmin)

# Увеличьте для текущей сессии
ulimit -n 65536

# Проверьте
ulimit -n
# Должно показать: 65536

# Сделайте постоянным
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536
EOF

Почему 65536? Каждый открытый файл, сокет, канал и подключение к базе данных занимают один файловый дескриптор. При 10+ сайтах WordPress, почтовых серверах, рабочих процессах NGINX и подключениях MySQL вы легко превысите 1024. OVH и другие провайдеры задают этот консервативный лимит по умолчанию ради безопасности — его предполагается повышать для каждого приложения.

Решение 2: увеличьте /tmp (tmpfs)

При восстановлении Virtualmin создаёт дампы MySQL в /tmp/. По умолчанию /tmp — это tmpfs (диск в RAM) с ограничением ~50% от общего объёма RAM. При 11 ГБ RAM /tmp он достигает максимума ~5,8 ГБ. Но Virtualmin легко создаёт 5–6 ГБ временных файлов при восстановлении.

# Текущий размер /tmp
df -h /tmp

# Измените размер на лету без размонтирования
mount -o remount,size=8G /tmp

# Проверьте
df -h /tmp

# Сделайте постоянным
echo "tmpfs /tmp tmpfs size=8G,mode=1777 0 0" >> /etc/fstab

Решение 3: добавьте swap

Если восстановление съест всю RAM, система перестанет отвечать. 4 ГБ swap дают запас прочности:

# Создайте файл swap на 4 ГБ
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Сделайте постоянным
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Проверьте
swapon --show

---

Часть 3: Процесс восстановления и типичные ошибки

Ошибка 1: “Checking contents of the backup ..” зависает на 20+ минут

Как это выглядит:

Checking contents of the backup ..

[застревает на 15–30 минут без прогресса]

Причина: Это не зависание — просто действительно медленно. Проверка tar -tzf в Virtualmin читает весь сжатый архив объёмом 4,4 ГБ, проверяет заголовки всех файлов и целостность tar. На старых CPU (например, Haswell) для копии на 4 ГБ это может занять 20+ минут.

Решение:

1. Не паникуйте. Проверьте, действительно ли tar работает:

ps aux | grep tar
iostat -x 1  # Проверьте активность диска

2. Используйте восстановление через CLI вместо веб-интерфейса (обходит тайм-аут проверки):

screen -S restore
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --all-domains \
  --all-features \
  --reuid

Этот --reuid автоматически корректирует ID пользователей и групп — это критично при восстановлении на разные системы.

Ошибка 2: “/bin/tar: Cannot write: No space left on device”

Как это выглядит:

/bin/tar: ./seo.grahammiranda.com_mail_users: Cannot write: No space left on device
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: Cannot write: No space left on device

[ещё десятки таких ошибок]

/bin/tar: Exiting with failure status due to previous errors

Что сбивает с толку: У вас свободно 75 ГБ, но сообщение говорит “No space left on device.”

Основные причины (в порядке вероятности):

1. Достигнут лимит файловых дескрипторов (самое частое)
   • Симптом: Ошибки появляются через 5–10 минут после начала восстановления, а не сразу
   • Решение: ulimit -n 65536 (описано выше)
2. /tmp заполняется (второе по частоте)
   • Симптом: В ошибках упоминаются MySQL или временные файлы
   • Проверьте: df -h /tmp во время восстановления — смотрите, как он заполняется до 100%
   • Решение: mount -o remount,size=8G /tmp (описано выше)
3. Заканчивается реальное место на диске (реже, но возможно)
   • Проверьте: df -h / показывает <5 ГБ свободно
   • Решение:

# Уберите следы неудачного восстановления
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/

# Если копия всё ещё в /Files, подумайте о её переносе
mv /Files/backup_*.tar.gz /mnt/  # Перенесите на другой раздел, если он есть

4. Исчерпание inode (редко)
   • Проверьте: df -i / показывает >90% iUsed
   • Причина: Файловая система создана со слишком малым числом inode
   • Решение: Переформатируйте файловую систему с большим числом inode (уничтожит данные)

Как диагностировать во время восстановления:

Откройте второй терминал и следите в реальном времени:

watch -n 2 'df -h / && echo "---" && df -h /tmp && echo "---" && du -sh /tmp/* 2>/dev/null | sort -rh | head -5'

Так видно, когда и где вы упираетесь в лимит.

Ошибка 3: NGINX не запускается после восстановления

Сообщение об ошибке:

nginx[34392]: [emerg] 34392#34392: open() "/etc/nginx/snippets/block-manager.conf" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed

Причина: Восстановление прошло частично, или часть файлов перенеслась неправильно. Конфигурации NGINX ссылаются на файлы, которых нет.

Решение:

1. Создайте недостающий файл:

mkdir -p /etc/nginx/snippets
touch /etc/nginx/snippets/block-manager.conf

2. Проверьте конфигурацию NGINX:

nginx -t

3. Запустите NGINX:

systemctl start nginx
systemctl status nginx

Если файлу нужно реальное содержимое, посмотрите на старом сервере:

scp old-server.com:/etc/nginx/snippets/block-manager.conf /etc/nginx/snippets/

---

Часть 4: Продвинутые решения и оптимизация

Восстановление по одному домену (самый безопасный подход)

Если полное восстановление продолжает сбоить, несмотря на исправления, восстанавливайте выборочно:

# Уберите следы прошлых неудачных попыток
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Сначала восстановите только основной домен
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --domain grahammiranda.com \
  --all-features \
  --reuid

Так видно, у каких доменов есть проблемы. Если один восстанавливается успешно, тот же подход работает и для остальных.

Особенности миграции с Debian 12 на Debian 13

Я мигрировал с Debian 12 на Debian 13. В целом они совместимы, но обратите внимание на:

1. Различия версий PHP: В Debian 12 может быть PHP 8.1, в Debian 13 — 8.3
   • Проверьте: php -v на обоих серверах
   • Проблема: Редкие проблемы совместимости со старыми расширениями PHP
   • Решение: Принудительно задайте старую версию PHP: virtualmin modify-web --domain example.com --php-version 8.1
2. Синтаксис конфигурации NGINX/Apache: Обычно совместим, но проверьте после восстановления
   • Проверка: nginx -t и apache2ctl configtest
3. Совместимость MySQL/MariaDB: Как правило, совместимы при обновлении
   • Проверьте: mysql --version на обоих серверах
   • Различия форматов дампов: Редко, но в более новой версии Debian режимы SQL могут быть строже
4. Совместимость сертификатов SSL: Между версиями Debian проблем нет, но проверьте:

certbot certificates  # Проверьте сертификаты Let's Encrypt

---

Часть 5: Проверка после миграции

Критические проверки перед запуском

После завершения восстановления проверьте, что всё работает:

# 1. Список всех восстановленных доменов
virtualmin list-domains

# 2. Проверьте доступность сайтов
curl -I https://yourdomain.com

# 3. Проверьте работу почты
mysql -u root -p'password' -e "SELECT user FROM mysql.user;"

# 4. Проверьте DNS
dig yourdomain.com @localhost

# 5. Проверьте модуль Virtualmin
virtualmin test-domain --domain yourdomain.com

# 6. Следите за ошибками в журналах
journalctl -f
tail -f /var/log/nginx/error.log

Обновите записи DNS

Когда все домены восстановятся успешно:

1. Обновите серверы имён у регистратора чтобы они указывали на новый сервер
2. Следите за обратным отсчётом TTL (при сокращённом TTL это займёт 5 минут)
3. Проверьте из разных точек:

nslookup yourdomain.com
dig yourdomain.com +short

4. Верните обычное значение DNS TTL через 24–48 часов:

virtualmin modify-dns --all-domains --ttl 3600

---

Часть 6: Справочник по системным лимитам

Для справки: вот все системные лимиты, которые проверялись во время этой миграции:

# Лимиты пользователя и процессов
ulimit -a                              # Все лимиты
ulimit -n                              # Открытые файлы
ulimit -u                              # Максимум процессов
ulimit -v                              # Виртуальная память

# Системные лимиты
cat /proc/sys/fs/file-max              # Открытые файлы в системе
cat /proc/sys/kernel/pid_max           # Максимум PID
cat /proc/sys/vm/max_map_count         # Лимит карт памяти

# Текущее использование ресурсов
df -h                                  # Место на диске
df -i                                  # Использование inode
free -h                                # RAM и swap
ps aux | wc -l                         # Запущенные процессы
lsof | wc -l                           # Открытые файловые дескрипторы

# Особенности файловой системы
mount | grep /dev/sda1                 # Параметры монтирования
quota -s                               # Дисковые квоты
tune2fs -l /dev/sda1                   # Свойства файловой системы

---

Главное

1. OVH (и большинство провайдеров) задают консервативные значения по умолчанию. Перед восстановлением резервных копий Virtualmin нужно поднять лимиты файловых дескрипторов.
2. Настоящий враг — системные лимиты, а не место на диске. Даже при 75 ГБ свободного места вы получите “No space left on device”, если /tmp заполнен или файловые дескрипторы исчерпаны.
3. Увеличьте /tmp размер перед восстановлением. Virtualmin создаёт 5–6 ГБ временных файлов при восстановлении резервных копий. Выделенного по умолчанию tmpfs недостаточно.
4. Используйте восстановление через CLI, а не веб-интерфейс. В веб-интерфейсе большие копии приводят к тайм-аутам. Восстановление из командной строки надёжнее и показывает реальный прогресс.
5. Миграция с Debian 12 на Debian 13 работает, но в пределах одной версии безопаснее. Различия минорных версий редко вызывают проблемы, но по возможности оставайтесь в пределах одной мажорной версии.
6. Проверяйте целостность резервной копии перед переносом. Используйте контрольные суммы SHA256, чтобы убедиться, что файл копии не повредился при передаче.
7. Планирование до миграции экономит часы. Снижение TTL DNS, проверка размеров баз данных и подготовка целевого сервера предотвращают большинство проблем.

---

Заключение

Миграция Virtualmin не сложна — она просто капризна. Большинство сбоев вызвано не самим Virtualmin, а скрытыми системными лимитами, которые задают хостинг-провайдеры. Понимая эти ограничения и применяя описанные здесь исправления, вы сможете надёжно перенести более 10 сайтов WordPress с сервера на сервер.

Конкретные ошибки, с которыми я столкнулся (лимиты файловых дескрипторов, /tmp их исчерпание, отсутствующие сниппеты NGINX), воспроизводимы и встречаются часто. Если вы столкнётесь с любой из них, вернитесь к этому руководству — вы найдёте точное решение.

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

---

Об авторе

Это руководство описывает реальную миграцию Virtualmin, выполненную в феврале 2026 года: более 10 рабочих доменов перенесены с VPS на Debian 12 (Франция) на VPS с Debian 13 (Нидерланды). Решения проверены на практике и подтверждены в реальных условиях.