Este documento descreve o que compõe o conjunto restaurável da Plataforma em caso de perda de dado ou indisponibilidade prolongada, e onde o Cliente encontra os valores de RPO (Recovery Point Objective) e RTO (Recovery Time Objective) vigentes para este serviço. Integra os Termos de Serviço por referência. É um modelo base e não constitui aconselhamento jurídico nem operacional — revise antes do primeiro deploy em produção.
1. Fonte de verdade e escopo do backup
O banco de dados PostgreSQL é a fonte de verdade da Plataforma: todo dado estruturado — conta, Organização, configuração, trilha de auditoria e demais tabelas de domínio — reside nele. O conjunto restaurável em caso de incidente é composto por:
- backup lógico do Postgres (
pg_dumpou mecanismo equivalente do provedor de banco gerenciado), cobrindo a totalidade do dado estruturado; e - objetos de armazenamento compatível com S3, quando a variável de
ambiente
S3_BUCKETestá configurada — arquivo carregado por um tenant (upload) reside nesse armazenamento, fora do Postgres.
Configuração que reside apenas em variável de ambiente (segredo, credencial de integração) não é dado de aplicação e não faz parte deste backup — é responsabilidade operacional do fork mantê-la reproduzível fora do banco.
2. RPO e RTO — parâmetro do fork
RPO (quanto dado, em tempo, pode ser perdido num incidente) e RTO (quanto tempo a restauração leva) não são fixados por este documento nem pelo scaffold: dependem da topologia de banco, da frequência de backup e do plano de recuperação que cada fork efetivamente opera em produção — o scaffold, por si só, não garante nenhum valor numérico de RPO/RTO.
Os valores de RPO e RTO vigentes para este serviço estão publicados em
[complementar antes do primeiro deploy]. O fork deve preencher essa
referência, com base na configuração real de backup e recuperação de
desastre que operar, antes do primeiro deploy em produção — no mesmo
espírito dos demais parâmetros declarados em src/config/legal.ts.
3. Teste de restauração
Recomenda-se testar a restauração completa a partir do backup ao menos uma vez por trimestre, para validar que o processo funciona e que o RPO/RTO declarado na Seção 2 é factível na prática, não apenas teórico. A cadência final, e o registro da evidência de cada teste, é decisão operacional do fork.
4. Checklist de prontidão
O checklist operacional completo de backup, restauração e demais requisitos de produção — incluindo o que precisa ser decidido e testado antes do primeiro deploy — é mantido pelo Fornecedor como parte da documentação interna de prontidão para produção deste serviço.
5. Contato
Dúvidas sobre este documento: TODO: suporte@exemplo.com.br ou TODO: security@exemplo.com.br.