> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Backup e restauração do armazenamento

> Proteja o PostgreSQL e as versões exatas dos objetos como um único conjunto de consistência

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:

```bash theme={null}
pnpm storage:backup-verify inventory \
  --output '<protected-manifest.json>'
chmod 600 '<protected-manifest.json>'
```

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:

```bash theme={null}
sha256sum '<protected-manifest.json>' \
  > '<protected-manifest.json>.sha256'
```

## 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:

```bash theme={null}
pnpm storage:backup-verify verify-restore \
  --manifest '<protected-manifest.json>' \
  --target-profile '<isolated-restore-profile>' \
  --isolated-prefix 'tenants/<test-tenant>/restore-verification/<exercise-id>' \
  --evidence-output '<sanitized-restore-evidence.json>'
```

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](/pt-BR/deployment/storage-migration-runbook) para transição
e rollback e [Backup e recuperação](/en/deployment/recovery) para o conjunto mais amplo
de recuperação da instalação.