Comment transférer un serveur CasaOS vers un nouveau matériel

Meilleure stratégie de migration : considérez CasaOS comme trois couches : le système d’exploitation hôte, les définitions des applications et les données persistantes. Réinstaller CasaOS est la partie la plus simple. L’essentiel consiste à préserver les dossiers et la configuration réellement utilisés par vos conteneurs, puis à recréer ces mêmes chemins sur la nouvelle machine.

Faites l’inventaire avant la copie

• versions de CasaOS et de la base Linux ;
• images des conteneurs, ports et variables d’environnement ;
• tous les chemins sources des montages liés ;
• /DATA/AppData et dossiers personnalisés des applications ;
• points de montage des disques de médias/données ;
• Propriété UID/GID ;
• IP statique, DNS, proxy, VPN et règles de pare-feu.

Les applications du magasin CasaOS conservent généralement leurs données sous /DATA/AppData/$AppID. Le modèle AppData de CasaOS montre pourquoi la copie d’un conteneur Docker seul ne constitue pas une migration.

Arrêtez les applications qui écrivent intensivement avant la copie finale

Les bases de données et l’état des applications peuvent changer pendant la copie. Arrêtez les conteneurs concernés — ou Docker pour la synchronisation finale — avant d’effectuer la dernière sauvegarde.

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

Copiez ensuite avec un outil préservant les métadonnées, tel que rsync -aHAX lorsque vos systèmes de fichiers le permettent.

Inventoriez également les volumes nommés

Certaines applications utilisent des volumes Docker plutôt que des montages de répertoires de l’hôte. Les volumes Docker persistants survivent aux conteneurs, mais doivent tout de même être migrés intentionnellement.

Recréez d’abord les chemins de stockage

Sur le nouvel hôte, montez les disques avant de lancer les applications. Si Jellyfin utilisait auparavant /DATA/Media/Movies, restaurer ce même chemin évite les bibliothèques défectueuses. Si les chemins changent, modifiez les mappages des conteneurs avant le premier démarrage.

Préservez les propriétaires numériques

Les conteneurs utilisent des UID/GID numériques. Comparez les répertoires importants sur les anciens et les nouveaux systèmes :

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

Rétablissez les services par étapes

1. Installez une base Linux prise en charge.
2. Installez CasaOS.
3. Montez tous les disques de données.
4. Restaurez les données persistantes.
5. Recréez/importez les définitions des applications.
6. Démarrez les applications avec état une par une.
7. Validez les bases de données, les médias, les permissions et les planifications.
8. Ne changez l’IP/le DNS qu’après la réussite des tests.

La structure Docker de CasaOS explique pourquoi les données des applications et les conteneurs sont deux éléments distincts. La plateforme d’applications auto-hébergées est pertinente si vous migrez vers ZimaOS plutôt que de reconstruire CasaOS.

Pour un remplacement x86 compact, le ZimaBoard 2 peut convenir aux petites installations.

Classez chaque application selon son type d’état

Tous les conteneurs ne se migrent pas de la même manière :

• Sans état : la configuration peut être recréée à partir de compose et de l’environnement.
• Basées sur des fichiers : copiez les dossiers montés par liaison.
• SQLite : arrêtez l’application avant de copier le fichier de base de données.
• PostgreSQL/MySQL : utilisez si possible une sauvegarde de l’application ou de la base de données plutôt que de vous fier uniquement à une copie du système de fichiers en fonctionnement.
• Applications utilisant des volumes nommés : exportez ou copiez intentionnellement le volume Docker.

Capturez la configuration Docker actuelle

Pour chaque conteneur important, enregistrez :

docker inspect <container> > container-inspect.json

Il ne s’agit pas d’un fichier compose prêt à importer, mais il consigne les montages, les ports, l’environnement, les réseaux et les périphériques afin que vous puissiez vérifier que le service reconstruit correspond à l’ancien.

Planifiez le basculement de l’adresse IP et du nom d’hôte

Si les clients utilisent le nom d’hôte du serveur, la migration est plus simple : dirigez le DNS vers la nouvelle adresse IP après validation. Si chaque application utilise en dur l’ancienne adresse IP, vous pouvez préférer attribuer l’ancienne adresse statique au nouvel hôte une fois l’ancien serveur hors ligne.

Gardez l’ancien serveur intact jusqu’à ce qu’un retour en arrière ne soit plus nécessaire

N’effacez pas immédiatement la source après la première connexion réussie. Laissez-la éteinte, mais intacte, pendant au moins un cycle de sauvegarde et une période d’utilisation normale. Vous disposerez ainsi d’une solution de restauration connue comme fiable si une tâche planifiée, une base de données ou un client distant a été oublié.

Validez les données, pas seulement les conteneurs

Un statut Docker au vert prouve seulement que le processus est en cours d’exécution. Validez les éléments suivants :

• bibliothèque Jellyfin et état de visionnage ;
• état des dossiers Syncthing ;
• tâches de sauvegarde et tests de restauration ;
• applications utilisant une base de données ;
• chemins des disques externes ;
• certificats du proxy inverse ;
• accès VPN/tunnel distant.

FAQ

Puis-je cloner le disque de démarrage ?

Parfois, mais un clone conserve des paramètres réseau, de démarrage et de montage propres au matériel. Un hôte propre avec les données restaurées est souvent plus facile à valider.

Quand puis-je mettre l’ancien serveur hors service ?

Uniquement lorsque les connexions aux applications, les bases de données, les chemins multimédias, les autorisations, les tâches planifiées, les sauvegardes et l’accès distant fonctionnent tous sur le nouvel hôte.