Een CasaOS-server naar nieuwe hardware verplaatsen

Beste migratiestrategie: behandel CasaOS als drie lagen: het hostsysteem, appdefinities en persistente gegevens. CasaOS opnieuw installeren is het eenvoudige deel. Het belangrijke werk is het behouden van de mappen en configuratie die je containers daadwerkelijk gebruiken en vervolgens dezelfde paden op de nieuwe machine opnieuw aanmaken.

Inventariseer voordat je kopieert

• CasaOS- en Linux-basisversies;
• containerimages, poorten en omgevingsvariabelen;
• alle bronpaden van bind mounts;
• /DATA/AppData en aangepaste appmappen;
• koppelpunten van media- en gegevensschijven;
• UID/GID-eigenaarschap;
• statische IP-, DNS-, proxy-, VPN- en firewallregels.

CasaOS Store-apps slaan gegevens doorgaans op onder /DATA/AppData/$AppID. Het CasaOS AppData-patroon laat zien waarom alleen het kopiëren van een Docker-container geen migratie is.

Stop apps die veel schrijven vóór de laatste kopie

Databases en appstatus kunnen tijdens het kopiëren veranderen. Stop de relevante containers—or Docker voor de laatste synchronisatie—voordat je de laatste back-up maakt.

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

Kopieer vervolgens met een tool die metadata behoudt, zoals rsync -aHAX wanneer je bestandssystemen dit ondersteunen.

Inventariseer ook benoemde volumes

Sommige apps gebruiken Docker-volumes in plaats van bind mounts van de host. De persistente Docker-volumes overleven containers, maar moeten nog steeds doelbewust worden gemigreerd.

Maak opslagpaden eerst opnieuw aan

Koppel op de nieuwe host de schijven voordat je apps start. Als Jellyfin eerder /DATA/Media/Movies; door datzelfde pad te herstellen voorkom je defecte bibliotheken. Als paden wijzigen, pas dan de containertoewijzingen aan voordat je de container voor het eerst start.

Behoud numeriek eigenaarschap

Containers gebruiken numerieke UID/GID-waarden. Vergelijk belangrijke mappen op de oude en nieuwe systemen:

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

Breng services gefaseerd weer online

1. Installeer een ondersteunde Linux-basis.
2. Installeer CasaOS.
3. Koppel alle gegevensschijven.
4. Herstel persistente gegevens.
5. Maak appdefinities opnieuw aan of importeer ze.
6. Start apps met persistente gegevens één voor één.
7. Valideer databases, media, rechten en schema's.
8. Schakel IP/DNS pas om nadat de tests geslaagd zijn.

De Docker-structuur van CasaOS legt uit waarom appgegevens en containers afzonderlijke zaken zijn. Het zelfgehoste appplatform is relevant als je naar ZimaOS migreert in plaats van CasaOS opnieuw op te bouwen.

Voor een compacte x86-vervanger kan ZimaBoard 2 geschikt zijn voor kleinere implementaties.

Classificeer elke app op basis van het statustype

Niet alle containers worden op dezelfde manier gemigreerd:

• Stateless: de configuratie kan opnieuw worden gemaakt vanuit compose/omgeving.
• Bestandsgebaseerd: kopieer de mappen die via bind mounts zijn gekoppeld.
• SQLite: stop de app voordat je het databasebestand kopieert.
• PostgreSQL/MySQL: gebruik indien mogelijk een back-up van de toepassing/database in plaats van uitsluitend te vertrouwen op een live kopie van het bestandssysteem.
• Apps met benoemde volumes: exporteer of kopieer het Docker-volume doelbewust.

Leg de huidige Docker-configuratie vast

Sla voor elke belangrijke container het volgende op:

docker inspect <container> > container-inspect.json

Dit is geen compose-bestand dat je direct kunt importeren, maar het legt koppelingen, poorten, omgevingsvariabelen, netwerken en apparaten vast, zodat je kunt controleren of de opnieuw gebouwde service overeenkomt met de oude.

Plan de omschakeling van IP-adres en hostnaam

Als clients een serverhostnaam gebruiken, is de migratie eenvoudiger: laat DNS na de controle naar het nieuwe IP-adres verwijzen. Als elke app het oude IP-adres hardgecodeerd gebruikt, kun je er de voorkeur aan geven het oude statische adres aan de nieuwe host toe te wijzen nadat de oude offline is.

Laat de oude server ongemoeid totdat terugdraaien niet meer nodig is

Wis de bron niet onmiddellijk na de eerste geslaagde aanmelding. Houd deze uitgeschakeld maar intact gedurende minstens één back-upcyclus en één periode van normaal gebruik. Zo behoud je een bekende, werkende terugvaloptie als een geplande taak, database of externe client over het hoofd is gezien.

Controleer gegevens, niet alleen containers

Een groene Docker-status bewijst alleen dat het proces actief is. Controleer:

• Jellyfin-bibliotheek en kijkstatus;
• mapstatus van Syncthing;
• back-uptaken en hersteltests;
• databasetoepassingen;
• paden naar externe schijven;
• reverse-proxycertificaten;
• externe VPN-/tunneltoegang.

Veelgestelde vragen

Kan ik de opstartschijf klonen?

Soms, maar een kloon bevat hardware-specifieke aannames over netwerken, opstarten en koppelingen. Een schone host met herstelde gegevens is vaak eenvoudiger te controleren.

Wanneer kan ik de oude server buiten gebruik stellen?

Pas nadat app-aanmeldingen, databases, mediapaden, machtigingen, geplande taken, back-ups en externe toegang allemaal op de nieuwe host werken.