Planejamento de Backup: Framework Completo para Implementar do Zero
Planejar backup não é apenas 'instalar um software e agendar'. É um processo técnico que começa com inventário de dados, passa pela classificação por criticidade, definição de RPO/RTO para cada sistema, escolha de estratégia e termina com monitoramento contínuo. Este guia mostra o framework completo.
Pontos-Chave deste Artigo
- Planejamento de backup segue 6 etapas: inventário → classificação → RPO/RTO → estratégia → implementação → monitoramento
- RPO e RTO são definidos pelo impacto no negócio, não pela TI
- Sem inventário completo, algum sistema ficará desprotegido — e será justamente o que vai falhar
- Com BaaS gerenciado, a implementação cai de semanas para dias
O Que é Planejamento de Backup
Planejamento de backup é o processo técnico de engenharia que define como os dados da empresa serão protegidos. Não é apenas "instalar software e agendar backup às 23h". É uma análise estruturada que responde 5 perguntas fundamentais:
- O que proteger? (inventário de dados)
- Quanto posso perder? (RPO)
- Quanto tempo posso ficar parado? (RTO)
- Como proteger? (estratégia técnica)
- Onde armazenar? (local, nuvem, híbrido)
Planejamento vs Política vs Procedimentos
| Fase | Foco | Quem Faz | Resultado |
|---|---|---|---|
| Planejamento | Engenharia e projeto técnico | TI + negócio | Arquitetura da solução de backup |
| Política | Governança e formalização | TI + compliance + diretoria | Documento formal com regras e responsabilidades |
| Procedimentos | Operação do dia a dia | Equipe de TI | Checklists diários, semanais, mensais |
O planejamento vem primeiro. A política formaliza as decisões. Os procedimentos operacionalizam. Os três são complementares e necessários para proteção real.
Etapa 1: Inventário de Dados
O primeiro passo — e o mais negligenciado — é saber exatamente o que existe na infraestrutura. Sem inventário, algum sistema ficará desprotegido. E pela lei de Murphy, será justamente o que vai falhar.
O Que Catalogar
| Categoria | Itens a Catalogar | Informações Necessárias |
|---|---|---|
| Servidores físicos | Todos os servidores on-premise | Hostname, SO, função (AD, file, app, DB), volume de dados, taxa de crescimento mensal |
| Máquinas virtuais | VMs em VMware, Hyper-V, Proxmox | Host, hypervisor, SO guest, volume de disco alocado vs usado |
| Bancos de dados | SQL Server, MySQL, PostgreSQL, Oracle, MongoDB | Tipo, tamanho, taxa de transações/dia, janela de manutenção |
| SaaS | Microsoft 365, Google Workspace, CRM, ERP cloud | Número de usuários, volume de dados, APIs disponíveis para backup |
| Endpoints | Estações com dados locais, notebooks da diretoria | SO, volume de dados locais, frequência de uso offline |
| Dados não estruturados | File servers, NAS, SharePoint | Volume total, taxa de crescimento, estrutura de pastas |
Dica prática: use planilha ou CMDB (Configuration Management Database). Atualize a cada nova contratação de sistema ou mudança de infraestrutura.
Etapa 2: Classificação por Criticidade
Nem todo dado tem a mesma importância. Classificar por criticidade permite investir mais proteção onde o impacto de perda é maior.
| Classe | Definição | Exemplos | Proteção Necessária |
|---|---|---|---|
| Crítico | Empresa para de operar se perder | ERP, banco de dados de produção, e-commerce, AD/LDAP, e-mail | RPO ≤ 1h, RTO ≤ 4h, imutável, offsite, DRaaS |
| Importante | Impacto significativo, mas empresa continua operando parcialmente | File server, CRM, sistemas de RH, sites internos | RPO ≤ 24h, RTO ≤ 8h, offsite |
| Auxiliar | Impacto menor, pode ser reconstruído | Ambientes de teste, documentação pública, logs antigos | RPO ≤ 48h, RTO ≤ 24-48h, backup básico |
Quem classifica: a classificação deve envolver negócio + TI juntos. A TI entende a infraestrutura; o negócio entende o impacto financeiro e operacional de cada sistema parar.
Etapa 3: Definição de RPO e RTO por Sistema
RPO (Recovery Point Objective) define quanto de dados pode ser perdido. RTO (Recovery Time Objective) define quanto tempo o sistema pode ficar indisponível. Esses dois parâmetros determinam toda a estratégia técnica.
| Sistema | RPO Recomendado | RTO Recomendado | Justificativa |
|---|---|---|---|
| ERP | 15 min — 1h | 1 — 4h | Transações financeiras, estoque, faturamento — cada hora parada custa milhares |
| Banco de dados | 5 min — 1h | 1 — 4h | Dados transacionais. Downtime impacta diretamente a receita |
| 1 — 4h | 2 — 8h | Comunicação crítica, mas equipes podem usar celular temporariamente | |
| Active Directory | 4 — 24h | 1 — 4h | Sem AD, ninguém faz login. Mas muda pouco (baixo RPO é suficiente) |
| File server | 4 — 24h | 4 — 12h | Importante, mas geralmente não impede operação completa |
| Microsoft 365 | 4 — 12h | 4 — 24h | Microsoft garante infraestrutura, mas não protege contra exclusão/ransomware |
| Web server / e-commerce | 15 min — 1h | 30 min — 2h | Cada minuto offline é venda perdida e SEO prejudicado |
O RPO determina a frequência do backup. O RTO determina o tipo de restauração necessário. Sistemas com RTO < 4h precisam de bare-metal recovery ou DRaaS — restauração manual de SO + apps + dados leva 1-3 dias.
Etapa 4: Escolha da Estratégia Técnica
Tipo de Backup
| Tipo | Quando Usar | RPO Típico |
|---|---|---|
| Incremental | Diário (padrão para maioria dos sistemas). Copia só o que mudou desde o último backup | 24h |
| Diferencial | Quando precisa de restauração mais rápida que incremental. Copia tudo que mudou desde o último full | 24h |
| CDP (Continuous Data Protection) | Bancos de dados críticos, e-commerce. Backup contínuo de cada mudança | Minutos |
| Transaction Log | Bancos de dados SQL Server, PostgreSQL, Oracle. Backup dos logs a cada 5-15 min | 5-15 min |
Destino do Backup
| Destino | Vantagem | Limitação | Quando Usar |
|---|---|---|---|
| Servidor local | Restauração rápida via rede local | Não protege contra desastre físico ou ransomware que compromete rede local | 1ª linha — restauração rápida |
| Nuvem offsite | Proteção contra desastre e ransomware. Imutabilidade | Restauração mais lenta (depende da internet) | 2ª linha — proteção offsite obrigatória |
| Híbrido | Combina velocidade local + segurança offsite | Custo de ambos | Estratégia recomendada para a maioria |
Política de Retenção
A retenção define por quanto tempo cada backup é mantido. A abordagem mais comum é GFS (Grandfather-Father-Son):
- Diários (Son): manter últimos 30 dias
- Semanais (Father): manter últimas 12 semanas (backup de sexta ou domingo)
- Mensais (Grandfather): manter últimos 12 meses (backup do 1º dia do mês)
- Anuais: manter 3-7 anos (compliance LGPD, fiscal, setorial)
Retenção excessiva consome storage. Retenção insuficiente pode violar compliance. O equilíbrio depende de regulamentações do setor (BACEN exige 5 anos, fiscal exige 5 anos, LGPD depende da finalidade).
Etapa 5: Implementação
Com o planejamento definido, a implementação segue um roteiro previsível:
- Preparar infraestrutura: servidor de backup local (se aplicável), configurar storage na nuvem, rede dedicada para backup
- Instalar agentes: agente de backup em cada servidor/estação a ser protegido
- Configurar jobs: para cada sistema, definir: tipo de backup, agendamento, retenção, criptografia, destino
- Executar backup full inicial: o primeiro backup é sempre full (mais demorado). Planejar para fim de semana ou janela de baixa utilização
- Testar restauração: restaurar dados de cada job configurado para validar que funciona
- Configurar monitoramento: alertas de falha, dashboards, relatórios automáticos
- Documentar: registrar toda a configuração para procedimentos operacionais e auditoria
Cronograma de Implementação
| Porte da Empresa | Servidores/Sistemas | Planejamento | Implementação | Validação |
|---|---|---|---|---|
| Micro/Pequena | 1-5 | 2-3 dias | 1-3 dias | 1 dia |
| PME | 5-15 | 1-2 semanas | 1-2 semanas | 3-5 dias |
| Média empresa | 15-50 | 2-4 semanas | 2-4 semanas | 1-2 semanas |
| Grande empresa | 50+ | 4-8 semanas | 4-12 semanas | 2-4 semanas |
Com BaaS gerenciado (DataBackup), os prazos caem drasticamente: o agente instala em 5 minutos por servidor, a configuração é via painel web, e a equipe DataBackup auxilia no setup. Uma PME com 10 servidores pode estar 100% protegida em 1-3 dias.
Etapa 6: Monitoramento Contínuo
O planejamento não termina na implementação. Monitoramento contínuo garante que a proteção continua funcionando:
- Diário: verificar status de jobs, volume de dados, alertas (checklist diário)
- Semanal: teste de restauração de arquivos, revisão de erros
- Mensal: teste de restauração de banco de dados, revisão de capacidade
- Trimestral: teste de bare-metal recovery, revisão de política
- Anual: re-planejamento completo — inventário atualizado, classificação revisada, RPO/RTO reavaliados
A DataBackup oferece planejamento assistido, implementação guiada e monitoramento 24/7 — para que sua equipe de TI foque no que importa, enquanto a proteção de dados funciona em piloto automático. Backup imutável em data center Tier III+, criptografia AES-256, deduplicação e suporte técnico brasileiro. Teste grátis 14 dias.