APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Backups automáticos fazem parte da proteção de Azure SQL Database, mas retenção e redundância precisam de configuração adequada aos objetivos. PITR recupera um ponto dentro da janela disponível e cria uma nova base, sem sobrescrever diretamente a existente. O plano inclui validação e mudança controlada das conexões. LTR conserva backups selecionados por períodos maiores; não fornece uma cadeia contínua ilimitada para escolher qualquer segundo de anos anteriores. Duração de retenção e localização das cópias são dimensões distintas. Uma cópia local não prova capacidade de geo-restore depois de perda regional. Verifica a opção de redundância e a disponibilidade efetiva das cópias antes do incidente.
Aplicação guiada
Num erro fictício de atualização de posições, recuperar para antes do erro pode excluir movimentos válidos posteriores. Preserva a origem, reconcilia eventos e avalia correção seletiva quando apropriado. O sucesso técnico do restauro não reverte integrações externas. Com TDE e chaves geridas pelo cliente, backups antigos podem continuar a depender de versões anteriores do protector. Rodar a chave não volta a cifrar automaticamente essas cópias; apagar versões antigas pode impedir recuperação. Mantém material necessário e acesso do destino ao Key Vault ou HSM, com proteção e owners definidos. O ensaio deve medir tanto tempo até disponibilidade como perda de dados real, incluindo autenticação e acesso às chaves.
PITR para 09:59 após erro às 10:00 exige avaliar movimentos válidos confirmados depois das 10:00.
Armadilhas comuns
LTR como PITR ilimitado; backup local como geográfico; chave nova como substituto de todas as antigas.
Tópicos relacionados: Plataforma, capacidade e migração · Identidade, rede e cifragem · Dados sensíveis e evidência
Recuperabilidade depende de dados, histórico e chaves acessíveis.
Referência: PITR and geo restore · DP-300 English objectives effective 2026-04-24