Como transferir um servidor CasaOS para hardware novo

Melhor estratégia de migração: encare o CasaOS como três camadas — sistema operativo anfitrião, definições das aplicações e dados persistentes. Reinstalar o CasaOS é a parte fácil. O trabalho importante consiste em preservar as pastas e a configuração que os seus contentores realmente utilizam e, em seguida, recriar os mesmos caminhos na nova máquina.

Faça o inventário antes de copiar

• versões do CasaOS e da base Linux;
• imagens dos contentores, portas e variáveis de ambiente;
• todos os caminhos de origem das montagens de ligação;
• /DATA/AppData e pastas personalizadas das aplicações;
• pontos de montagem dos discos de multimédia/dados;
• Propriedade UID/GID;
• IP estático, DNS, proxy, VPN e regras de firewall.

As aplicações da loja CasaOS guardam normalmente os dados em /DATA/AppData/$AppID. O padrão AppData do CasaOS mostra por que motivo copiar apenas um contentor Docker não constitui uma migração.

Pare as aplicações que fazem muitas escritas antes da cópia final

As bases de dados e o estado das aplicações podem alterar-se durante a cópia. Pare os contentores relevantes — ou o Docker para a sincronização final — antes de efetuar a última cópia de segurança.

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

Em seguida, copie com uma ferramenta que preserve os metadados, como rsync -aHAX quando os seus sistemas de ficheiros o suportarem.

Faça também o inventário dos volumes nomeados

Algumas aplicações utilizam volumes Docker em vez de montagens de ligação do anfitrião. Os volumes persistentes do Docker sobrevivem aos contentores, mas também têm de ser migrados intencionalmente.

Recrie primeiro os caminhos de armazenamento

No novo anfitrião, monte os discos antes de iniciar as aplicações. Se o Jellyfin utilizava /DATA/Media/Movies, restaurar esse mesmo caminho evita bibliotecas danificadas. Se os caminhos mudarem, edite os mapeamentos dos contentores antes do primeiro arranque.

Preserve a propriedade numérica

Os contentores dependem de UID/GID numéricos. Compare os diretórios importantes nos sistemas antigo e novo:

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

Reponha os serviços por fases

1. Instale uma base Linux compatível.
2. Instale o CasaOS.
3. Monte todos os discos de dados.
4. Restaure os dados persistentes.
5. Recrie/importe as definições das aplicações.
6. Inicie as aplicações com estado, uma a uma.
7. Valide as bases de dados, os ficheiros multimédia, as permissões e os agendamentos.
8. Alterne o IP/DNS apenas depois de os testes serem aprovados.

A estrutura Docker do CasaOS explica por que motivo os dados das aplicações e os contentores são questões separadas. A plataforma de aplicações autoalojadas é relevante se estiver a migrar para o ZimaOS em vez de reconstruir o CasaOS.

Para uma substituição x86 compacta, o ZimaBoard 2 pode ser adequado para implementações mais pequenas.

Classifique cada aplicação pelo tipo de estado

Nem todos os contentores são migrados da mesma forma:

• Sem estado: a configuração pode ser recriada a partir do compose/ambiente.
• Baseadas em ficheiros: copie as pastas montadas por bind.
• SQLite: pare a aplicação antes de copiar o ficheiro da base de dados.
• PostgreSQL/MySQL: utilize, quando possível, uma cópia de segurança da aplicação/base de dados, em vez de depender apenas de uma cópia do sistema de ficheiros em utilização.
• Aplicações com volumes nomeados: exporte ou copie intencionalmente o volume do Docker.

Capture a configuração atual do Docker

Para cada contentor importante, guarde:

docker inspect <container> > container-inspect.json

Este não é um ficheiro compose pronto a importar, mas regista montagens, portas, variáveis de ambiente, redes e dispositivos, para que possa verificar se o serviço reconstruído corresponde ao antigo.

Planeie a mudança do IP e do nome de anfitrião

Se os clientes utilizarem um nome de anfitrião do servidor, a migração será mais fácil: aponte o DNS para o novo IP após a validação. Se todas as aplicações tiverem o IP antigo codificado, poderá preferir atribuir o endereço estático antigo ao novo anfitrião depois de o antigo estar desligado.

Mantenha o servidor antigo intocado até a reversão deixar de ser necessária

Não apague imediatamente a origem após o primeiro início de sessão bem-sucedido. Mantenha-a desligada, mas intacta, durante pelo menos um ciclo de cópia de segurança e um período de utilização normal. Isto fornece uma reversão conhecida e funcional caso tenha sido esquecida uma tarefa agendada, uma base de dados ou um cliente remoto.

Valide os dados, não apenas os contentores

Um estado verde do Docker apenas prova que o processo está em execução. Valide:

• biblioteca e estado de visualização do Jellyfin;
• estado das pastas do Syncthing;
• tarefas de cópia de segurança e testes de restauro;
• aplicações de bases de dados;
• caminhos das unidades externas;
• certificados do proxy inverso;
• acesso remoto por VPN/túnel.

Perguntas frequentes

Posso clonar o disco de arranque?

Por vezes, mas um clone transporta pressupostos específicos do hardware relativos à rede, ao arranque e às montagens. Um anfitrião limpo com os dados restaurados é frequentemente mais fácil de validar.

Quando posso desativar o servidor antigo?

Apenas quando os inícios de sessão nas aplicações, as bases de dados, os caminhos multimédia, as permissões, as tarefas agendadas, as cópias de segurança e o acesso remoto funcionarem todos no novo anfitrião.