14:00
Espelho em dia
Com 1 hora de atraso, o espelho está aplicando o WAL de 13:00. Produção segue normal.
PostgreSQL-first / Self-hosted
Recuperação não deveria ser uma aposta.
Transforme backup, WAL, integridade e clone em uma rota de recuperação observável. A execução permanece na sua infraestrutura.
Integridade verificável
Manifestos e SHA-256 ajudam a identificar artefatos incompletos ou alterados.
Saúde do PITR
Acompanhe cadeia WAL, gaps detectados e RPO observado por instalação.
Restore isolado e espelho atrasado
Valide em clone separado ou mantenha um standby com delay para promover em minutos após um erro lógico.
ROTA DE RECUPERAÇÃO / 01CONTROLE LOCAL
OrigemPOSTGRESQL
WAL contínuoRPO VISÍVEL
Backup físicoINTEGRIDADE
Clone isoladoVALIDADO
Como funciona
Do banco em produção à evidência de recuperação
01
Conecte o PostgreSQL
Instale o data plane no seu servidor e cadastre os bancos que deseja proteger.
02
Observe a recuperabilidade
Acompanhe backups, integridade, cadeia WAL, jobs e riscos no mesmo painel.
03
Valide em clone isolado
Escolha um ponto de recuperação, restaure separadamente e confirme o resultado.
04
Mantenha um espelho atrasado
Para erros lógicos, congele o replay do banco espelho e promova o ponto seguro sem esperar um restore completo.
Prontidão de recuperação
Backup existente não significa recuperação possível
O DunckOps reúne os sinais necessários para avaliar a recuperabilidade. A disponibilidade de cada capacidade depende do plano e da configuração da instalação.
Backup e integridade
Acompanhe a execução do backup e valide os artefatos por manifesto e SHA-256.
Saúde do PITR
Visualize cadeia WAL, gaps detectados e o RPO observado dentro da retenção disponível.
Restore de validação
Restaure em clone isolado e registre o resultado sem executar rollback destrutivo sobre a origem.
Banco espelho com atraso
Mantenha uma cópia já restaurada, atrasada de 15 minutos a 24 horas, para congelar o replay e promover em minutos depois de um DROP ou DELETE acidental.
Jobs e operação
Centralize progresso, logs, falhas e reprocessamentos dos jobs operacionais.
Alertas multicanal
Receba eventos operacionais por Telegram, Slack, Teams e Discord, conforme a configuração.
Métricas de contexto
Relacione risco de recuperação com conexões, WAL, cache, deadlocks, CPU, memória e disco.
Banco espelho com atraso
Quando a PRD quebra, o restore não precisa começar do zero.
O espelho é um PostgreSQL já restaurado que aplica o WAL da produção com delay proposital — o mesmo padrão de delayed standby que DBAs usam no motor nativo e que nuvens oferecem como linha de defesa. Entra no plano Assurance. Backup e PITR continuam obrigatórios. O espelho existe para o RTO não depender de baixar centenas de gigabytes na hora do incidente.
15:00
Incidente na PRD
DROP TABLE, DELETE sem filtro, ou a instância de produção fica indisponível.
15:05
Operador age no painel
Erro lógico: congela o replay. Pane da produção: aplica o WAL restante já arquivado.
minutos
Espelho vira o banco útil
Promoção no ponto seguro. O principal antigo permanece como backup protegido; a aplicação aponta para a nova connection string.
Erro lógico
DROP TABLE clientes às 15:00, percebido às 15:05
- 1Congelar o replay imediatamente. O comando destrutivo tem 5 minutos; o atraso é 1 hora, então o espelho ainda não aplicou o DROP.
- 2Promover o estado atrasado (cerca de 14:05). Opcionalmente, promover até 14:59:59.
- 3Apontar a aplicação para a connection string do espelho. A PRD antiga não é apagada.
RTO em minutos. Você não espera restaurar o backup inteiro a partir do storage.
Pane da produção
Container, disco ou VPS da PRD saiu do ar às 15:00
- 1Não congele. Aqui o objetivo é aproveitar o WAL que já estava no storage.
- 2Escolha “WAL restante e promover”: o atraso vai a zero, o espelho aplica até o último WAL arquivado e promove.
- 3O RPO fica no último WAL confirmado, não nas 1 hora de atraso. Se faltar WAL, o PITR em clone isolado continua disponível.
O banco já está no ar, com índices prontos. O tempo deixa de ser “fetch do backup + replay completo”.
Onde o espelho entra na rota de recuperação
Réplica comum
Cópia quase em tempo real.
Copia o DROP em milissegundos. As duas instâncias ficam logicamente corrompidas.
PITR em clone
Recupera qualquer ponto dentro da retenção, em destino isolado.
Em bases grandes, restaurar o basebackup e aplicar WAL pode levar muito mais tempo.
Espelho com atraso
Já restaurado. Congela, alcança WAL ou promove. RTO curto para erro humano e para pane.
Consome disco e CPU contínuos. Não troca o tráfego da aplicação sozinho. Não substitui backup/PITR.
O que o operador faz no painel
- Cria o espelho no detalhe do banco, com atraso de 15 minutos a 24 horas. Recomendado: 1 a 6 horas.
- Acompanha atraso observado, último WAL aplicado e se o replay está congelado.
- Na crise, escolhe congelar, promover o estado atrasado, aplicar WAL restante ou promover até um instante.
- A promoção pede o nome do container. O espelho herda agenda, retenção e intervalo de WAL da PRD anterior, religa o archive e dispara o primeiro backup. O principal antigo vira backup protegido.
O que isso não é
- Não é failover automático nem troca de DNS. A aplicação precisa da nova connection string.
- Não substitui backup físico, cadeia WAL nem restore em clone isolado.
- Não há RPO/RTO genérico. O resultado depende do atraso escolhido, do WAL arquivado e do disco do host.
- A proteção do intervalo completo existe depois que o espelho rodou pelo tempo configurado.
A execução permanece no ambiente self-hosted. A cloud comercial não acessa o PostgreSQL, o WAL nem o espelho.
Visibilidade operacional
Da execução do backup ao diagnóstico da recuperação.
Capturas de uma operação self-hosted com ambientes de Produção, Staging e Desenvolvimento. Resultados de RPO e RTO dependem de cada instalação.
Portfólio operacional1/10
01
Visão operacional
Projetos, bancos, jobs e sinais operacionais reunidos no ambiente self-hosted.
Para quem opera PostgreSQL
Controle local sem voltar para uma coleção de scripts.
SaaS em VPS
Padronize backup, PITR e um espelho com atraso para o PostgreSQL sem entregar o plano de dados a uma plataforma externa.
Software houses e MSPs
Centralize a leitura de risco e a operação de diferentes projetos e instalações.
DevOps enxuto
Substitua sinais fragmentados por jobs, alertas e evidências em um fluxo único.
Arquitetura de confiança
A cloud comercial não é o seu plano de dados.
Conta, cobrança e licença ficam na plataforma comercial. Bancos, credenciais, backups, WAL e execução operacional permanecem no ambiente controlado pelo cliente.
- Entitlement RS256 validado localmente
- Storage local ou S3/R2 escolhido pelo cliente
- Espelho com atraso, clone e PITR executados no host do cliente
- Validade curta com período de carência para continuidade
Cloud comercial
Conta, planos, pagamentos, licenças e suporte comercial.
API + licença
Ambiente do cliente
PostgreSQL, credenciais, backups, WAL, storage e jobs.
Separação de responsabilidadesChave privada somente na cloudSem banco operacional na cloud
Planos
Escolha pelo nível de recuperação que você precisa comprovar
Compare bancos, instalações, retenção, PITR, observabilidade e suporte. Infraestrutura e storage são contratados e operados separadamente pelo cliente.
Catálogo indisponível no momento
Os planos são carregados da API para evitar valores desatualizados na página. Tente novamente em instantes ou entre em contato.
Dúvidas
Perguntas frequentes
A cloud DunckOps acessa meus bancos?
Não. A cloud processa conta, cobrança, licença e suporte comercial. Bancos, credenciais, backups, WAL e jobs permanecem no ambiente self-hosted.
Dá para testar um restore sem risco?
O fluxo de recuperação suportado cria um clone separado para validação. A execução depende dos pré-requisitos, do storage e da cadeia WAL disponíveis na instalação.
O que é o banco espelho com atraso?
É um PostgreSQL já restaurado que aplica o WAL da produção com delay proposital (15 minutos a 24 horas). Serve para erro humano e para pane da PRD, quando o restore completo a partir do storage seria lento demais.
Se a produção cair, o espelho de 1 hora vira o banco novo?
Sim, por promoção explícita. O espelho vira Principal, herda agenda/retenção/WAL da PRD anterior, religa o archive e inicia o primeiro backup sozinho. A aplicação precisa da nova connection string; o principal antigo não é apagado. Depois disso, um novo espelho pode ser criado no mesmo fluxo.
O espelho substitui o PITR?
Não. Backup físico, cadeia WAL e restore em clone isolado continuam a linha de recuperação completa. O espelho encurta o RTO quando o banco útil já precisa estar no ar.
Posso trocar de plano depois?
Renovação, cancelamento e reativação estão disponíveis no portal. Mudanças de plano e limites devem ser confirmadas conforme a contratação vigente.
O plano de entrada exige pagamento?
Não. O plano Validação é ativado sem cobrança e permite conhecer o fluxo com um banco e retenção curta.
A infraestrutura e o storage estão incluídos?
Não. VPS, storage local ou S3/R2 e tráfego permanecem sob contratação e controle do cliente, salvo serviço adicional expressamente contratado.
O RPO e o RTO são garantidos?
Não há garantia genérica. O DunckOps apresenta valores observados por instalação; resultados variam com volume, rede, storage, WAL e capacidade do servidor.
Primeiro resultado
Transforme backup em evidência de recuperação
Comece pelo plano Validação ou escolha o plano recomendado para PostgreSQL em produção.
Plano Validação sem cobrança · 1 banco · 1 instalação · 3 dias de retenção