Como reparar o Immich depois de o volume da base de dados ficar cheio

Quando o volume da base de dados do Immich fica cheio, pare as novas escritas do Immich, preserve o diretório de dados do PostgreSQL e crie espaço de trabalho seguro antes de tentar a recuperação. Não elimine ficheiros de pg_wal nem de outros componentes internos do PostgreSQL simplesmente por serem grandes.

Um sistema de ficheiros da base de dados cheio pode interromper os checkpoints ou a recuperação após uma falha, pelo que os reinícios repetidos podem continuar a falhar mesmo quando a aplicação de fotografias parece estar saudável. Primeiro confirme qual sistema de ficheiros está cheio — os dados do PostgreSQL, o armazenamento raiz do Docker, a memória partilhada ou outro ponto de montagem — e depois recupere essa camada sem destruir as evidências de que pode precisar para reverter alterações.

Confirme qual sistema de ficheiros está cheio e pare novas escritas

Verifique a disponibilidade de bytes e inodes para o ponto de montagem do PostgreSQL, a raiz de dados do Docker, o sistema de ficheiros raiz do anfitrião e qualquer caminho tmpfs/de memória partilhada indicado no erro. Compare o carimbo temporal com os registos do PostgreSQL. Uma mensagem “no space left on device” proveniente de pg_wal significa algo diferente de uma cache de imagens ou partição de miniaturas cheia.

Uma discussão sobre a recuperação da base de dados do Immich mostra o PostgreSQL a interromper a recuperação porque não conseguiu escrever um ficheiro WAL temporário depois de o armazenamento ficar cheio. O caso é antigo e específico de uma implementação, mas demonstra por que motivo alterar permissões de ficheiros ou reiniciar a stack não resolve uma falha de capacidade.

Pause os carregamentos e as tarefas em segundo plano e, em seguida, pare os componentes da aplicação que geram novo trabalho para a base de dados. Preserve a primeira janela de registos com a falha e o mapa dos pontos de montagem. Se o sistema de ficheiros cheio não for, na realidade, o sistema de ficheiros dos dados do PostgreSQL, repare a localização correta em vez de mover desnecessariamente a base de dados.

Preserve o estado do PostgreSQL antes de libertar espaço

Com o PostgreSQL parado, crie um instantâneo do sistema de ficheiros ou uma cópia completa do diretório de dados da base de dados, quando o armazenamento e as ferramentas o permitirem. Inclua o diretório WAL e quaisquer tablespaces não predefinidos como um único estado. Esta cópia de segurança permite regressar ao ponto do incidente caso a próxima tentativa de recuperação agrave a situação.

As orientações de recuperação do PostgreSQL quando o disco fica cheio tornam explícita a regra essencial: o WAL faz parte da consistência da base de dados, não é lixo de registos comum, e eliminá-lo manualmente pode corromper a base de dados. Crie capacidade expandindo ou movendo o volume, ou removendo dados não relacionados e seguros. Não substitua imediatamente a base de dados com falhas pela última cópia de segurança, a menos que tenha decidido que o estado atual é irrecuperável e aceite perder as alterações feitas desde essa cópia. Preservar a instância cheia proporciona um ponto de reversão e evidências sobre o motivo pelo qual o espaço desapareceu.

Recupere primeiro o PostgreSQL e só depois decida se o Immich precisa de reparação

Quando existir espaço suficiente, inicie o PostgreSQL sozinho ou com a stack mínima necessária e observe os registos de recuperação. Um arranque limpo, uma verificação de integridade bem-sucedida e acesso normal de leitura são sinais mais fortes do que um estado de contentor “em execução”. Crie uma nova cópia de segurança nativa da base de dados assim que esta estiver suficientemente estável para o permitir.

O guia da ZimaSpace sobre manutenção ou substituição da base de dados do Immich estabelece o limite seguinte: problemas comuns de tamanho ou desempenho não devem desencadear uma reconstrução, enquanto falhas repetíveis de integridade ou recuperação podem justificar o restauro de uma cópia verificada da base de dados.

Inicie o Immich apenas depois de o PostgreSQL se manter saudável.

Verifique os utilizadores, a cronologia, vários originais, os álbuns, a pesquisa e um novo carregamento controlado. Se a base de dados iniciar, mas as consultas da aplicação falharem de forma consistente, preserve os novos registos e determine se o problema ativo é a compatibilidade de esquema/versão ou a integridade dos dados — e não a falta de espaço.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Corrija a causa do crescimento e prove que o sistema pode voltar a encher-se em segurança

Meça qual componente cresceu: tabelas normais da base de dados, retenção do WAL, cópias de segurança armazenadas no mesmo volume, registos, camadas do Docker ou um caminho inesperado. Se o incidente tiver sido causado por um fluxo de arquivo ou replicação com falhas, ou por outro serviço que esteja a escrever no volume da base de dados, corrija essa causa em vez de simplesmente aumentar a capacidade.

Configure alertas muito antes de o volume atingir o ponto em que o PostgreSQL já não consegue executar checkpoints ou recuperar. Monitorize tanto a percentagem como o espaço livre absoluto, porque um volume grande pode ter uma pequena percentagem livre e ainda dispor de espaço de trabalho suficiente, enquanto um volume de base de dados pequeno pode tornar-se rapidamente perigoso. Mantenha as cópias de segurança da base de dados fora do mesmo limite de falha que protegem.

Por fim, repita um ciclo normal de carregamento e processamento em segundo plano, crie uma nova cópia de segurança da base de dados, reinicie a stack e reinicie o anfitrião. O teste é bem-sucedido quando há uma diminuição estável do espaço livre, não existem erros de WAL ou recuperação, os recursos antigos e novos podem ser lidos e existe um limiar documentado que desencadeia ações antes de as escritas falharem novamente.