Introdução
A organização mantém um ETL (Extract, Transform, Load) hospedado na Microsoft Azure, responsável por extrair, transformar e carregar dados dos principais sistemas críticos do negócio. Esse pipeline é a base para relatórios, integrações, tomada de decisão e continuidade operacional.
Sistemas de origem
Active
Gestão comercial / CRM / operação de vendas
Omie
ERP — financeiro, fiscal, estoque e cadastros
3CX
Telefonia IP — chamadas, ramais e registros
RMStation
Gestão de estações / operação de campo
O ETL executa de forma contínua ou em alta frequência, mantendo os dados no Azure sempre atualizados conforme novas informações chegam desses sistemas.
Proteção dos dados
Os dados processados e armazenados por esse ETL são considerados críticos. Por isso, a infraestrutura no Azure conta com:
Em resumo: o ETL alimenta o ambiente Azure com dados dos sistemas críticos; o Azure Backup protege essa camada de dados e infraestrutura para que a operação possa ser recuperada com segurança.
Como o backup é feito no Microsoft Azure
Esta seção descreve como a Microsoft Azure implementa a proteção do ETL e dos dados associados — do mecanismo técnico à política de retenção.
1. Serviço utilizado: Azure Backup
O Azure Backup é o serviço gerenciado da Microsoft para criar e manter cópias de segurança de recursos na nuvem. No contexto do ETL, ele protege tipicamente:
| Componente do ETL | Recurso Azure | Como é protegido |
|---|---|---|
| Servidor / VM do pipeline | Azure Virtual Machine | Azure Backup (completo + incremental) |
| Banco de dados (SQL, etc.) | SQL em VM ou Azure SQL | Azure Backup ou backup nativo do serviço |
| Arquivos e staging | Azure Files / Blob Storage | Azure Backup ou redundância + versionamento |
| Orquestração (se em VM) | Discos gerenciados | Inclusos no backup da VM |
Os backups são centralizados em um Recovery Services Vault (cofre de recuperação), recurso dedicado que armazena todos os pontos de restauração.
2. Recovery Services Vault — onde ficam os backups
- Armazena os pontos de restauração gerados pela política diária
- Permite restaurar VM, banco, arquivos ou discos em minutos ou horas
- Suporta soft delete — backups excluídos por engano permanecem recuperáveis
- Pode ter imutabilidade (WORM) — proteção extra contra ransomware
3. Política de backup diário do ETL
Agendamento
| Parâmetro | Configuração típica para ETL |
|---|---|
| Frequência | Diária (1x por dia) |
| Horário | Fora do pico (ex.: 02:00) — após janela principal de carga do ETL |
| Tipo | Completo na primeira execução; incrementais nos dias seguintes |
Retenção
| Camada | Período sugerido | Finalidade |
|---|---|---|
| Diária | 30 dias | Restauração rápida de incidentes recentes |
| Semanal | 12 semanas | Recuperação de problemas detectados com atraso |
| Mensal | 12 meses | Histórico operacional e auditoria |
| Anual | 5 anos (opcional) | Compliance e exigências regulatórias |
Exemplo de política aplicada ao ETL
RPO (Recovery Point Objective): até 24 horas — no máximo um dia de dados pode ser perdido em cenário de desastre total, desde que o backup diário tenha concluído com sucesso.
RTO (Recovery Time Objective): variável conforme tamanho dos dados; com Instant Restore, as restaurações mais recentes tendem a ser mais rápidas.
4. Atualização constante vs backup diário
São camadas complementares de proteção:
| Camada | O que faz | Frequência |
|---|---|---|
| ETL / pipeline | Extrai dados de Active, Omie, 3CX e RMStation e grava no Azure | Contínua ou em intervalos curtos |
| Redundância do storage | Replica dados entre racks ou regiões (LRS, ZRS, GRS) | Automática, em tempo real |
| Azure Backup | Cria ponto de restauração independente do ambiente de produção | Diária |
A atualização constante mantém os dados no Azure alinhados com os sistemas de origem. O backup diário garante um snapshot recuperável mesmo se houver corrupção lógica, exclusão em massa, ransomware ou falha na pipeline.
5. Como o backup é executado (passo a passo)
Extensão de backup
Instalada na VM do ETL (ou habilitada no recurso protegido)
Snapshot consistente
O Azure coordena com o SO e, se aplicável, com o SQL para capturar dados consistentes
Transferência incremental
Apenas blocos alterados desde o último backup são enviados ao cofre
Armazenamento no Vault
O ponto de restauração fica disponível conforme a política de retenção
Monitoramento
Falhas de backup geram alertas no Azure Monitor / Log Analytics
6. Tipos de restauração disponíveis
| Cenário | Ação no Azure |
|---|---|
| VM do ETL corrompida ou inacessível | Restaurar VM completa ou disco a partir do Vault |
| Banco de dados com dados incorretos | Restaurar banco para um ponto anterior (PITR, se habilitado) |
| Arquivo ou pasta excluída no staging | Restaurar item específico do backup de Azure Files |
| Desastre na região | Cross-region restore (se GRS estiver habilitado no cofre) |
7. Proteção adicional para Blob Storage e arquivos
| Recurso | Função |
|---|---|
| Redundância GRS/GZRS | Cópia geográfica automática |
| Versionamento de blobs | Histórico de versões anteriores |
| Soft delete | Recuperação após exclusão acidental |
| Azure Backup (Azure Files) | Backup agendado de compartilhamentos SMB |
8. Configuração no portal Azure
- Criar Recovery Services vault na mesma região do ETL (ou região pareada, se usar GRS)
- Em Backup policies, criar a política diária com retenção desejada
- Habilitar backup na VM do ETL, no banco de dados e em Azure Files, se aplicável
- Associar cada recurso à política
ETL-Sistemas-Criticos-Diaria - Configurar alertas de falha de backup no Azure Monitor
9. Comandos Azure CLI
10. Custos
| Fator | Impacto |
|---|---|
| Volume de dados do ETL no cofre | Principal driver de custo (GB/mês) |
| Retenção longa (mensal/anual) | Mais pontos = mais armazenamento |
| Número de VMs e bancos protegidos | Cada recurso contribui para o total |
| Região Azure | Preços variam por localização |
Estimativas: Calculadora de preços Azure
Checklist — ETL e backup
- VM do ETL com backup diário habilitado
- Banco de dados do ETL incluído na política de backup
- Azure Files / Blob com versionamento e soft delete (se usado no pipeline)
- Recovery Services vault com soft delete ativo
- Alertas configurados para falha de backup
- Teste de restauração realizado (trimestral)
- RPO e RTO documentados e alinhados com o negócio
- Procedimento de restore documentado com responsáveis
Teste de restauração
Uma política de backup só é confiável após validação prática:
- Restaurar VM ou banco do ETL em resource group de teste
- Validar integridade dos dados de Active, Omie, 3CX e RMStation consolidados
- Medir tempo real de restauração (RTO)
- Registrar resultado e ajustar política, se necessário
- Repetir periodicamente (recomendado: trimestral)
Referências Microsoft
- Visão geral do Azure Backup
- Backup de VMs Azure
- Backup de SQL no Azure
- Backup de Azure Files
- Imutabilidade e soft delete
Documento atualizado em: junho/2026