Arrivi a Server Manager da un altro host? La procedura guidata Importa da un altro host accede al tuo vecchio server, lo analizza per trovare siti WordPress, siti statici e database, poi ne copia uno come bundle .tar.gz. Il bundle passa quindi alla procedura guidata di ripristino, che installa davvero il servizio su questo server, con la tua approvazione a ogni passaggio.
L'origine è in sola lettura. Sul tuo vecchio host non viene modificato nulla. La procedura guidata analizza, copia ciò che le serve e si disconnette. Puoi rieseguirla più avanti per migrare un altro sito.
Cosa posso migrare?
La procedura guidata riconosce tre tipi di "elementi da spostare":
| Tipo | Cosa trova | Cosa viene creato qui |
|---|---|---|
| Sito WordPress | Un wp-config.php + un database raggiungibile (compila automaticamente le credenziali quando sono leggibili) | Installazione WordPress completa in container, con un database nuovo e media + plugin + temi ripristinati |
| Sito statico | Una document root con index.html (sotto /var/www/, /home/<user>/public_html/, layout cPanel comuni…) | L'albero dei file sotto /var/www/<your-new-domain>/, servito da Caddy |
| Database | Un'istanza MySQL / MariaDB raggiungibile dal login SSH dell'origine | Un nuovo container database con una copia ripristinata da mysqldump |
Non migra: app web arbitrarie (framework Node/Python/PHP oltre a WordPress: per quelle usa invece Distribuire da un repository git), email/caselle di posta, record DNS o qualsiasi cosa al di fuori delle convenzioni standard per webroot e database.
Come raggiungere il tuo vecchio host: SSH o cPanel
La procedura guidata supporta due modi per collegarsi:
| Tipo di origine | Quando sceglierlo |
|---|---|
| Login SSH | Hai accesso alla shell (lo stesso login che useresti con il comando ssh). La maggior parte dei provider VPS lo offre di default. |
| API cPanel | Hai solo cPanel e non SSH (situazione comune sugli hosting condivisi). Usa il token API di cPanel invece di un login Linux. |
Se non sei sicuro, prova prima SSH: è il percorso con meno attriti. Cambia scheda se la connessione fallisce o se il tuo host offre solo cPanel.
Procedura passo passo
Barra superiore → menu → Importa da un altro host.
Scegli il tipo di origine, inserisci le credenziali e fai clic su Analizza l'origine.
La modalità login SSH richiede: host (IP o dominio del vecchio server), porta (di solito 22), nome utente (root, ubuntu, il tuo utente cPanel, ecc.) e una password oppure una chiave privata OpenSSH. Hai già salvato le stesse credenziali come server in Server Manager? Fai clic su Usa le credenziali di un server salvato per precompilarle da lì.
La modalità API cPanel richiede: l'URL cPanel completo (porta inclusa, di solito https://your-domain:2083), il tuo nome utente cPanel e un token API. Ottieni il token da cPanel → cerca "Manage API Tokens" → Crea: cPanel lo mostra una sola volta, quindi copialo e incollalo subito.
Come la procedura guidata usa le credenziali. Restano solo in questa sessione del browser e vengono inviate via HTTPS direttamente all'origine. Non le scriviamo su disco su questo server e non le conserviamo tra un'esecuzione e l'altra della procedura guidata.
La procedura guidata accede all'origine e percorre per circa 10–30 secondi i percorsi web/database più comuni, raggruppando per tipo tutto ciò che riconosce.
Scegli un solo elemento da migrare in questa esecuzione (la selezione multipla non è ancora disponibile: riapri la procedura guidata per quello successivo). La scheda selezionata viene evidenziata con un bordo color pesca.
Se l'analisi non restituisce nulla, la procedura guidata ti mostra quali root ha controllato e gli eventuali avvisi (errori di permesso, wp-config illeggibile, ecc.). Modifica le credenziali dell'origine o la struttura dei percorsi se l'elemento mancante si trova in una root non standard.
Questo passaggio varia in base al tipo:
- WordPress → scegli il dominio su cui ospitare il sito migrato (può essere lo stesso di prima: cambierai DNS dopo; oppure uno completamente nuovo) e conferma le credenziali del DB (precompilate da
wp-config.phpse leggibile). - Sito statico → se vuoi, scegli un dominio. Lascia vuoto per servirlo per ora dall'IP del server; potrai collegare un dominio più tardi dal pannello del servizio.
- Database → scegli un titolo per il nuovo database su questo server e, raramente, sostituisci le credenziali di
mysqldump.
Fai clic su Avvia l'importazione.
Server Manager preleva i dati dall'origine e assembla su questo server un bundle in formato Server Manager. Le righe di avanzamento si aggiornano in tempo reale (creazione archivio, trasferimento, hashing, ecc.). Dal lato origine vengono eseguite solo letture: nessuna scrittura, nessun file temporaneo lasciato indietro.
Non chiudere la finestra durante l'importazione. Se lo fai, il trasferimento in corso viene interrotto e dovrai ricominciare. La pulizia avviene automaticamente: i file parziali in /tmp/helm-restore/ su questo server vengono rimossi entro 24 ore, oppure puoi eliminarli subito dalla schermata di errore se qualcosa non va.Una volta assemblato il bundle, la finestra di migrazione si chiude e si apre la procedura guidata di ripristino con il bundle appena arrivato già selezionato. È la stessa finestra che usa il flusso Spostare su un altro server all'arrivo, con lo stesso pulsante Ripristina questo bundle a un clic.
Fai clic su Ripristina questo bundle e la chat prende il controllo: Faro legge il manifest, avvia l'installazione su questo server e si ferma per chiedere la tua approvazione a ogni comando: docker compose up, la modifica del Caddyfile, il wp search-replace se il dominio è cambiato, ecc.
Al termine, il sito migrato compare come scheda workload nella schermata iniziale, esattamente come qualsiasi altra cosa distribuita nativamente qui.
Se hai usato un dominio nuovo per la destinazione, hai finito: Caddy emette un certificato TLS per quel dominio entro circa 30 secondi e il sito è online.
Se hai usato lo stesso dominio del vecchio host, la migrazione è stata eseguita usando l'IP del vecchio server. Per spostare il traffico, aggiorna il record A presso il tuo provider DNS in modo che punti a questo server. Entro il tempo di propagazione DNS (di solito 1–10 min), il traffico passa alla copia migrata e Caddy rinnova automaticamente il certificato sotto il nuovo IP. La vecchia installazione sull'origine continua a servire lo stesso dominio finché il DNS non si aggiorna; quando sei soddisfatto della migrazione, puoi spegnerla dal lato origine.
Avviso DNS nella schermata finale. La procedura guidata mostra un richiamo se il dominio di destinazione non punta ancora qui: Caddy non può ottenere un certificato HTTPS finché il DNS non si aggiorna. Anche il passaggio di ripristino si ferma e ti avvisa se il DNS non è ancora configurato.
Domande comuni
Il mio sito sarà offline durante la migrazione? No: l'origine continua a servire traffico per tutto il tempo. La migrazione fa solo una copia. Avrai downtime solo nel momento in cui cambi DNS (oppure mai, se stai usando un nuovo dominio sul nuovo server).
Che succede a plugin / temi / codice personalizzato su WordPress? Vengono inclusi nel bundle. La migrazione acquisisce i file WordPress (temi, plugin, upload) E il database in uno snapshot coerente. Dopo il ripristino, il sito si comporta allo stesso modo: stessi contenuti, stessi URL (oppure URL riscritti se hai scelto un dominio diverso).
Il mio database è più grande dello spazio libero sul disco dell'origine. Così com'è, non funziona: mysqldump ha bisogno per poco tempo di spazio temporaneo sull'origine pari alla dimensione del dump. Libera prima spazio sull'origine, oppure migra manualmente con dump SQL (scarica il dump → caricalo qui tramite Ripristina da un backup).
Posso migrare da qualcosa che non sia SSH/cPanel? Oggi no: la logica di analisi/probe conosce solo questi due ambienti. Per altri pannelli (Plesk, DirectAdmin, ecc.), il percorso è: accedi manualmente all'origine via SSH, usa tar sulla tua webroot, esegui mysqldump del database, crea un .tar.gz che rispetti il layout del bundle di backup e importalo tramite Ripristina da un backup. Se ti serve la specifica esatta del formato bundle per crearne uno a mano, chiedicela da Contatto e te la invieremo.
Cosa succede se la migrazione fallisce a metà? La schermata di errore offre un pulsante Pulisci ora a un clic che rimuove eventuali directory di staging scritte parzialmente sotto /tmp/helm-restore/. Dal lato origine, nulla è stato modificato. Puoi rieseguire la procedura guidata dall'inizio in tutta sicurezza.
Sovrascriverà un sito esistente in questa destinazione? Solo se lo accetti esplicitamente nel passaggio di ripristino. Nel passaggio dalla chat, l'impostazione predefinita è installare affiancato: sceglieresti "clona su nuovo dominio" (oppure, per i database, "clona accanto" con un suffisso) se esiste già un workload sul dominio di destinazione.
Rimane qualcosa sull'origine dopo la migrazione? Nessun artefatto aggiunto da noi. La procedura guidata effettua solo chiamate di lettura; l'unica cosa che scrive sull'origine è mysqldump (per migrazioni WordPress + database), che produce un file che la procedura guidata scarica e poi elimina immediatamente. Dopo la disconnessione della procedura guidata, l'origine si trova nello stesso stato di prima.
Segreti: vengono riutilizzati o ruotati? La password del DB da wp-config.php viene usata per eseguire mysqldump sull'origine, poi scartata. Il sito ripristinato viene avviato con credenziali database nuove generate nel passaggio dalla chat: nessuna credenziale del lato origine finisce nella nuova installazione.
Cosa NON rientra qui
- Ripristino bundle-to-bundle (hai già un
.tar.gzesportato da qualche altra parte) → vedi direttamente Ripristina da un backup. - Spostamento da server a server dentro Server Manager (sia l'origine sia la destinazione sono gestite da Helm) → vedi Backup → Sposta su un altro server. Questo percorso è più efficiente: nessuna fase di probe, nessuna ricostruzione del manifest.
- Cambio di engine (sei su nginx/Apache e vuoi Caddy qui) → vedi Migrare a Caddy. È un problema diverso: riscrive le configurazioni sul posto, non preleva un bundle.
- Email + DNS → fuori ambito. Configurali separatamente tramite Collega un dominio e Configura l'email per il tuo dominio.
Riferimento
Percorsi di origine controllati dall'analisi SSH:
/var/www/*/— root vhost comune per Nginx / Apache/srv/www/*/— alternativa in stile Debian/home/*/public_html/— document root in stile cPanel/home/*/domains/*/public_html/— document root in stile DirectAdmin- WordPress: qualunque percorso tra quelli sopra che contenga un
wp-config.php - Database: enumerati tramite
mysql -e "SHOW DATABASES"usando~/.my.cnfdell'utente SSH, se presente
Endpoint usati dall'analisi cPanel:
WebVhosts(elenca le document root dei vhost)MysqlFE/listdbs(elenca i database)- Probe dell'albero dei file per ogni vhost alla ricerca di
wp-config.php
Staging su disco durante la migrazione:
- Lato origine: mysqldump temporaneo sotto
/tmp/, poi eliminato immediatamente - Questo server:
/tmp/helm-restore/<id>/<bundle>.tar.gz— lo stesso percorso usato dalla procedura guidata di ripristino
Formato del bundle: quello proprietario di Server Manager, intercambiabile con ciò che produce la scheda Backup: quindi una migrazione-seguita-da-ripristino è identica byte per byte a un backup-seguito-da-ripristino (l'unica differenza è da dove proviene il bundle).