Como verificar se uma cópia de segurança de uma base de dados inclui utilizadores, extensões e tarefas agendadas

Um dump apenas da base de dados pode omitir funções ao nível do cluster e o estado de agendadores externos; verifique explicitamente cada classe de objeto numa restauração isolada.

A decisão é importante quando um serviço ao estilo do PostgreSQL tem de recuperar não só tabelas, mas também logins, extensões, privilégios e tarefas agendadas. Os dois estados em disputa são o esquema e os dados locais da base de dados, e os objetos operacionais ao nível do cluster ou externos. Comece com uma configuração guardada e dados descartáveis, observe um ramo de cada vez e pare se o teste aumentar o risco de perda de dados, permissões ou disponibilidade.

Defina as condições subjacentes à decisão sobre o âmbito de uma cópia de segurança completa da base de dados

Registe o ambiente antes de alterar qualquer coisa: versões do software e do firmware, identidades dos dispositivos, caminho de montagem ou de rede, espaço livre, permissões e o sintoma observável. A linha de base deve preservar detalhes suficientes para reproduzir a situação em que um serviço ao estilo do PostgreSQL tem de recuperar não só tabelas, mas também logins, extensões, privilégios e tarefas agendadas.

O primeiro candidato é o esquema e os dados locais da base de dados. O segundo são os objetos operacionais ao nível do cluster ou externos. O mecanismo ou limite de comando utilizado no teste é definido pelos atuais objetos globais do pg_dumpall; isso não substitui a observação deste servidor doméstico específico.

Escreva a condição de aceitação e a condição de paragem antes de executar o teste discriminador. Um resultado aprovado deve alterar as evidências previstas por um dos ramos, deixando os serviços não relacionados inalterados; um resultado reprovado deve devolver o sistema ao estado guardado, em vez de desencadear uma cadeia de correções especulativas.

Teste a afirmação sem reduzir o requisito original

Utilize este teste discriminador: restaure num servidor isolado, faça um inventário das funções, versões das extensões, proprietários, privilégios e entradas do agendador e, em seguida, execute uma tarefa de teste. Mantenha constantes a carga de trabalho, o cliente, o caminho, o conjunto de ficheiros e o momento, para que o resultado seja atribuível à variável alterada.

Utilize restaurações isoladas do PostgreSQL para selecionar o campo que consegue realmente separar os ramos e, em seguida, registe o respetivo carimbo de data e hora, estado de saída, texto do erro, identidade do dispositivo ou do instantâneo, latência, bytes transferidos, permissões e estado da recuperação. Uma saída limpa do comando não é suficiente quando a identidade, a durabilidade ou o estado da aplicação são a afirmação em teste.

Repita o teste uma vez após um reinício, uma nova ligação, uma remontagem ou uma cache fria, quando esse evento fizer parte da condição original. Se a primeira execução for destrutiva ou o ambiente não puder ser restaurado, pare e reproduza-a numa cópia descartável.

pg_dump -Fc appdb > app.dump
pg_dumpall --globals-only > globals.sql

Interprete os resultados aprovados, reprovados e excecionais

APROVADO: as aplicações autenticam-se, as extensões são carregadas, os proprietários coincidem e as tarefas agendadas existem com o estado desativado ou ativado esperado. Registe a versão, a identidade e a carga de trabalho exatas que foram aprovadas, para que a conclusão permaneça condicional em vez de se tornar uma afirmação universal.

REPROVADO: as tabelas são restauradas, mas faltam funções, pacotes de extensões, segredos ou definições de agendadores externos. Um resultado reprovado não prova automaticamente o ramo oposto quando a rede, a memória, as permissões ou a consistência da origem podem influenciar ambos; isole essas dependências partilhadas antes de avançar.

RESULTADO EXCECIONAL OU AMBÍGUO: mantenha a produção intocada e adicione à cópia de segurança a exportação em falta ao nível do cluster ou da aplicação. Preserve os registos e não execute comandos de reparação, limpeza, destruição, reparticionamento ou alteração recursiva de proprietários até existir uma cópia recuperável.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirme a decisão com a carga de trabalho original

Aplique a ação correspondente ao ramo observado e, em seguida, repita a condição original, em vez de um substituto reduzido. A decisão só é válida quando as aplicações se autenticam, as extensões são carregadas, os proprietários coincidem e as tarefas agendadas existem com o estado desativado ou ativado esperado ao longo de dois ciclos ou do reinício, suspensão, interrupção ou transição de carga relevante.

Utilize as cópias de segurança da base de dados antes da atualização para verificar o fluxo de trabalho dependente mais próximo, mas mantenha o acionador original inalterado. Os conjuntos de dados, partilhas, contentores, utilizadores e pontos de recuperação não relacionados devem manter o acesso e o momento anteriores.

O limite de paragem é explícito: se as tabelas forem restauradas, mas faltarem funções, pacotes de extensões, segredos ou definições de agendadores externos, volte à última configuração verificada, conserve as evidências e avance para um teste mais profundo da plataforma ou do hardware apenas quando o ramo for reproduzível.

Depois de o resultado pretendido se confirmar, compare-o com as cópias de segurança separadas do estado da aplicação, para garantir que a correção não transfere o risco para um serviço vizinho. Um teste do objetivo bem-sucedido com uma nova falha de cópia de segurança, identidade, tempo limite ou disponibilidade continua a ser uma alteração falhada.

FAQ

Para determinar o âmbito de uma cópia de segurança completa da base de dados, as pesquisas restantes costumam ser: o pg_dump inclui funções de login, os binários das extensões estão dentro do dump e onde ficam as tarefas agendadas. As respostas abaixo mantêm esses casos-limite separados da decisão principal.

O limite de aceitação não muda: as aplicações autenticam-se, as extensões são carregadas, os proprietários coincidem e as tarefas agendadas existem com o estado desativado ou ativado esperado. Se uma condição posterior alterar o sistema de ficheiros, a identidade, o caminho de rede ou a versão da aplicação, repita apenas o teste discriminador afetado por essa alteração.

Pare de alargar a experiência quando as tabelas forem restauradas, mas faltarem funções, pacotes de extensões, segredos ou definições de agendadores externos. Nesse momento, mantenha a produção intocada e adicione à cópia de segurança a exportação em falta ao nível do cluster ou da aplicação; preserve as evidências antes de avançar para o responsável pela plataforma, pelo armazenamento ou pelo hardware.

O pg_dump inclui funções de login?

Um pg_dump de uma única base de dados não captura todas as funções ao nível do cluster; exporte os objetos globais separadamente.

Os binários das extensões estão dentro do dump?

Não. O dump regista os objetos das extensões, mas os pacotes compatíveis têm de existir no servidor de restauração.

Onde ficam as tarefas agendadas?

Depende do agendador. As extensões da base de dados, os contentores cron e os temporizadores do anfitrião requerem caminhos de cópia de segurança diferentes.

Para determinar o âmbito de uma cópia de segurança completa da base de dados, a resposta prática continua a ser condicional: as aplicações autenticam-se, as extensões são carregadas, os proprietários coincidem e as tarefas agendadas existem com o estado desativado ou ativado esperado. Quando as tabelas são restauradas, mas faltam funções, pacotes de extensões, segredos ou definições de agendadores externos, mantenha a produção intocada e adicione à cópia de segurança a exportação em falta ao nível do cluster ou da aplicação; um sucesso parcial que não resista à carga de trabalho original não é compatibilidade.