PowerDBA Protect · proteção contínua de bancos de dados
O desastre acontece às 14h32.
Você volta para as 14h30.
O Protect faz backup contínuo do seu banco de dados, testa a restauração de verdade e cuida da manutenção — para que um vírus, um erro humano ou um disco queimado custem minutos de trabalho, e não o dia inteiro.
Por que se preocupar
O banco de dados é a memória da sua empresa
Vendas, estoque, financeiro, clientes — tudo vive ali. E ele pode sumir de formas que ninguém escolhe:
Um comando errado
Alguém apaga ou altera dados sem querer. Acontece nas melhores equipes — e geralmente em dia de fechamento.
Sequestro digital
Criminosos criptografam seus arquivos e cobram resgate. Um backup fora do servidor é a única saída que não passa por pagar.
Disco que morre
Todo disco falha um dia. A pergunta não é se, é quando — e se você estará pronto.
Atualização que corrompe
Uma atualização do sistema ou queda de energia no momento errado pode deixar o banco inconsistente e inutilizável.
Como funciona
Três camadas de proteção, funcionando sozinhas
Instalamos um agente leve no seu servidor. A partir daí, tudo é automático — e vigiado pela nossa equipe de DBAs.
1. Backup de verdade, contínuo
- Cópia completa do banco + registro contínuo de cada alteração (archive logs)
- Enviado criptografado para a nuvem, fora do seu prédio
- Restauração a qualquer ponto no tempo — até minutos antes da perda
- Retenção configurável por banco, servidor e cliente
2. Restauração testada, de verdade
- Testes periódicos de restore em ambiente isolado
- Validamos que o backup abre, sobe e responde consultas
- Você recebe a evidência — não uma promessa
- Backup que nunca foi restaurado é só uma esperança
3. Manutenção e vigilância 24/7
- Estatísticas e reorganização automáticas (o banco não “envelhece”)
- Espaço em disco monitorado com antecedência — agimos antes de encher
- Incidente crítico? Nossa equipe é alertada na hora — inclusive por ligação
- Painel com a saúde de todos os seus bancos
Verdade incômoda
No PostgreSQL, dump não é backup.
Muita empresa dorme tranquila com um pg_dump agendado à noite.
Até o dia em que precisa dele.
| Critério | pg_dump agendado | PowerDBA Protect |
|---|---|---|
| Até onde você volta | Só a hora do último dump | Qualquer minuto do dia (PITR) |
| Dados perdidos num desastre às 15h | O dia inteiro de trabalho | Minutos |
| Tempo de restauração em banco grande | Horas (reconstrói tudo via SQL) | Muito menor (restaura arquivos + reaplica o diário) |
| Alguém testa se restaura? | Quase nunca | Sim, periodicamente e com evidência |
| Cópia fora do servidor | Depende de alguém lembrar | Automática, criptografada, na nuvem |
| Alguém é avisado se falhar? | Silêncio | Equipe alertada na hora, 24/7 |
“Backup que nunca foi restaurado não é backup. É esperança.”
Por isso o Protect agenda testes de restauração de verdade: o backup é baixado, restaurado em ambiente isolado e validado com consultas reais. Se algo estiver errado, descobrimos antes do desastre — não durante.
Housekeeping · o que quase sempre fica de lado
A manutenção que todo banco precisa — e quase nenhum recebe
Banco de dados sem manutenção fica lento, incha e falha em silêncio. Essas rotinas são conhecidas, mas exigem disciplina — então são adiadas até o dia do problema. No Protect, elas rodam em agenda, automaticamente, com registro de cada execução:
Coleta de estatísticas em dia
O otimizador do banco decide como buscar seus dados usando estatísticas. Desatualizadas, ele escolhe caminhos ruins — e o sistema arrasta. Agendamos a coleta (runstats, analyze, update statistics) e mostramos quando foi a última em cada banco.
Reorganização e limpeza
Tabelas fragmentam com o uso: ocupam mais disco e respondem mais devagar. Reorg, vacuum e poda de arquivos antigos rodam com controle de concorrência — nunca duas rotinas pesadas brigando no mesmo banco.
Tuning continuado
Não é ajuste único na instalação: acompanhamos consultas lentas, memória, índices e parâmetros ao longo do tempo, e ajustamos conforme seu volume de dados cresce e o uso muda.
Histórico de tamanho: base e objetos
Medimos periodicamente o tamanho de cada banco e das maiores tabelas. Crescimento anormal aparece no gráfico antes de virar disco cheio — e você sabe qual tabela está inchando.
Histórico de configurações
Toda mudança de configuração do banco fica registrada com antes, depois e motivo. Quando algo muda de comportamento, dá para responder a pergunta que ninguém consegue: “o que mexeram, e quando?”
Disco sob controle
Prevemos quando o espaço vai acabar antes do backup falhar, e liberamos com segurança apenas o que já está protegido na nuvem.
Resposta automática
Problema conhecido não espera chamado
O Protect vigia seus bancos 24/7. Quando detecta uma degradação, ele mesmo investiga, classifica a causa e — para problemas conhecidos e seguros — aplica a correção na hora. O que exige decisão vira um incidente com diagnóstico pronto e opções de um clique para nossa equipe.
Travamentos
Sessão travando as outras? Identificamos quem bloqueia quem, há quanto tempo, e qual aplicação está por trás — e resolvemos ou recomendamos a ação, com evidência.
Sistema arrastando
Investigação automática com dezenas de sondas: estatísticas velhas? consulta nova ruim? memória? Cada causa provável vem com a correção correspondente pronta para aplicar.
Espaço esgotando
Log de transação enchendo ou disco no limite geram ação preventiva antes da parada — não um alerta às 3h da manhã para alguém resolver no susto.
Rotina que falhou
Backup que falha vira incidente imediato com causa e nova tentativa. Falha grave escala para nossa equipe por mensagem — e por ligação telefônica, até alguém atender.
Transparência
Seu relatório em tempo real, num link só seu
Cada cliente recebe um link exclusivo e privado que abre no navegador — computador ou celular, sem instalar nada, sem senha para decorar.
- Últimos backups (completo e contínuo) de cada banco, com idade e status
- Crescimento da base e das maiores tabelas ao longo do tempo
- Saúde dos servidores: disco, memória, atividade
- Rotinas de manutenção executadas e testes de restauração
- Confiabilidade do período: o que rodou, o que falhou, o que foi corrigido
O link é somente-leitura, atualizado em tempo real e pode ser revogado a qualquer momento. Você não precisa acreditar que está protegido — você vê.
Para o seu time técnico
Os detalhes que o seu TI vai querer conferir
Sem caixa-preta. Abra cada tópico para ver como fazemos.
PostgreSQL Backup físico + WAL archiving com pgBackRest ▾
Usamos pgBackRest com backups full/incremental do cluster e archive_command para arquivamento contínuo de WAL. Isso habilita PITR real: restauração a qualquer LSN/timestamp coberto pela cadeia.
- Stanza por cluster, repositório em object storage (S3-compatível), compressão e criptografia no repositório.
pgbackrest checke verificação de saúde dopg_stat_archivermonitorados continuamente — WAL parado gera incidente, não silêncio.- Dump lógico continua útil para outras finalidades (migração, cópia de tabela) — só não é a sua estratégia de recuperação.
IBM Db2 Backup online + incremental + archive logs ▾
Backup online (sem parar o banco) com estratégia full + incremental, e LOGARCHMETH configurado para arquivamento contínuo dos transaction logs.
- Rollforward até o fim dos logs ou até timestamp específico — PITR nativo do Db2.
- Poda de backups e logs locais respeita um piso de PITR: nunca removemos um log que ainda seria necessário para restaurar a partir do backup mais antigo retido.
- Runstats e reorg automatizados com controle de concorrência (nunca duas rotinas pesadas ao mesmo tempo no mesmo banco).
SQL Server FULL + DIFF + log backups com cadeia LSN íntegra ▾
Bancos em recovery model FULL recebem backup de log frequente, mantendo a cadeia de LSN íntegra — pré-requisito para restaurar a um ponto no tempo.
- Um único dono da cadeia de log: nada de duas ferramentas disputando o
BACKUP LOG(isso quebra o PITR silenciosamente). - Autenticação integrada (sem senha em texto), agendamento com cadência configurável por criticidade.
Armazenamento Nuvem criptografada, retenção em camadas ▾
Backups e archive logs vão para object storage (S3-compatível) com envio direto do servidor — sem intermediários guardando seus dados.
- Transferência via TLS; segregação por cliente; credenciais em cofre próprio, nunca em texto plano.
- Retenção configurável em cascata (padrão da frota → cliente → servidor → instância → banco), com trava dura: nada é apagado se comprometer a janela de PITR.
- Timestamps de backup extraídos do nome do arquivo gerado pela engine — não confiamos em data de upload para decidir o que é recente.
Restore test Como validamos a restauração ▾
Periodicamente, o backup mais recente é restaurado em ambiente isolado, o banco é iniciado e validado com consultas de sanidade (contagens, integridade de catálogo, aplicação dos logs até o fim).
- Resultado registrado com data, duração e evidência — visível no painel.
- Falha de restore vira incidente com prioridade: um backup que não restaura é tratado como banco desprotegido.
Housekeeping Manutenção agendada e histórico de tudo ▾
Rotinas de manutenção rodam como tarefas agendadas com controle de concorrência (rotina pesada nunca roda duas vezes ao mesmo tempo no mesmo banco, e manutenção espera o backup do mesmo banco terminar).
- Estatísticas:
runstats(Db2),ANALYZE/autovacuum supervisionado (PostgreSQL),UPDATE STATISTICS(SQL Server) — com recência visível por banco no painel. - Reorganização (
reorg,VACUUM, rebuild) tratada como operação sensível: exige aprovação e roda em janela. - Séries históricas dedicadas: tamanho de banco e das maiores tabelas (semanal), métricas de host e filesystem (por minuto, com retenção agregada), conexões e atividade.
- Histórico de configurações: toda mudança de parâmetro (memória, log, cache) registrada com antes/depois/motivo — inclusive mudanças feitas fora da plataforma, auditadas.
- Timeout de rotinas é inteligente: uma tarefa que comprova progresso (bytes escritos) não é morta por relógio.
Auto-resposta Incidentes: detecção, diagnóstico e correção ▾
Cada situação anômala vira um incidente com ciclo de vida (detectado → diagnóstico → decisão → execução → resolvido). Correções classificadas como seguras executam automaticamente; as demais aguardam um clique de aprovação da nossa equipe — nunca da máquina sozinha.
- Lentidão: investigação read-only com ~12 sondas (locks, estatísticas velhas, planos ruins, memória, I/O), classificação de causa provável e correções específicas por causa.
- Locks: cadeia de bloqueio mapeada (quem segura, quem espera, há quanto tempo, qual aplicação); resolução com evidência registrada no incidente.
- Log de diagnóstico do banco (ex.: db2diag) escutado em tempo real — erro estrutural aparece minutos depois de acontecer, não no chamado da semana seguinte.
- Escalada: mensagem → repetição → ligação telefônica, até resposta humana. Incidente crítico não morre em e-mail.
- Toda ação automática respeita uma camada de segurança que bloqueia comandos destrutivos, mesmo vindos da nossa própria equipe.
Portal Relatório em tempo real por link exclusivo ▾
O relatório do cliente é servido por um link com token aleatório não-adivinhável, somente-leitura, renderizado no servidor — sem acesso a nada além dos dados daquele cliente.
- Conteúdo: backups (completo/contínuo) com idade, crescimento de base e tabelas, saúde de servidores (CPU, disco, I/O), rotinas executadas, testes de restore, confiabilidade do período.
- Link revogável a qualquer momento; vários links por cliente (ex.: um para a diretoria, um para o TI), ligáveis/desligáveis de forma independente.
- Horários exibidos no fuso do cliente.
Operação Agente local e plano de controle ▾
Um agente leve (binário único, sem dependências) roda no servidor e se conecta ao nosso plano de controle via mensageria segura (TLS). Ele executa as rotinas localmente e transmite o resultado em tempo real — inclusive a saída ao vivo de cada tarefa.
- Métricas de host, filesystem e crescimento de banco coletadas continuamente; previsão de esgotamento de disco antes da janela de backup.
- Se o agente reinicia ou perde conexão, tarefas órfãs são detectadas e tratadas — nada fica “rodando” fantasma.
- RPO típico: minutos (frequência dos archive logs). RTO: depende do tamanho do banco — medido e conhecido, porque testamos o restore.
Comece agora
Quanto custa um dia inteiro do seu faturamento?
A proteção custa uma fração disso. Fale com a PowerDBA: analisamos seu ambiente, mostramos onde você está exposto e ativamos a proteção sem parar sua operação.