Guida completa alla migrazione del server Virtualmin: Risolvere gli errori comuni e i limiti

Introduzione

Migrazione da un VPS a un altro con Virtualmin La gestione di 10+ domini WordPress sembra semplice in teoria: backup sul vecchio server, ripristino sul nuovo, fatto. In realtà, si tratta di un campo minato di limiti di sistema nascosti, vincoli sui descrittori di file e problemi di spazio su disco che possono lasciarvi bloccati per ore.

Di recente ho completato un'impegnativa migrazione di Virtualmin da un sito di Debian 12 VPS in Francia a un nuovo VPS Debian 13 nei Paesi Bassi, spostando oltre 4,4 GB di dati di backup su più di 10 domini. Durante questo processo, ho incontrato tutti i principali errori che gli amministratori di Virtualmin devono affrontare e li ho risolti tutti. Questo articolo documenta i problemi e le soluzioni esatte, in modo che non dobbiate impararli nel modo più difficile.

Sia che stiate aggiornando il vostro provider VPS, scalando orizzontalmente o recuperando un server guasto, questa guida vi guiderà attraverso gli errori del mondo reale e le relative soluzioni.

---

Parte 1: Pianificazione e preparazione pre-migrazione

Scegliere le specifiche del VPS di destinazione

Prima di toccare qualsiasi cosa sul vostro server attuale, assicuratevi che il vostro nuovo VPS abbia risorse adeguate. L'errore più comune è quello di pensare che il solo spazio su disco sia importante, ma non è così.

Specifiche minime per Virtualmin con oltre 10 domini:

