Como mover dados do Immich sem perder utilizadores, histórico ou definições

Mova o Immich como uma migração do estado da aplicação, não como uma simples cópia de pastas: preserve a base de dados, a árvore de multimédia, a configuração, os segredos e os caminhos que os ligam.

Uma migração pode parecer bem-sucedida porque todas as imagens JPEG existem no novo disco, enquanto as contas, os álbuns, as pessoas, a partilha, os favoritos ou as relações históricas desapareceram. Crie primeiro um ponto de recuperação, capture um estado de origem consistente, copie-o sem alterar identificadores, restaure-o num destino isolado e só faça a mudança depois de os fluxos de trabalho da família corresponderem.

Faça o inventário do estado que tem de ser movido em conjunto

Enumere a base de dados PostgreSQL, os ficheiros multimédia carregados, os dados gerados que pretende manter, as definições das bibliotecas externas, a configuração do Compose ou da aplicação, os valores do ambiente, os segredos, os nomes de rede e os mapeamentos de armazenamento atuais. Assinale qual item é a fonte de autoridade e qual pode ser regenerado após a recuperação.

Uma discussão de migração de 2026 sobre preservar os utilizadores do Immich durante uma mudança reforça o ponto central: o estado dos utilizadores e das bibliotecas está associado à base de dados e aos caminhos montados, não à imagem do contentor. Trate os comandos da comunidade como exemplos e adapte-os à versão exata instalada.

Antes da mudança, registe um pequeno conjunto de verificação: dois utilizadores, vários álbuns, favoritos, itens partilhados, uma pessoa ou resultado de pesquisa, ficheiros antigos e recentes e um caminho de biblioteca externa, se utilizado. Esses registos conhecidos tornarão a validação pós-migração muito mais sólida do que comparar apenas o tamanho total dos ficheiros.

Crie um ponto de recuperação consistente antes de copiar

Pause os novos carregamentos ou agende uma janela de manutenção para que a origem deixe de sofrer alterações enquanto captura o estado da migração. Faça uma cópia de segurança nativa da base de dados e proteja os ficheiros multimédia e a configuração da origem. Mantenha a instância original intacta após a captura até o destino passar a validação.

O guia de recuperação do ZimaSpace sobre restaurar em conjunto os componentes de uma biblioteca de fotografias explica por que motivo os originais, o estado do catálogo e a configuração que define os caminhos têm de representar um ponto de recuperação compatível. Esse é o mesmo limite de consistência necessário numa migração.

Não utilize o diretório da base de dados de produção em funcionamento como destino de uma cópia de ficheiros normal enquanto este sofre alterações. Se o tempo de indisponibilidade tiver de ser reduzido, utilize uma exportação consciente da base de dados e um método de armazenamento cuja ordem de captura compreenda. Uma migração só é tão recuperável quanto o ponto que consegue restaurar, não quanto ao número de ficheiros copiados.

Copie os ficheiros multimédia preservando caminhos e permissões

Copie a árvore de ficheiros multimédia para o destino sem reorganizar pastas durante a migração. Preserve o proprietário, as permissões, as marcas temporais e quaisquer funcionalidades do sistema de ficheiros de que a instalação dependa. Se o caminho visível no contentor tiver de permanecer igual, altere a origem da montagem no anfitrião, mantendo estável o mapeamento dentro do contentor.

O atual fluxo de trabalho de migração com rsync destaca o modo de arquivo, as execuções de teste, as transferências retomáveis e o perigo das opções de espelhamento destrutivas. Faça uma comparação de teste antes de qualquer eliminação e verifique o destino, em vez de presumir que um comando concluído equivale a uma migração completa da aplicação.

Compare as contagens e os tamanhos dos ficheiros e, em seguida, verifique uma amostra representativa de somas de verificação que inclua fotografias antigas, fotografias novas, vídeos e ficheiros grandes. Se surgirem erros de cópia ou “ficheiros desaparecidos” porque a origem sofreu alterações, pare de aceitar carregamentos e repita a passagem diferencial, em vez de eliminar a origem para obter um destino com aspeto limpo.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Restaure a base de dados e a configuração num destino isolado

Inicie o destino com um nome de anfitrião temporário ou numa rede isolada, para que os clientes móveis não possam carregar ficheiros durante a validação. Ligue os ficheiros multimédia copiados aos caminhos esperados no contentor, restaure a base de dados correspondente e reproduza o ambiente, os segredos, as redes e as definições do proxy necessários para essa versão.

Outro relato de 2026 sobre uma migração faseada de servidor mostra por que motivo os operadores testam o novo anfitrião antes de desativarem o antigo. Utilize esses relatos para identificar possíveis falhas, mas deixe que os seus registos conhecidos determinem se a migração preservou realmente o estado.

Pare se o destino abrir como uma instalação nova, indicar armazenamento em falta ou propor uma inicialização destrutiva. Esses sinais normalmente significam que a base de dados ou as montagens não são as esperadas. Corrija primeiro o caminho ou o destino da restauração; não carregue ficheiros novos para uma instância que parece vazia, criando dois históricos concorrentes.

Faça a mudança apenas depois de os utilizadores, o histórico e as novas escritas serem validados

Inicie sessão com cada utilizador de referência e verifique a pertença aos álbuns, os favoritos, a partilha, o estado da pesquisa ou das pessoas, os originais representativos, as marcas temporais e as contagens esperadas da biblioteca. Em seguida, carregue uma fotografia de teste nova e confirme que aparece, é processada e sobrevive ao reinício de um contentor.

Altere o destino do DNS de produção ou do proxy apenas depois de o teste isolado ser concluído com sucesso. Mantenha a instância antiga parada, mas recuperável, para que os dois sistemas não possam aceitar escritas em simultâneo. Preserve a cópia de segurança da base de dados anterior à migração e os ficheiros multimédia da origem até o novo anfitrião concluir as cópias de segurança normais e pelo menos um teste de restauração.

Faça o rollback se as contagens divergirem, se desaparecerem relações conhecidas, se os novos carregamentos forem escritos no disco errado ou se o destino falhar após o reinício. Ao escalar o problema, inclua as versões da origem e do destino, a data e hora da cópia de segurança da base de dados, os mapas de montagem, os registos de cópia, as diferenças de permissões e o primeiro item de verificação que falhou.