Como recuperar uma base de dados do Immich a partir de uma cópia de segurança válida conhecida

Uma cópia de segurança conhecida como válida da base de dados do Immich só é útil se a restaurar num estado controlado e comprovar que a base de dados recuperada continua a apontar para os ficheiros multimédia que o seu servidor consegue realmente ver.

Trate a recuperação como uma sequência, não como um único comando de importação. Preserve primeiro a instância com falhas, identifique a versão do Immich e a data e hora da cópia de segurança, prepare um destino de base de dados limpo e compatível, restaure sem deixar que a aplicação escreva primeiro num esquema vazio e, em seguida, valide as contas, os dados da cronologia, os caminhos dos ficheiros multimédia e uma nova escrita. Se algum passo for ambíguo, pare antes de substituir a última cópia recuperável.

Congele o estado com falhas antes de restaurar o que quer que seja

Pare os novos carregamentos e as escritas em segundo plano na instância afetada do Immich antes de iniciar o trabalho de recuperação. Guarde o ficheiro Compose atual, os valores do ambiente, os caminhos montados, as versões das imagens, os registos recentes e o estado da base de dados danificada, se o armazenamento o permitir. Uma base de dados com falhas pode ainda conter indícios que expliquem o que aconteceu, e substituí-la elimina esses indícios.

Identifique exatamente qual a cópia de segurança em que pretende confiar. Registe a data e hora, a forma como foi criada, o tamanho do ficheiro e se alguma vez foi restaurada para teste. Um despejo SQL produzido pela base de dados é um recurso de recuperação diferente de uma cópia direta do diretório de dados PostgreSQL em funcionamento; não os trate como se fossem intercambiáveis.

Crie o destino de recuperação num diretório separado ou numa stack isolada sempre que possível. O critério de conclusão desta fase é simples: o estado original com falhas está preservado, a cópia de segurança escolhida é apenas de leitura e sabe qual a versão da implementação e quais os caminhos de armazenamento aos quais a restauração deverá voltar a ligar-se.

Verifique se a cópia de segurança pode realmente ser restaurada

Inspecione a cópia de segurança antes de a reproduzir. Um despejo SQL comprimido deve ser descomprimido sem erros e conter conteúdo reconhecível de um despejo PostgreSQL, em vez de ser um arquivo vazio produzido por uma cadeia de processamento que falhou. Se tiver somas de verificação ou resultados de validação do repositório, compare-os agora, em vez de descobrir a corrupção a meio da recuperação.

Um despejo PostgreSQL é um recurso de recuperação mais seguro do que uma cópia casual de um diretório de dados de uma base de dados em funcionamento, porque é criado através de ferramentas conscientes da base de dados e pode ser reproduzido num destino limpo. O padrão de cópia de segurança com despejo da base de dados também mantém a base de dados separada da cópia dos ficheiros multimédia, facilitando a validação de cada parte antes da recuperação.

Confirme também que os ficheiros multimédia e a configuração correspondentes ao período da cópia de segurança ainda existem. Restaurar apenas a base de dados pode recuperar utilizadores, álbuns, metadados e referências a ficheiros, deixando todos os recursos inutilizáveis se os caminhos da biblioteca referenciados estiverem em falta. Avance apenas quando o despejo e o conjunto de ficheiros multimédia/configuração pertencerem a um ponto de recuperação conhecido.

Inicie primeiro um destino de base de dados limpo e compatível

Adapte o método de restauração à versão que criou a cópia de segurança. As versões atuais do Immich permitem restaurar a base de dados através de Administração > Manutenção e do fluxo de configuração inicial de uma instalação nova, enquanto as cópias de segurança mais antigas podem exigir instruções manuais específicas da versão; o fluxo de restauração mudou na versão v2.5.0.

Para um destino de recuperação novo, não deixe que o Immich execute migrações normais num esquema vazio antes de a restauração da base de dados estar preparada. Se o seu método de implementação iniciar a aplicação juntamente com o PostgreSQL, utilize os controlos de restauração adequados à versão, para que o servidor não crie um estado concorrente antes da importação.

Se a base de dados não ficar saudável por si própria, pare e resolva primeiro essa questão. Não continue a reproduzir a mesma cópia de segurança num destino que está sempre a reiniciar, sem espaço em disco ou a utilizar um esquema de armazenamento incompatível. Um destino limpo e estável é um pré-requisito, não uma questão secundária de resolução de problemas.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaure o despejo uma vez e pare ao primeiro erro

Restaure o despejo escolhido na base de dados preparada e capture todo o resultado. Utilize as ferramentas da base de dados e as opções adequadas ao formato do despejo, para que um erro faça a restauração falhar de forma visível, em vez de deixar um esquema parcialmente importado que ainda inicia.

Um conjunto de migração utilizável precisa dos recursos, do estado do PostgreSQL e da configuração que os volta a ligar. Um conjunto completo de cópia de segurança do Immich inclui os recursos carregados, uma cópia de segurança da base de dados suportada e a configuração da implementação, utilizando testes de restauração para comprovar que o conjunto funciona. Mantenha estas peças juntas, para que o destino possa ser associado a um único ponto de recuperação.

Depois de uma importação bem-sucedida, inicie a aplicação Immich e observe atentamente o primeiro arranque. Se a interface lhe pedir para criar um novo primeiro administrador, em vez de aceitar as contas existentes, pare: isso sugere fortemente que a base de dados restaurada não é a que o Immich está a utilizar. Não comece a carregar novamente fotografias para esse estado vazio.

Valide o estado da base de dados, os caminhos dos ficheiros multimédia e uma nova escrita

Inicie sessão com uma conta existente e verifique a cronologia em várias datas antigas e recentes. Abra vários originais, inspecione álbuns ou favoritos que sabe que existiam e confirme que a aplicação consegue localizar os ficheiros subjacentes, em vez de apenas apresentar linhas da base de dados.

O estado da base de dados, os ficheiros da aplicação, a configuração e os carregamentos têm de estar de acordo no momento da restauração. Utilize uma cópia de segurança consistente do contentor da base de dados como modelo de aceitação, e não apenas o facto de o PostgreSQL arrancar.

Por fim, carregue uma fotografia descartável, aguarde o processamento normal, confirme que sobrevive ao reinício do Immich e à reinicialização do anfitrião e, depois, elimine-a através da aplicação. Se as contas, os recursos antigos e a nova escrita funcionarem normalmente, faça uma nova cópia de segurança do estado recuperado antes de qualquer atualização de versão. Caso contrário, volte aos indícios preservados da falha ou a uma cópia de segurança anterior conhecida como válida, em vez de agravar os danos.