• Spazio su disco: 100GB (non 50GB - i siti WordPress con backup crescono velocemente)
• CPU: 6+ core (8+ core consigliati per 10+ domini)
• RAM: 8GB minimo (15GB+ per la produzione)
• Scambio: 4 GB (aggiunti dopo l'installazione del sistema operativo se non preconfigurati)

Il nuovo server dovrebbe essere uguale o superiore al vecchio in termini di CPU e RAM, con più spazio su disco. Virtualmin richiede un uso intensivo della CPU e dell'I/O durante le operazioni di ripristino: un processore debole farà scricchiolare il ripristino.

Lista di controllo pre-migrazione

Sul vecchio server (48 ore prima della migrazione):

1. Ridurre il TTL del DNS a 300 secondi (5 minuti) per ridurre al minimo i problemi di cache:

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

2. Creare un nuovo backup con il formato consigliato da Virtualmin:

mkdir /backup
virtualmin backup-domain \
  --dest /backup/ \
  --tutti i domini \
  --tutte le caratteristiche \
  --nuovo formato

3. Verifica dell'integrità del backup prima del trasferimento:

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

4. Annotare le dimensioni del database per la pianificazione:

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. Verifica delle configurazioni personalizzate che potrebbero non essere trasferiti:
   • Versioni PHP personalizzate
   • Configurazioni NGINX modificate
   • Lavori di cron in /etc/cron.d/
   • Certificati SSL personalizzati

---

Parte 2: Il processo di migrazione

Passo 1: Trasferimento del file di backup

Utilizzo SCP con checksum per verificare l'integrità del file:

# Sul vecchio server, generare la somma di controllo
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Trasferire il backup e il checksum
scp /backup/backup_*.tar.gz root@new-server.com:/Files/
scp /backup/backup.sha256 root@new-server.com:/Files/

# Sul nuovo server, verificare
cd /Files/
sha256sum -c backup.sha256

Se le checksum non corrispondono, fermarsi immediatamente. Il file si è corrotto durante il trasferimento. Trasferire nuovamente o usare rsync con checksum:

rsync -avz --checksum /backup/backup_*.tar.gz root@new-server.com:/Files/

Passo 2: Installare Virtualmin sul nuovo server

Utilizzare il programma di installazione ufficiale di Virtualmin:

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

Importante: Installare la stessa versione del sistema operativo (o quasi): questo aspetto è più importante di quanto si pensi. Io sono migrato da Debian 12 a Debian 13 (non consigliato, ma fattibile). Se possibile, mantenete la stessa versione principale.

Fase 3: Configurazione del sistema prima del ripristino

È qui che la maggior parte delle migrazioni fallisce. Prima di toccare il ripristino, correggete questi tre limiti critici:

Correzione 1: Aumentare i descrittori di file aperti

Questo è il #1 causa degli errori “Non c'è più spazio sul dispositivo” durante il ripristino, anche quando lo spazio su disco è abbondante.

# Controllare il limite di corrente
ulimit -n
# Probabilmente mostra: 1024 (troppo basso per Virtualmin)

# Aumentare per la sessione corrente
ulimit -n 65536

# Verifica
ulimit -n
# Dovrebbe mostrare: 65536

# Rendere permanente
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536
EOF

Perché 65536? Ogni file aperto, socket, pipe e connessione al database consuma un descrittore di file. Con oltre 10 siti WordPress, server di posta, worker NGINX e connessioni MySQL, si superano facilmente i 1024. OVH e altri provider hanno impostato questo valore predefinito in modo conservativo per motivi di sicurezza, ma deve essere aumentato per ogni applicazione.

Correzione 2: Ingrandire /tmp (tmpfs)

Durante il ripristino, Virtualmin crea i dump di MySQL in /tmp/. Per impostazione predefinita, /tmp è un disco tmpfs (RAM) limitato a ~50% di RAM totale. Con 11 GB di RAM, /tmp raggiunge un massimo di ~5,8 GB. Ma Virtualmin può facilmente generare 5-6GB di file temporanei durante il ripristino.

# Controllare la dimensione attuale di /tmp
df -h /tmp

# Ridimensionare dinamicamente senza smontare
mount -o remount,size=8G /tmp

# Verifica
df -h /tmp

# Rendere permanente
echo "tmpfs /tmp tmpfs size=8G,mode=1777 0 0" >> /etc/fstab

Correzione 3: Aggiungere spazio di scambio

Se il ripristino consuma tutta la RAM, il sistema diventa poco reattivo. 4 GB di swap forniscono un buffer di sicurezza:

# Creare un file di swap da 4GB
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Rendere permanente
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Verificare
swapon --show

---

Parte 3: Il processo di ripristino e gli errori più comuni

Errore 1: “Controllo del contenuto del backup ...”. Si blocca per oltre 20 minuti

Che aspetto ha:

Controllo del contenuto del backup .

[bloccato per 15-30 minuti senza alcun progresso].

Causa principale: Non si tratta di un blocco, ma di una vera e propria lentezza. Il sistema di Virtualmin tar -tzf legge l'intero archivio compresso da 4,4 GB, verifica l'intestazione di ogni file e controlla l'integrità del tar. Sulle CPU più vecchie (come Haswell), questa operazione può richiedere oltre 20 minuti per un backup di 4 GB.

Soluzione:

1. Non fatevi prendere dal panico. Controllare se tar è effettivamente in esecuzione:

ps aux | grep tar
iostat -x 1 # Controllare l'attività del disco

2. Utilizzare il ripristino della CLI invece dell'interfaccia web (aggira il timeout di verifica):

schermo -S ripristino
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz ´
  --tutti i domini \
  --tutte le caratteristiche \
  --reuid

Il --reuid regola automaticamente gli ID utente/gruppo, fondamentale quando si esegue il ripristino su sistemi diversi.

Errore 2: “/bin/tar: Impossibile scrivere: Non c'è più spazio sul dispositivo”

Che aspetto ha:

/bin/tar: ./seo.grahammiranda.com_mail_users: Impossibile scrivere: Non c'è più spazio sul dispositivo
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: Impossibile scrivere: Non c'è più spazio sul dispositivo

[decine di altri errori].

/bin/tar: Esce con stato di fallimento a causa di errori precedenti

La parte confusa: Avete 75 GB liberi, ma vi dice “Non c'è più spazio sul dispositivo”.”

Cause principali (in ordine di probabilità):

1. Limite dei descrittori di file raggiunto (più comune)
   • Sintomo: Gli errori vengono visualizzati dopo 5-10 minuti dal ripristino, non all'inizio.
   • Correggere: ulimit -n 65536 (vedi sopra)
2. /tmp si riempie (secondo più comune)
   • Sintomo: Errori relativi a MySQL o ai file temporanei
   • Controllo: df -h /tmp durante il ripristino: osservare il riempimento a 100%
   • Correggere: mount -o remount,size=8G /tmp (vedi sopra)
3. Lo spazio effettivo su disco si esaurisce (meno comune ma possibile)
   • Controllo: df -h / mostra <5GB liberi
   • Soluzione:

# Pulire il ripristino fallito
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/

# Se il backup si trova ancora in /Files, si consideri la possibilità di spostarlo
mv /Files/backup_*.tar.gz /mnt/ # Spostare in un'altra partizione, se disponibile

4. Esaurimento degli inode (raro)
   • Controllo: df -i / mostra >90% iUsed
   • Causa: File system creato con un numero di inode troppo basso
   • Soluzione: Riformattare il filesystem con più inode (distruttivo)

Approccio diagnostico durante il ripristino:

Aprire un secondo terminale e monitorare in tempo reale:

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

Questo mostra esattamente quando e dove si è raggiunto il limite.

Errore 3: NGINX non si avvia dopo il ripristino

Messaggio di errore:

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

Causa principale: Il ripristino è parzialmente fallito o alcuni file non sono stati trasferiti correttamente. Le configurazioni di NGINX fanno riferimento a file inesistenti.

Soluzione:

1. Creare il file mancante:

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

2. Prova la configurazione di NGINX:

nginx -t

3. Avviare NGINX:

systemctl start nginx
systemctl status nginx

Se il file ha bisogno di contenuti effettivi, controllate il vostro vecchio server:

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

---

Parte 4: Soluzioni avanzate e ottimizzazione

Ripristino di un dominio alla volta (approccio più sicuro)

Se il ripristino completo continua a non funzionare nonostante le correzioni, ripristinare in modo selettivo:

# Pulire i precedenti tentativi falliti
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Ripristinare prima solo il dominio principale
virtualmin restore-domain \
  --sorgente /Files/backup_*.tar.gz ´
  -dominio grahammiranda.com ´
  --all-features \
  --reuid

In questo modo si isolano i domini che presentano problemi. Se uno di essi viene ripristinato con successo, lo schema funziona anche per gli altri.

Considerazioni sulla migrazione da Debian 12 a Debian 13

Ho effettuato la migrazione da Debian 12 a Debian 13. Sebbene sia generalmente compatibile, fate attenzione a:

1. Differenze di versione di PHP: Debian 12 potrebbe avere PHP 8.1, Debian 13 ha l'8.3.
   • Controllo: php -v su entrambi i server
   • Problema: Rari problemi di compatibilità con le vecchie estensioni PHP
   • Correggere: Forzare la vecchia versione di PHP: virtualmin modify-web --domain example.com --php-version 8.1
2. Sintassi della configurazione di NGINX/Apache: Di solito è compatibile, ma verificare dopo il ripristino
   • Test: nginx -t e apache2ctl configtest
3. Compatibilità con MySQL/MariaDB: Generalmente compatibile con il futuro
   • Controllo: mysql --versione su entrambi i server
   • Differenze di formato dei dump: Raro, ma le Debian più recenti potrebbero avere modalità SQL più rigide
4. Compatibilità del certificato SSL: Nessun problema tra le versioni di Debian, ma verificare:

certificati certbot # Controllare i certificati Let's Encrypt

---

Parte 5: Verifica post-migrazione

Controlli critici prima della messa in funzione

Al termine del ripristino, verificare che tutto funzioni:

# 1. Elencare tutti i domini ripristinati
virtualmin elenco-domini

# 2. Testare la connettività web
curl -I https://yourdomain.com

# 3. Verificare la funzionalità della posta elettronica
mysql -u root -p'password' -e "SELECT user FROM mysql.user;"

# 4. Verificare il DNS
dig yourdomain.com @localhost

# 5. Controllare il modulo Virtualmin
virtualmin test-domain --domain yourdomain.com

# 6. Monitorare i log per gli errori
journalctl -f
tail -f /var/log/nginx/error.log

Aggiornare i record DNS

Una volta che tutti i domini sono stati ripristinati con successo:

1. Aggiornare i server dei nomi della società di registrazione per puntare al nuovo server
2. Monitoraggio del conto alla rovescia TTL (dovrebbe essere di 5 minuti con TTL ridotto)
3. Test da più postazioni:

nslookup tuodominio.com
dig yourdomain.com +corto

4. Riportare il TTL del DNS alla normalità dopo 24-48 ore:

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

---

Parte 6: Limiti del sistema Riferimento

Per riferimento futuro, ecco tutti i limiti di sistema controllati durante questa migrazione:

# Limiti utente/processo
ulimit -a # Tutti i limiti
ulimit -n # File aperti
ulimit -u # Processi massimi
ulimit -v # Memoria virtuale

# Limiti a livello di sistema
cat /proc/sys/fs/file-max # File aperti a livello di sistema
cat /proc/sys/kernel/pid_max # ID massimo dei processi
cat /proc/sys/vm/max_map_count # Limite della mappa di memoria

# Utilizzo attuale delle risorse
df -h # Spazio su disco
df -i # Uso degli inode
free -h # RAM e swap
ps aux | wc -l # Processi in esecuzione
lsof | wc -l # Descrittori di file aperti

# Specifiche del filesystem
mount | grep /dev/sda1 # Opzioni di montaggio
quota -s # Quote disco
tune2fs -l /dev/sda1 # Proprietà del filesystem

---

Punti di forza

1. OVH (e la maggior parte dei fornitori) impostano valori predefiniti conservativi. È necessario aumentare i limiti dei descrittori di file prima di ripristinare i backup di Virtualmin.
2. I limiti del sistema sono il vero nemico, non lo spazio su disco. Anche con 75 GB gratuiti, si otterrà il messaggio “Non c'è più spazio sul dispositivo” se /tmp è pieno o i descrittori di file sono esauriti.
3. Aumento /tmp prima del ripristino. Virtualmin crea 5-6 GB di file temporanei durante il ripristino del backup. L'allocazione predefinita di tmpfs non è sufficiente.
4. Usare il ripristino CLI, non l'interfaccia web. L'interfaccia Web presenta problemi di timeout su backup di grandi dimensioni. Il ripristino da riga di comando è più affidabile e mostra l'avanzamento effettivo.
5. La migrazione da Debian 12 a Debian 13 funziona, ma la stessa versione è più sicura. Le differenze di versione minori raramente causano problemi, ma se possibile rimanete nella stessa versione principale.
6. Verificare l'integrità del backup prima di trasferirlo. Utilizzare le checksum SHA256 per garantire che il file di backup non si sia corrotto durante il trasferimento.
7. La pianificazione pre-migrazione fa risparmiare ore. La riduzione del TTL del DNS, la verifica delle dimensioni del database e la preparazione del server di destinazione evitano la maggior parte dei problemi.

---

Conclusione

La migrazione di Virtualmin non è difficile, è solo pignola. La maggior parte dei fallimenti non è dovuta a Virtualmin stesso, ma a limiti di sistema nascosti imposti dai provider di hosting. Comprendendo questi limiti e applicando i rimedi qui documentati, è possibile migrare più di 10 siti WordPress da un server all'altro in modo affidabile.

Gli errori specifici che ho riscontrato (limiti del descrittore di file, /tmp esaurimento, snippet NGINX mancanti) sono riproducibili e comuni. Se si verifica uno di questi problemi, tornare a questa guida per trovare la soluzione esatta.

Buona fortuna per la migrazione. Che i vostri backup possano essere ripristinati rapidamente e che i vostri domini siano online senza problemi.

---

Biografia dell'autore

Questa guida documenta una migrazione reale di Virtualmin completata nel febbraio 2026, con la migrazione di oltre 10 domini di produzione da un VPS Debian 12 (Francia) a un VPS Debian 13 (Paesi Bassi). Le soluzioni sono testate e verificate sul campo.