Come trasferire un server CasaOS su un nuovo hardware

Migliore strategia di migrazione: considera CasaOS come tre livelli: sistema operativo host, definizioni delle app e dati persistenti. Reinstallare CasaOS è la parte più semplice. Il lavoro importante consiste nel preservare le cartelle e la configurazione effettivamente utilizzate dai container, quindi nel ricreare gli stessi percorsi sulla nuova macchina.

Fai l'inventario prima di copiare

• versioni di CasaOS e della base Linux;
• immagini dei container, porte e variabili d'ambiente;
• tutti i percorsi sorgente dei bind mount;
• /DATA/AppData e cartelle personalizzate delle app;
• punti di montaggio dei dischi multimediali/dati;
• proprietà UID/GID;
• IP statico, DNS, proxy, VPN e regole del firewall.

Le app dello store di CasaOS salvano comunemente i dati in /DATA/AppData/$AppID. Il modello AppData di CasaOS mostra perché copiare solo un container Docker non equivale a una migrazione.

Arresta le app che eseguono molte scritture prima della copia finale

I database e lo stato delle app possono cambiare durante la copia. Arresta i container interessati o Docker per la sincronizzazione finale prima di eseguire l'ultimo backup.

sudo systemctl stop casaos-app-management
sudo systemctl stop docker

Poi copia con uno strumento che preservi i metadati, come rsync -aHAX quando i tuoi filesystem lo supportano.

Fai l'inventario anche dei volumi denominati

Alcune app utilizzano volumi Docker invece dei bind mount dell'host. I volumi Docker persistenti sopravvivono ai container, ma devono comunque essere migrati intenzionalmente.

Ricrea prima i percorsi di archiviazione

Sul nuovo host, monta i dischi prima di avviare le app. Se Jellyfin utilizzava in precedenza /DATA/Media/Movies, ripristinare lo stesso percorso evita il malfunzionamento delle librerie. Se i percorsi cambiano, modifica le mappature dei container prima del primo avvio.

Mantieni la proprietà numerica

I container considerano UID/GID numerici. Confronta le directory importanti sui sistemi vecchio e nuovo:

stat -c '%u:%g %a %n' /DATA/AppData/*

Riattiva i servizi per fasi

1. Installa una base Linux supportata.
2. Installa CasaOS.
3. Monta tutti i dischi dati.
4. Ripristina i dati persistenti.
5. Ricrea/importa le definizioni delle app.
6. Avvia le app con stato persistente una alla volta.
7. Verifica database, media, permessi e pianificazioni.
8. Cambia IP/DNS solo dopo aver superato i test.

La struttura Docker di CasaOS spiega perché i dati delle app e i container sono questioni separate. La piattaforma per app self-hosted è pertinente se stai migrando a ZimaOS anziché ricostruire CasaOS.

Per una sostituzione x86 compatta, ZimaBoard 2 è adatta a distribuzioni più piccole.

Classifica ogni app in base al tipo di stato

Non tutti i container vengono migrati allo stesso modo:

• Senza stato: la configurazione può essere ricreata dal file compose o dall’ambiente.
• Basate su file: copia le cartelle montate tramite bind.
• SQLite: arresta l’app prima di copiare il file del database.
• PostgreSQL/MySQL: quando possibile, utilizza un backup dell’applicazione o del database invece di affidarti solo a una copia del file system attivo.
• App con volumi denominati: esporta o copia intenzionalmente il volume Docker.

Acquisisci la configurazione Docker attuale

Per ogni container importante, salva:

docker inspect <container> > container-inspect.json

Non è un file compose pronto per l’importazione, ma registra montaggi, porte, variabili d’ambiente, reti e dispositivi, così puoi verificare che il servizio ricostruito corrisponda a quello precedente.

Pianifica il passaggio di IP e nome host

Se i client utilizzano il nome host del server, la migrazione è più semplice: dopo la convalida, indirizza il DNS al nuovo IP. Se ogni app è codificata staticamente con il vecchio IP, potresti preferire assegnare il vecchio indirizzo statico al nuovo host dopo aver disconnesso quello precedente.

Mantieni intatto il vecchio server finché non sarà più necessario il rollback

Non cancellare immediatamente la sorgente dopo il primo accesso riuscito. Tienila spenta ma intatta per almeno un ciclo di backup e un periodo di utilizzo normale. Avrai così un rollback affidabile nel caso in cui sia stata trascurata un’attività pianificata, un database o un client remoto.

Convalida i dati, non solo i container

Uno stato Docker verde dimostra solo che il processo è in esecuzione. Convalida:

• libreria e stato di visione di Jellyfin;
• stato delle cartelle Syncthing;
• attività di backup e test di ripristino;
• applicazioni di database;
• percorsi delle unità esterne;
• certificati del reverse proxy;
• accesso remoto tramite VPN/tunnel.

FAQ

Posso clonare il disco di avvio?

A volte, ma un clone conserva impostazioni di rete, avvio e montaggio specifiche dell’hardware. Un host pulito con i dati ripristinati è spesso più facile da convalidare.

Quando posso dismettere il vecchio server?

Solo dopo che gli accessi alle app, i database, i percorsi multimediali, i permessi, le attività pianificate, i backup e l’accesso remoto funzionano tutti sul nuovo host.