Banco que não monta, servidor em dirty shutdown, disco de log cheio, caixa de correio apagada. Aqui está o caminho de volta em cada cenário — e o comando que você não deve rodar antes de ter uma cópia.
No Exchange existe um comando que resolve — e que apaga o que não conseguiu consertar. Quase toda perda definitiva que chega até nós passou por ele, rodado antes da hora. Se você é o técnico chamado, comece por aqui.
O reparo em modo forçado (eseutil /p) não conserta: ele descarta as páginas corrompidas para conseguir montar o banco. Isso significa perda permanente e silenciosa de conteúdo. Copie o EDB e a pasta de logs para outro volume antes — e trate esse comando como último recurso, não como primeiro passo.
Verifique com eseutil /mh se o banco está em clean ou dirty shutdown. Em dirty shutdown com logs íntegros, a recuperação suave (eseutil /r) apenas reaplica as transações — sem descartar nada. É o caminho seguro, e resolve boa parte dos casos.
Banco desmontado por falta de espaço é comum — e apagar arquivos de log na pressa impede a recuperação suave, empurrando você para o reparo destrutivo. Libere espaço em outro lugar ou mova os logs; não os elimine.
Se o log circular estiver habilitado, não existe recuperação a ponto no tempo: os logs são sobrescritos e só resta a última cópia completa. Vale conferir essa configuração antes de prometer prazo ao cliente.
Com o Exchange protegido pelo SERVER BACKUP, a cópia é consistente em nível de aplicação — o banco volta montável, não como um arquivo copiado no susto.
Devolve o banco de dados inteiro para o servidor original ou para outro. É o caminho quando o volume falhou, quando o servidor foi perdido ou quando a corrupção alcançou a base toda.
Sem mexer nas outras. Serve para o funcionário cuja caixa foi apagada, para a conta excluída depois do prazo de retenção, ou para devolver o histórico de alguém que voltou à empresa.
Um e-mail, um anexo, um item de calendário. Restauração granular: você localiza o item dentro da cópia e traz só ele, sem restaurar a base nem interromper o serviço.
Hardware perdido, migração ou ambiente comprometido: a base sobe em outro Exchange. É também o que permite validar a cópia sem tocar na produção.
Um Database Availability Group mantém cópias sincronizadas entre servidores — e isso é ótimo contra falha de hardware. Mas ele replica o estado atual: corrupção lógica, exclusão de caixa e ransomware são copiados para as réplicas com a mesma eficiência.
Backup é cópia em ponto no tempo, retida e isolada. É o que permite voltar para antes do problema — coisa que nenhuma réplica faz.
No Exchange, backup mal configurado não é só risco de perda — é também disco enchendo até o banco desmontar sozinho.
A cópia é coordenada com o próprio Exchange, para que o banco volte íntegro e montável — e não em estado que exija reparo antes de abrir.
Com o backup íntegro concluído, os logs de transação já aplicados podem ser liberados. É isso que impede o clássico disco de log cheio derrubando o serviço.
O destino não é outro disco da mesma máquina: é data center Tier-III no Brasil, replicado em dois estados. O que derruba o servidor não alcança a cópia.
| Cenário no Exchange Server | Caminho recomendado |
|---|---|
| Banco em dirty shutdown, logs íntegros | Recuperação suave, que reaplica as transações. Nada é descartado. Não parta para reparo forçado. |
| Banco corrompido, logs perdidos | Restaurar a base a partir da cópia. É mais rápido e mais íntegro do que reparo forçado, que descarta o que não consegue ler. |
| Disco de log cheio, banco desmontou | Liberar espaço sem apagar log e remontar. Depois, revisar a rotina de backup, que é o que deveria estar liberando os logs. |
| Caixa de correio excluída além do prazo | Restauração da caixa individual a partir da cópia, sem tocar nas demais. |
| Ransomware no servidor | Voltar a um ponto anterior à infecção. Com storage imutável contratado, a cópia não pôde ser cifrada nem apagada. |
| Servidor perdido ou migração | Restauração em outro Exchange, com a base íntegra. |
O mesmo padrão de proteção da bringback, aplicado ao Exchange Server.
Dados cifrados em trânsito e em repouso. A chave é sua — só você acessa o conteúdo.
Com storage imutável (object lock / WORM) contratado, o dado não pode ser deletado, alterado ou criptografado.
Verificação periódica com correção: o dado é conferido para garantir que está 100% restaurável.
Elimina blocos repetidos e comprime — menos espaço, menos banda, mais retenção pelo mesmo custo.
Replicado em 2 data centers Tier-III em estados diferentes, de 3 que operamos no Brasil.
Políticas diária, semanal, mensal e anual, com versionamento — do jeito que a auditoria pede.
* A imutabilidade depende do tipo de storage contratado (armazenamento imutável / object lock / WORM). É uma característica da infraestrutura de armazenamento, definida na contratação.
Todo backup é monitorado 24/7 na Plataforma iCOM e passa por testes de recuperação (Restore Drill): periodicamente, os dados são restaurados em ambiente isolado, a integridade é validada e vira relatório. É esse relatório que você mostra quando o cliente — ou a auditoria — pergunta se o dado volta mesmo.
Só em último caso, e nunca antes de copiar o EDB e a pasta de logs para outro volume. O reparo forçado descarta as páginas que não consegue ler para conseguir montar — o banco abre, mas com perda permanente e sem aviso. Se o estado for dirty shutdown com logs íntegros, a recuperação suave resolve sem descartar nada.
A suave reaplica as transações que ficaram nos logs e devolve o banco ao estado consistente — não perde dado. O forçado remove o que está corrompido para viabilizar a montagem — perde dado. São operações com finalidades opostas, e a ordem importa.
Não. Sem os logs você perde a chance de recuperação suave e fica dependente de reparo destrutivo. Libere espaço em outro volume ou mova os arquivos, remonte, e depois revise a rotina de backup — é ela que deveria estar liberando os logs após cada cópia íntegra.
Sim. O DAG protege contra falha de servidor, replicando o estado atual. Se uma caixa for excluída ou a base for cifrada, a réplica recebe o mesmo problema. Backup é ponto no tempo, retido e isolado.
Sim, sem afetar as demais nem interromper o serviço — e também apenas um item específico, como um e-mail ou um anexo.
Atrapalha bastante: com log circular os arquivos são sobrescritos, então não há recuperação a ponto no tempo. Você fica limitado à última cópia completa. Vale checar essa configuração antes de assumir prazos.
Sim. É o caminho quando o hardware foi perdido, durante migração, ou para validar a cópia em ambiente isolado sem tocar na produção.
Se você é o técnico que atende quando o e-mail da empresa para, existe um jeito de essa madrugada não se repetir — e de virar receita recorrente sua. Manda o cenário no WhatsApp: versão do Exchange, tamanho das bases e a retenção que o cliente precisa. A resposta vem em linguagem de técnico, sem ligação e sem roteiro comercial.