Skip to main content
Um ponto de recuperação do CaseBender é o PostgreSQL mais cada versão exata de objeto referenciada, a configuração e as chaves criptográficas. Um dump de banco de dados ou uma cópia de bucket isoladamente não é um conjunto de recuperação válido.

​
Conteúdo do conjunto de recuperação

  • um snapshot/dump do PostgreSQL e o identificador de migração;
  • cada StoredObject finalizado e não excluído em seu profileKey, objectKey e providerVersion registrados;
  • SHA-256 e tamanho de cada objeto;
  • perfil de backup, chave de objeto de backup e versão exata de backup;
  • versões de configuração de armazenamento/identidade/CA;
  • chaves de campo, credencial, integridade de auditoria, autenticação e assinatura;
  • digests imutáveis de imagem do CaseBender e manifesto da release; e
  • timestamp, aprovações, versões de ferramentas, RPO/RTO medidos e digest de evidência.
Criptografe o conjunto, restrinja o acesso e armazene-o independentemente do domínio primário de falha. Não grave credenciais nem conteúdos de objetos em logs de backup.

​
Capturar um ponto de consistência

Silencie escritas de usuário/integração ou use um método de snapshot de provedor/banco de dados que garanta um limite de consistência equivalente. Drene ou pause de forma durável os workers. Registre o snapshot/LSN do PostgreSQL e as versões exatas dos objetos antes de retomar. Gere o inventário de objetos:
O comando executa uma transação serializável no banco de dados e recusa objetos sem metadados de versão exata, SHA-256 ou tamanho. Ele não copia os bytes; o processo de backup aprovado deve preencher backupProfileKey, backupObjectKey e backupVersionId para cada entrada do manifesto. Calcule o hash e proteja o manifesto concluído:

​
Política de cópia

Copie primeiro e retenha o primário. Nunca use uma operação destrutiva de sincronização como o primeiro passo de backup ou migração. Verifique os bytes baixando e calculando o SHA-256; não confie em ETags. Preserve todas as versões históricas exigidas e o estado de retenção/hold. A cópia ordinária de objeto pode não preservar ACL específica do provedor, CMEK, Object Lock, imutabilidade, legal hold, hold baseado em evento, metadados ou histórico de versões. Ateste e reproduza esses controles no destino.

​
Verificação isolada de restauração

Restaure o PostgreSQL em um ambiente isolado usando a mesma release compatível do CaseBender. Garanta que a migração do banco de dados e os metadados de objetos armazenados do manifesto coincidam e, em seguida, restaure os objetos para um prefixo dedicado de verificação:
O script lê cada versão exata de backup, verifica tamanho e SHA-256, faz upload para o destino isolado, baixa-o e verifica o SHA-256 novamente. Ele grava o arquivo de evidência com modo 0600. Limpe o prefixo isolado pelo processo aprovado e consciente de retenção após a revisão da evidência. Em seguida, verifique login, organizações, casos, evidências, anexos, exportações, estado do scanner, retenção, legal hold, integridade da cadeia de auditoria e autorização. Nunca conecte um ensaio a integrações de produção.

​
Ressalvas por provedor

​
S3 e Ceph RGW

Capture IDs de versão e todos os delete markers. O Object Lock deve existir quando o bucket é criado e não pode ser inferido de um adaptador. Um objeto copiado pode receber uma nova versão e um novo estado de retenção. Use a versão exata certificada do produto e a CA privada durante a restauração.

​
Google Cloud Storage

Capture gerações numéricas. Valide o bloqueio de política de retenção, a retenção de objeto, holds baseados em evento, acesso CMEK, acesso uniforme ao bucket e prevenção de acesso público. Os números de geração mudam quando copiados para outro bucket.

​
Azure Blob Storage

Capture IDs de versão de blob. Valide transferência segura, versionamento de conta/contêiner, chaves de criptografia, política de imutabilidade e legal holds. As versões restauradas recebem IDs específicos do destino.

​
Local ou MinIO legado

O armazenamento local não é um destino de produção. Preserve tanto snapshots de volume do MinIO legado quanto exportações de objeto exato no nível da API durante a migração; nunca importe o layout interno do MinIO como arquivos ordinários.

​
Evidência de RPO e RTO

Registre:
  • a última transação do banco de dados e a versão de objeto incluídas;
  • a primeira transação excluída;
  • duração do backup, duração da restauração, duração da validação e horário de retomada do serviço;
  • intervalo real de perda de dados (RPO) e duração da recuperação (RTO);
  • objetos ausentes, alterados, ilegíveis, em hold ou bloqueados por política; e
  • resultado do exercício de rollback.
Uma meta de política não é evidência. Retenha resultados medidos para cada linha de release suportada e após mudanças materiais de armazenamento. Consulte Migração de armazenamento para transição e rollback e Backup e recuperação para o conjunto mais amplo de recuperação da instalação.