Identificar perda de dados devido a falha de registro em banco de dados do Exchange 2013

2

Durante as últimas semanas, nosso servidor Exchange teve problemas com a falta de conclusão dos trabalhos de backup, o que fez com que as nossas unidades de log normalmente vazias fossem preenchidas até o ponto em que o Exchange desmontou bancos de dados e registrou vários erros relacionados à repetição de arquivos de log. Lamentavelmente, ninguém na equipe de backup fez seu trabalho corretamente, então no fim de semana tivemos uma situação de falha que desmontou ~ 40 bancos de dados devido a haver ~ 100GB de logs, que geralmente ficam em ~ 3GB. Isso fez com que todos que trabalhavam no fim de semana não olhassem para o histórico da questão e, em vez de entrar em contato com outras pessoas, permitir o registro em log circular depois que todos da equipe fossem instruídos a não remontar todos os bancos de dados e encerrar o dia. / p>

Ainda não ouvimos falar de qualquer perda de dados de usuários, mas o fato de todos os bancos de dados terem encontrado isso e que há reclamações sobre falhas de log, falhas de reprodução e desmontagens inesperadas. .

Além de disparar a equipe de backup, os monitores de final de semana e o administrador que decidiram habilitar o log circular após um período de tempo significativo entre os backups sem salvar os logs em qualquer lugar em caso de restauração do backup e obter o que pudemos qual é o melhor curso de ação para determinar se perdemos alguma coisa?

Existem eventos específicos que podem estar enterrados nas 3.000.000 entradas de log que abrangem a seção de seis horas enquanto isso acontecia? Está realizando uma verificação de integridade recomendada? Defrag, on ou offline?

No servidor do Exchange, geralmente, o que aconteceu é que tirei a ID e a origem do evento porque tudo parece ser genérico e de pouca ajuda para determinar se as coisas realmente foram super suladas, ou apenas arruinou minha segunda-feira:

  1. Em 'TIME', a cópia de 'DATABASE' do Banco de Dados de Armazenamento de Informações do Microsoft Exchange neste servidor apresentou um erro sério que causou o encerramento de sua atividade funcional. O erro retornado pela tentativa de remontagem foi "Há apenas uma cópia desse banco de dados de caixa de correio (DATABASE). A recuperação automática não está disponível." Consulte o log de eventos no servidor para outros eventos de armazenamento e "ExchangeStoreDb" para obter informações mais específicas sobre as falhas.

  2. Armazenamento de Informações - BANCO DE DADOS DATABASE (9564): Uma tentativa de gravar no arquivo "F: \ Logs \ DATABASE \ E0Etmp.log" no deslocamento 1048576 (0x0000000000100000) para 0 (0x00000000) bytes falhou após 0,000 segundos com erro de sistema 112 (0x00000070): "Não há espaço suficiente no disco". A operação de gravação falhará com o erro -1808 (0xfffff8f0). Se esse erro persistir, o arquivo pode estar danificado e talvez precise ser restaurado a partir de um backup anterior.

  3. Armazenamento de Informações - DATABASE (9564) BANCO DE DADOS: Não é possível criar um novo arquivo de log porque o banco de dados não pode gravar na unidade de log. A unidade pode ser somente leitura, sem espaço em disco, configurada incorretamente ou corrompida. Erro -529.

  4. Armazenamento de Informações - BANCO DE DADOS DATABASE (9564): A sequência do arquivo de log em "F: \ Logs \ DATABASE \" foi interrompida devido a um erro fatal. Nenhuma atualização adicional é possível para os bancos de dados que usam essa seqüência de arquivo de log. Por favor, corrija o problema e reinicie ou restaure a partir do backup.

  5. Armazenamento de Informações - BANCO DE DADOS DO DATABASE (9564): A recuperação / restauração do banco de dados falhou com erro inesperado -510.

  6. O serviço de Replicação de Caixa de Correio do Microsoft Exchange não pôde processar tarefas em um banco de dados de caixa de correio. Banco de dados: DATABASE Erro: MapiExceptionMdbOffline: não é possível abrir o armazenamento de mensagens. (hr = 0 x 80004005, ec = 1142) Contexto diagnóstico:

  7. Em 'TIME', a cópia do banco de dados 'DATABASE' neste servidor encontrou um erro durante a operação de montagem. Para obter mais informações, consulte o log de eventos no servidor para eventos "ExchangeStoreDb" ou "MSExchangeRepl". A operação de montagem será tentada novamente automaticamente.

Este é um servidor autônomo, portanto, os únicos erros de cópia parecem ser esperados. Também há vários erros de acesso do cliente registrados durante o tempo em que isso ocorreu, o que eu omiti.

    
por RobbieCrash 21.10.2014 / 00:29

1 resposta

3

Eu costumo pensar que você tem perda mínima de dados, se houver. Isso parece bem extremo, eu sei, mas a base para minha opinião é que novos dados pararam de chegar quando os discos foram preenchidos. Mesmo se você perder dados, o que seria perdido seria quase certamente dados que foram recebidos pelo servidor imediatamente antes da condição de disco cheio.

  • No momento em que o disco enchia o Mecanismo de Armazenamento Extensível (ESE), ele descarregava os dados de log nos logs de transação de reserva de cada banco de dados antes de desmontar o banco de dados.

  • O Exchange desmontou as lojas. Qualquer email proveniente da Internet será enfileirado pelo MX secundário (ou pelo remetente se você não tiver nenhum) e enviado posteriormente, ou NDR'd (nesse caso, o remetente estaria ciente da falha) pelo servidor do remetente. Suponho que existe uma chance de o remetente enviar uma mensagem da fila sem NDR, mas esse não é o seu problema.

  • Os clientes do Outlook não conseguirão se conectar a seus bancos de dados de armazenamento de informações, portanto, provavelmente não foi gerado nenhum novo email de clientes internos.

Você mencionou falhas de repetição do log de transações. Isso soa um pouco perturbador, mas sem saber a extensão dessas falhas, é difícil dizer. Devido à natureza dos replays do log de transações (ou seja, confirmar dados não confirmados recentemente gravados no banco de dados), a chance de falhas de reprodução terem efeito nos dados armazenados mais antigos é bastante baixa. Se os usuários não estiverem vendo problemas com os dados mais recentes em suas caixas de correio, provavelmente não serão mais tarde.

Não há realmente uma preocupação relacionada à fragmentação do banco de dados relacionada à condição completa do disco. Os padrões de gravação no banco de dados não seriam alterados porque o volume do log de transações era preenchido. A desfragmentação online ainda acontecerá normalmente. A desfragmentação offline normalmente não é mais necessária ou recomendada pela Microsoft.

É concebível que, se os bancos de dados estivessem armazenados nos volumes preenchidos, os arquivos EDB pudessem ter fragmentação do sistema de arquivos, mas, em geral, a Microsoft não recomenda a desfragmentação de volumes que contêm bancos de dados do Exchange. Você pode acessar seus arquivos .EDB com contig.exe para analisar a fragmentação deles se você quiser ter certeza.

O ESE é muito robusto. Eu acho que você provavelmente está bem.

    
por 21.10.2014 / 02:29