A Microsoft protege ambientes com banco de dados por meio de backups do sistema. No entanto, existem limites de retenção, regras para restauração e diferenças entre recuperar um ambiente inteiro e recuperar alguns registros.
Conhecer essas condições evita uma descoberta desagradável justamente quando a empresa precisa restaurar informações importantes.
O Dynamics 365 possui backup automático?
Sim. Os aplicativos de Customer Engagement, como Dynamics 365 Sales e Customer Service, utilizam o Microsoft Dataverse.
Os ambientes com banco de dados recebem backups automáticos do sistema. A tecnologia utiliza os recursos de disponibilidade e proteção do Azure SQL Database.
Esses backups ocorrem continuamente. Portanto, o processo não se limita a uma única cópia executada durante a madrugada.
Por quanto tempo o backup do Dynamics 365 fica disponível?
Por padrão, os backups de ambientes de produção e de não produção são mantidos por até sete dias.
Isso inclui ambientes dos tipos:
- Produção;
- Sandbox;
- Desenvolvedor;
- Microsoft Teams;
- Ambiente padrão.
Entretanto, existem diferenças importantes.
Ambientes de avaliação, também conhecidos como trial, não possuem o mesmo suporte de backup e restauração. Além disso, o ambiente padrão não aceita backup manual e possui regras próprias de recuperação.
É possível aumentar a retenção para 28 dias?
Sim, mas essa possibilidade possui condições.
Ambientes de produção configurados como Managed Environments podem ter a retenção ampliada de sete para até 28 dias.
A alteração pode ser feita pelo centro de administração da Power Platform ou por PowerShell.
No entanto, ativar Managed Environments envolve requisitos de licenciamento. A empresa deve analisar os usuários, os aplicativos, os fluxos e os direitos fornecidos pelas licenças contratadas.
Portanto, a retenção ampliada não deve ser ativada sem avaliar o impacto técnico e comercial.
O que são backups manuais?
O backup manual é um ponto de restauração identificado pela empresa.
Ele deve ser criado antes de mudanças relevantes, como:
- Grandes personalizações;
- Importação de dados;
- Atualização de uma solução;
- Alteração estrutural;
- Implantação de nova versão;
- Execução de automações em massa;
- Mudanças importantes de segurança;
- Reorganização do modelo de dados.
A Microsoft mantém esses backups por sete dias no cenário padrão.
Em ambientes de produção gerenciados, a retenção também pode ser ampliada para até 28 dias.
O backup manual cria uma cópia separada do banco?
Não exatamente.
Como o Dataverse utiliza backups contínuos, o backup manual funciona como um ponto identificado para restauração. Ele recebe um nome e uma referência de data e hora.
Isso facilita localizar o momento anterior a uma mudança importante.
Ainda assim, a empresa não recebe um arquivo completo do banco de dados para baixar e armazenar onde quiser.
É possível baixar o backup do Dataverse?
A Microsoft não fornece uma opção para baixar uma cópia do backup nativo do banco de dados.
Se a empresa precisa manter dados fora do ambiente, deverá avaliar outras estratégias, como:
- Exportação de dados;
- Integração com repositórios externos;
- Azure Synapse Link for Dataverse;
- Microsoft Fabric;
- Soluções especializadas de backup;
- Processos de arquivamento;
- Migração periódica de informações.
Essas alternativas possuem objetivos diferentes.
Exportar dados para um arquivo, por exemplo, não equivale necessariamente a criar um backup completo e restaurável do ambiente.
Como funciona a restauração do Dynamics 365?
A restauração sobrescreve um ambiente de destino com o estado armazenado no ponto escolhido.
Existem algumas regras importantes:
- A origem e o destino precisam estar na mesma região;
- O ambiente de destino precisa ser compatível;
- A operação exige capacidade disponível;
- Ambientes gerenciados devem ser restaurados para ambientes gerenciados;
- Origem e destino precisam possuir Dataverse;
- Políticas empresariais e chaves de criptografia podem afetar a operação.
Além disso, um backup não pode ser restaurado diretamente sobre um ambiente de produção.
Por que o backup não é restaurado diretamente em produção?
Essa restrição ajuda a evitar que um administrador sobrescreva acidentalmente o ambiente utilizado pela empresa.
Para restaurar o próprio ambiente de produção, normalmente é necessário:
- Alterar o tipo do ambiente para sandbox;
- Executar a restauração;
- Validar os dados e a solução;
- Alterar novamente o ambiente para produção;
- Confirmar integrações, caixas de correio e automações;
- Liberar o acesso aos usuários.
A empresa também pode restaurar o backup em outro ambiente sandbox para analisar os dados antes de tomar uma decisão.
Essa abordagem costuma ser mais segura quando é necessário recuperar registros sem eliminar informações criadas depois do ponto de restauração.
Restaurar um ambiente apaga os dados atuais?
A restauração sobrescreve o ambiente escolhido como destino.
Imagine que um erro tenha eliminado registros na segunda-feira. Na quarta-feira, a empresa decide restaurar um ponto de domingo diretamente sobre o ambiente afetado.
Os registros existentes apenas na segunda, terça e quarta-feira podem deixar de aparecer no ambiente restaurado.
Por isso, a decisão precisa considerar duas necessidades:
- Recuperar o que foi perdido;
- Preservar o que foi criado depois do incidente.
Em muitos casos, a melhor estratégia é restaurar o backup em um ambiente separado, localizar os dados ausentes e planejar sua reinserção no ambiente atual.
É possível recuperar apenas um registro?
O backup nativo do ambiente foi projetado principalmente para restauração de ambientes, não para recuperação instantânea e individual de registros.
Se um usuário excluir uma conta, oportunidade ou ocorrência, pode não existir um botão simples para restaurar apenas aquele item diretamente do backup.
A empresa pode utilizar diferentes alternativas:
- Auditoria;
- Lixeira do Dataverse, quando disponível e configurada;
- Restauração em ambiente separado;
- Exportações periódicas;
- Integração com repositórios externos;
- Ferramentas especializadas;
- Recriação controlada do registro.
O melhor caminho depende do tipo de dado, dos relacionamentos e do tempo transcorrido desde a exclusão.
A lixeira do Dataverse substitui o backup?
Não.
A lixeira pode ajudar a recuperar registros excluídos em cenários compatíveis. No entanto, ela não substitui a proteção do ambiente completo.
Backup e lixeira resolvem problemas diferentes.
A lixeira atende exclusões de registros. Já o backup pode ser necessário em situações como falha de implantação, alteração estrutural, importação incorreta ou automação que modificou grande quantidade de dados.
Os logs de auditoria também são restaurados?
Os logs de auditoria exigem atenção especial.
Durante determinadas restaurações, eles podem ser excluídos do processo por padrão. Isso ocorre porque sua inclusão pode aumentar significativamente o tempo necessário.
Caso a auditoria seja importante para requisitos legais ou investigações, a equipe deve verificar explicitamente sua inclusão.
Não presuma que todos os históricos estarão disponíveis apenas porque o ambiente foi restaurado.
O backup protege contra uma importação incorreta?
Sim, desde que exista um ponto de restauração adequado e a empresa aja dentro do período de retenção.
Ainda assim, restaurar o ambiente inteiro pode ser uma medida desproporcional.
Uma importação incorreta pode:
- Criar registros duplicados;
- Alterar dados válidos;
- Remover relacionamentos;
- Disparar automações;
- Enviar notificações;
- Atualizar sistemas integrados.
O backup ajuda a recuperar o Dataverse. Porém, ele não desfaz automaticamente efeitos produzidos em sistemas externos.
Se uma automação enviou informações erradas ao ERP, por exemplo, a restauração do CRM não reverte necessariamente o que ocorreu no ERP.
O backup recupera integrações e conexões?
A restauração recupera dados e componentes do ambiente conforme as regras da plataforma.
Contudo, integrações precisam ser validadas depois da operação.
A equipe deve conferir:
- Referências de conexão;
- Contas utilizadas nas conexões;
- Fluxos do Power Automate;
- Webhooks;
- Aplicativos registrados;
- Endpoints;
- Caixas de correio;
- Sincronização com Outlook;
- Integrações com ERP;
- Chaves e segredos;
- Parâmetros do ambiente;
- Processos agendados.
Alguns componentes podem continuar apontando para serviços externos. Portanto, reativá-los sem validação pode causar novos problemas.
O backup elimina a necessidade de um plano de continuidade?
Não.
O backup é apenas uma parte da continuidade do negócio.
A empresa também precisa definir:
- Quem identifica o incidente;
- Quem pode solicitar a restauração;
- Quem aprova a perda potencial de dados;
- Qual ambiente será utilizado;
- Quanto tempo a operação pode ficar parada;
- Quais integrações precisam ser interrompidas;
- Como os usuários serão informados;
- Como os dados serão validados;
- Como será feito o retorno à produção;
- Quais evidências devem ser preservadas.
Sem essas definições, o backup existe, mas a recuperação continua improvisada.
O que são RPO e RTO?
RPO e RTO são dois conceitos importantes para planejar a recuperação.
RPO: quanto dado a empresa pode perder?
O Recovery Point Objective define a perda máxima aceitável de dados.
Se o RPO for de quatro horas, a empresa considera aceitável perder até quatro horas de registros em uma recuperação.
Esse limite precisa considerar vendas, atendimentos, pedidos, aprovações e integrações.
RTO: quanto tempo o sistema pode ficar indisponível?
O Recovery Time Objective define o prazo esperado para restabelecer a operação.
Uma equipe comercial pode tolerar algumas horas sem o CRM. Já uma central de atendimento pode sofrer impacto significativo após poucos minutos.
Backup disponível não significa restauração imediata.
O tempo depende do tamanho do ambiente, da validação, das integrações e das decisões necessárias durante o incidente.
O backup nativo é suficiente?
Para muitas empresas, o backup nativo oferece uma base importante de proteção.
No entanto, ele pode ser insuficiente quando a organização precisa de:
- Retenção superior a 28 dias;
- Recuperação granular frequente;
- Cópia dos dados fora da plataforma;
- Requisitos regulatórios específicos;
- Imutabilidade;
- Histórico de longo prazo;
- Recuperação independente de registros;
- Comparação entre versões;
- Arquivamento por vários anos;
- RPO e RTO muito reduzidos.
A decisão depende do risco e da importância dos dados.
Uma empresa não deve contratar uma solução adicional apenas por medo. Porém, também não deve descobrir as limitações do backup nativo durante um incidente real.
Quando avaliar uma solução adicional de backup?
Uma solução complementar pode fazer sentido quando:
- O Dynamics 365 é crítico para a operação;
- Existem dados regulados;
- A retenção nativa é insuficiente;
- Exclusões acidentais são frequentes;
- A recuperação granular é necessária;
- A empresa precisa manter cópias independentes;
- Auditorias exigem retenção prolongada;
- O tempo de recuperação precisa ser menor;
- Existem muitas integrações;
- A organização possui uma política corporativa de backup.
A ferramenta escolhida deve ser validada tecnicamente.
É importante confirmar quais componentes ela protege, como restaura relacionamentos e quais limites existem para anexos, atividades, auditoria e customizações.
Checklist de backup do Dynamics 365 e Dataverse
A empresa pode começar respondendo às seguintes perguntas:
- Quais ambientes possuem Dataverse?
- Quais ambientes são de produção?
- Eles estão configurados como Managed Environments?
- Qual é o período atual de retenção?
- Quem possui permissão para restaurar?
- Existe capacidade suficiente para uma restauração?
- Há um ambiente sandbox disponível?
- As integrações estão documentadas?
- Existe auditoria ativa?
- Há dados que precisam ser mantidos por mais de 28 dias?
- Qual é o RPO aceitável?
- Qual é o RTO necessário?
- A equipe já testou uma restauração?
- Existe um procedimento de comunicação?
- Os responsáveis sabem o que fazer durante um incidente?
Se várias respostas forem desconhecidas, a empresa possui backup, mas ainda não possui um plano confiável de recuperação.
Boas práticas antes de mudanças importantes
Antes de uma implantação ou alteração de grande impacto:
- Crie um backup manual identificado;
- Confirme se ele foi processado;
- Registre a versão da solução;
- Exporte a solução atual quando aplicável;
- Documente os componentes alterados;
- Pause integrações que possam gerar efeitos indesejados;
- Valide a capacidade disponível;
- Defina um plano de reversão;
- Informe os responsáveis;
- Execute a mudança em horário controlado.
Depois da alteração, teste os processos críticos.
Não verifique apenas se a solução foi importada. Confirme se usuários, dados, automações e integrações continuam funcionando.
Testar a recuperação é realmente necessário?
Sim.
Uma estratégia de backup nunca testada é apenas uma expectativa.
O teste permite descobrir:
- Permissões ausentes;
- Dependências;
- Falta de capacidade;
- Integrações não documentadas;
- Tempo real da operação;
- Componentes que exigem ajuste;
- Responsáveis que não conhecem o procedimento.
A empresa não precisa interromper a produção para testar.
Ela pode executar uma restauração controlada em sandbox e documentar o processo.
Conclusão
O Dynamics 365 e o Dataverse possuem proteção automática por meio de backups contínuos.
Por padrão, a retenção é de sete dias. Ambientes de produção gerenciados podem ampliar esse prazo para até 28 dias, desde que os requisitos aplicáveis sejam atendidos.
Entretanto, backup automático não resolve sozinho todos os cenários.
A empresa precisa entender como funciona a restauração, quanto tempo pode ficar sem o sistema, quais dados podem ser perdidos e como preservar informações criadas depois do ponto recuperado.
A STG Consultoria pode revisar os ambientes, as integrações e os procedimentos de administração do Dynamics 365. A análise também pode identificar riscos de recuperação, licenciamento e governança antes que eles se transformem em uma paralisação.
Fale com a STG para avaliar sua estratégia de backup e continuidade. É melhor testar o plano enquanto tudo está funcionando do que tentar aprendê-lo durante uma emergência.