Continuidade de Negócios e Recuperação de Desastres
Última atualização: 4 de julho de 2026
Os fundadores confiam que a CORPYO mantenha registros de empresas, arquivamentos e correspondências que importam por anos, não apenas pela duração de uma única sessão. Nossa abordagem de continuidade de negócios é projetada em torno dessa realidade.
Redundância
Nosso ambiente de produção é construído, sempre que praticável, sem depender de um único ponto de falha: a infraestrutura de aplicação roda na rede edge distribuída globalmente da Vercel, nosso banco de dados principal roda com replicação, e ativos estáticos e documentos são servidos por meio de um CDN redundante. As regiões dos provedores de nuvem são selecionadas com o failover em mente, de modo que a perda de uma única zona de disponibilidade não derrube a plataforma.
Frequência de Backup
Os backups de banco de dados rodam automaticamente de forma contínua/quase contínua via recuperação a um ponto no tempo combinada com snapshots completos regulares, e os documentos enviados por clientes são armazenados em armazenamento de objetos redundante e versionado. Os backups são criptografados em repouso (veja Criptografia) e armazenados separadamente do ambiente de produção principal, de modo que um único incidente que afete a produção dificilmente comprometa também os backups necessários para a recuperação.
Objetivos de Recuperação (RTO/RPO)
Projetamos e testamos nossos processos de recuperação em relação a metas internas para:
- Objetivo de Tempo de Recuperação (RTO) — o tempo-alvo para restaurar o serviço principal após uma interrupção significativa.
- Objetivo de Ponto de Recuperação (RPO) — a quantidade máxima aceitável de dados recentes que poderiam ser perdidos em um cenário de recuperação de pior caso.
Descrevemos essas metas nesta página como objetivos internos, e não SLAs contratuais; clientes empresariais com requisitos específicos de continuidade podem solicitar por escrito nossas metas atuais de RTO/RPO e a cadência de testes de backup pelo e-mail [email protected].
Estratégia de Disponibilidade
Monitoramos a disponibilidade da plataforma continuamente e visamos alta disponibilidade para o produto principal (painel, rastreamento de pedidos, autenticação e API) — veja nossa página de status em tempo real em /trust/status. Quando um componente se torna degradado, nossa arquitetura é projetada para falhar de forma controlada: por exemplo, atrasos em tarefas em segundo plano não devem impedir um fundador de visualizar o status de seu pedido existente, e um problema regional não deve derrubar toda a plataforma. A manutenção planejada é agendada para minimizar o impacto ao cliente e, quando viável, realizada sem tempo de inatividade usando implantações graduais.