Como impedir que as cópias de segurança do Immich capturem um estado inconsistente

Evite cópias de segurança inconsistentes do Immich tratando a base de dados e os ficheiros multimédia como uma única unidade de recuperação, cuja ordem de captura e atividade de escrita são controladas deliberadamente.

Uma cópia de segurança pode conter todos os ficheiros que lhe foi pedido para copiar e, ainda assim, ser restaurada incorretamente se a base de dados fizer referência a recursos que não foram capturados, ou se a cópia multimédia corresponder a um momento diferente do catálogo. Defina primeiro o limite de consistência, escolha um método com o serviço parado ou coordenado em funcionamento e valide o resultado num ambiente isolado.

Defina a Unidade de Recuperação Antes de Agendar a Cópia de Segurança

Liste a base de dados PostgreSQL, os ficheiros multimédia carregados, os dados de perfil, a configuração da implementação, os valores do ambiente, os segredos e quaisquer caminhos de armazenamento personalizados necessários para recriar o serviço. Classifique separadamente as miniaturas geradas, os vídeos codificados e os ficheiros de modelos, consoante a sua política de recuperação os proteja ou regenere.

A comparação da ZimaSpace entre cópias de segurança do Immich em funcionamento e parado explica a escolha básica de consistência. Este fluxo de prevenção vai um passo além: qualquer que seja o método escolhido, deve produzir um ponto documentado que possa ser restaurado sem ter de adivinhar que base de dados corresponde a que cópia multimédia.

Escreva a ordem de restauro junto ao âmbito da cópia de segurança. Se o plano disser “restaurar fotografias”, mas não indicar qual a cópia da base de dados, configuração, credenciais e mapeamentos de armazenamento que voltam a associar essas fotografias aos utilizadores e álbuns, a definição da cópia de segurança está incompleta antes de começar a primeira execução agendada.

Use uma Captura com o Serviço Parado Quando o Limite Mais Simples for Aceitável

Para uma casa pequena que possa tolerar uma breve janela de manutenção, suspenda os carregamentos e pare os serviços da aplicação que escrevem o estado da biblioteca. Crie a cópia de segurança da base de dados, capture os ficheiros multimédia e a configuração e, em seguida, reinicie apenas depois de o instantâneo ou a cópia ter uma marca temporal clara e um resultado de conclusão.

Uma aplicação parada não torna automaticamente correto um caminho incorreto. Confirme que a exportação da base de dados foi concluída, que as raízes multimédia pretendidas foram incluídas e que o destino da cópia de segurança é independente dos dados ativos que se pretende recuperar. Registe as horas de início e de fim para que os restauros posteriores possam identificar a geração exata.

O método é válido quando não ocorrem escritas da aplicação durante a captura e um restauro de teste devolve os utilizadores, as contagens de recursos, os álbuns e os originais amostrados esperados. Se o período de indisponibilidade exceder regularmente o que a casa tolera, passe para um método coordenado em funcionamento, em vez de permitir silenciosamente que os carregamentos sejam retomados a meio da cópia de um ficheiro.

Nas Cópias de Segurança em Funcionamento, Capture a Base de Dados e os Ficheiros por uma Ordem Conhecida

Quando o Immich tiver de permanecer disponível, crie uma cópia consistente nativa da base de dados em vez de copiar o diretório de dados PostgreSQL ativo como ficheiros comuns. Em seguida, capture ou crie um instantâneo da árvore multimédia pela ordem documentada, acompanhando os carregamentos que ocorram durante a janela da cópia de segurança.

O fluxo prático de cópia de segurança da base de dados do Immich demonstra a abordagem consciente da base de dados. Os comandos e nomes dos contentores podem variar consoante a implementação, pelo que o princípio transferível é pedir ao PostgreSQL uma cópia consistente, em vez de confiar numa cópia recursiva em funcionamento dos ficheiros da base de dados.

Prefira uma ordem que não possa deixar a base de dados restaurada a apontar para ficheiros multimédia que nunca entraram na cópia de segurança. Se a cópia do sistema de ficheiros contiver ficheiros adicionais que a base de dados ainda não conheça, estes poderão ser reconciliados com maior segurança do que registos da base de dados cujos originais referenciados estejam ausentes. Documente quaisquer carregamentos que atravessem o limite.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Coordene os Instantâneos do Sistema de Ficheiros com Hooks da Base de Dados em vez de Presumir Atomicidade

Os instantâneos do sistema de ficheiros são valiosos porque capturam rapidamente um volume, mas não tornam, por si só, transacionalmente consistentes dois sistemas que mudam de forma independente. Se a base de dados e os ficheiros multimédia estiverem em conjuntos de dados ou dispositivos diferentes, defina hooks anteriores e posteriores ao instantâneo e mantenha os respetivos momentos visíveis no registo da cópia de segurança.

Um exemplo de 2026 que combina software de cópia de segurança com hooks de instantâneos Btrfs mostra por que motivo a orquestração de instantâneos precisa de limites explícitos da aplicação ou da base de dados. Use a ideia para coordenar as capturas; não copie cegamente os comandos do sistema de ficheiros para uma disposição diferente.

Se a ferramenta de instantâneos não conseguir coordenar o limite temporal da base de dados e dos ficheiros multimédia, recorra a uma exportação lógica da base de dados juntamente com uma cópia de segurança multimédia, em vez de afirmar que a recuperação é atómica. A complexidade só se justifica quando o exercício de restauro comprova que a captura mais rápida continua a devolver um estado coerente da aplicação.

Inclua os Testes de Restauro no Agendamento da Cópia de Segurança

Uma tarefa de cópia de segurança concluída apenas prova que a captura terminou. Selecione periodicamente uma geração recente, restaure-a sob um nome de anfitrião isolado, associe o armazenamento esperado e verifique os utilizadores, originais representativos, álbuns, permissões, comportamento da pesquisa e uma nova cópia de segurança da base de dados a partir da instância restaurada.

A visão geral da recuperação do PostgreSQL, no planeamento de cópias de segurança e restauro do PostgreSQL, realça a validação do restauro e os objetivos de recuperação, em vez de tratar a criação da exportação como a linha de chegada. Aplique a mesma disciplina à unidade de recuperação combinada do Immich.

Rejeite a política de cópias de segurança se o restauro da base de dados for bem-sucedido mas faltarem ficheiros, se os ficheiros multimédia abrirem sem utilizadores ou relações, ou se a recuperação depender de um segredo armazenado apenas no anfitrião que falhou. Corrija o âmbito, a ordem, a retenção ou a independência antes de aumentar a frequência das cópias de segurança; mais cópias inconsistentes não criam um ponto de recuperação fiável.