Solução da comunidade

Voltar a ligar o Immich às fotografias existentes após repor o ZimaOS: proteja o pgdata e o Upload antes de remapear os caminhos

A June-July 2026 thread where a ZimaOS reset preserved a RAID6 and its old Immich folders, but reinstalling Immich did not reconnect the existing photo library. The old /media/photos/immich/upload and pgdata folders still existed. Community replies emphasized protecting both and verifying Docker's actual mounts. The user ultimately abandoned that recovery attempt without confirming a fix.

Os dados de origem não pareciam ter sido perdidos. Após uma reposição do ZimaOS, o RAID6 continuava a existir e diretórios como carregamento, pgdata, miniaturas, perfil, e vídeo codificado continuavam presentes. O problema era que a stack Immich reinstalada não estava ligada ao estado antigo da base de dados/biblioteca de forma a restaurar o catálogo de fotografias anterior.

O conselho mais seguro da fonte foi: não elimine nem mova ainda as antigas pastas upload e pgdata. O Immich não reconstrói o catálogo completo simplesmente por detetar ficheiros de imagem no disco. A base de dados contém caminhos dos ficheiros, utilizadores, álbuns, metadados e o estado da aplicação. A documentação atual do Immich v3 torna explícita essa relação e recomenda fazer cópias de segurança tanto dos ficheiros dos recursos como da base de dados.

Primeiro, confirme o caminho real de montagem do RAID

A fonte utilizou:

ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)

e encontrou:

/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/upload

Isso confirmou que as antigas pastas do Immich ainda existiam no RAID.

O utilizador ficou alarmado com:

/media/ZimaOS-HD -> /DATA

mas a comunidade explicou corretamente que se trata de uma relação de montagem/link simbólico do ZimaOS. A sua presença não indica quais os caminhos do anfitrião que os contentores Immich estão realmente a utilizar.

Inspecionar os mounts efetivos do Docker

A discussão recomendava verificar:

docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'

Isto é mais fiável do que presumir que uma captura de ecrã ou uma memória antiga reflete a configuração do contentor em execução.

Definições do servidor Immich no ZimaOS, com caminhos do anfitrião em /media/photos/immich mapeados para os caminhos do contentor upload, thumbs, profile, model-cache, library, encoded-video e backups
A fonte mostra as antigas pastas RAID mapeadas no novo contentor do servidor Immich, mas mapear apenas os ficheiros não restaurou o catálogo da base de dados anterior.

A antiga pgdata é tão importante como os antigos ficheiros de fotografias

Mapeamento das definições da base de dados do Immich no ZimaOS: /media/photos/immich/pgdata para o diretório de dados do Postgres
O mapeamento da base de dados é fundamental, porque o Immich armazena o catálogo e os metadados que associam os utilizadores aos ficheiros no disco.

Se a reinstalação inicializou uma base de dados completamente nova em vez da antiga, os ficheiros podem continuar a existir enquanto o Immich aparenta estar vazio.

O Immich atual utiliza UPLOAD_LOCATION e DB_DATA_LOCATION

O Compose atual do Immich v3 separa a localização dos ativos no anfitrião da localização do Postgres utilizando UPLOAD_LOCATION e DB_DATA_LOCATION. O projeto salienta explicitamente que as partilhas de rede não são suportadas para o caminho da base de dados.

Utilize o modelo de armazenamento atual do Immich.

Uma cópia de segurança da base de dados é mais segura do que voltar a associar um diretório pgdata antigo ativo entre versões

A origem estava no Immich v2.7.2. O Immich atual é a v3. Ao recuperar entre versões, o fluxo de trabalho de cópia de segurança/restauro da base de dados recomendado pelo projeto é mais seguro do que presumir que um diretório de dados antigo do Postgres pode simplesmente ser associado a uma imagem de base de dados mais recente.

Consulte o processo atual de cópia de segurança e restauro do Immich.

Não reorganize manualmente as pastas internas de ativos do Immich

A documentação atual do Immich alerta para o facto de pastas como biblioteca, carregamento, miniaturas, perfil, e vídeo codificado são geridos pela aplicação. Mover ou eliminar ficheiros individuais por trás do Immich pode criar ativos em falta ou não rastreados.

O utilizador de origem não confirmou uma recuperação bem-sucedida

Os membros da comunidade propuseram várias abordagens de mapeamento, incluindo uma montagem de um único diretório-pai, mas jerlo acabou por deixar o problema de lado e recomeçar noutro sistema. Por conseguinte, o fórum não valida nenhum mapeamento de caminhos específico como solução final.

O Immich atual prefere uma raiz de carregamentos gerida em vez do mapeamento manual de cada pasta secundária

As capturas de ecrã de origem mapearam manualmente carregamento, miniaturas, perfil, biblioteca, vídeo codificado, e faça cópias de segurança uma a uma. O Compose atual a montante centra-se, em vez disso, na configuração do anfitrião UPLOAD_LOCATION, com o Immich a gerir os diretórios secundários internos dentro dessa raiz.

Ao reconstruir numa versão mais recente do Immich, utilize o esquema atual do Compose/armazenamento em vez de reproduzir um conjunto histórico de mapeamentos secundários, a menos que o pacote exija especificamente esses mapeamentos.

Mantenha o caminho dos dados do PostgreSQL num armazenamento local suportado

A documentação atual do Immich afirma explicitamente que os compartilhamentos de rede não são suportados para DB_DATA_LOCATION. Um sistema de ficheiros RAID/armazenamento ligado localmente pode ser adequado, mas um diretório de base de dados montado através de SMB/NFS não é o caminho de base de dados suportado.

Uma recuperação completa do Immich precisa dos recursos e da base de dados

A documentação atual de cópias de segurança do Immich indica que as cópias de segurança da base de dados contêm metadados e informações dos utilizadores, mas não contêm os recursos de fotografias/vídeos. A árvore de recursos deve ser salvaguardada separadamente e restaurada juntamente com uma cópia de segurança da base de dados compatível.

Isso explica por que razão «os ficheiros carregados ainda estão lá» era tranquilizador, mas insuficiente no caso de origem.

Não associe casualmente um diretório pgdata ativo antigo a uma versão diferente do PostgreSQL/da imagem

Um diretório de dados PostgreSQL bruto depende da versão. Se o ambiente antigo e o novo pacote utilizarem versões diferentes do PostgreSQL ou do Immich, prefira uma exportação/importação da base de dados suportada ou um procedimento de migração documentado. Faça uma cópia de segurança, byte a byte, do diretório antigo pgdata antes de fazer experiências.

Perguntas frequentes sobre a recuperação do Immich

A reposição do ZimaOS apagou as pastas de fotografias do RAID6 de origem?

Não. O utilizador afirmou que o RAID e os diretórios/ficheiros existentes permaneceram intactos.

Mapear apenas os ficheiros de fotografias antigos irá restaurar a biblioteca do Immich?

Não necessariamente. O Immich também precisa do estado correspondente da base de dados/catálogo.

O que deve ser protegido antes de fazer experiências?

O armazenamento completo dos recursos, juntamente com a base de dados ou uma cópia de segurança da base de dados verificada.