Um problema que já me aconteceu algumas vezes e já precisei resolver para alguns amigos é o uso do disco externo eSATA desaparecer após conectado, ou mesmo apresentar lentidão extrema ao ser inserido demorando muito para ser detectado como letra.

SINTOMA

Ao olhar o Event Viewer você provavelmente encontrará um dos eventos abaixo:

Evento 51: An error was detected on device \Device\Harddisk?\DR? during a paging operation.

Evento 9: The device, \Device\Ide\iaStor0, did not respond within the timeout period

O evento 9 é consequencia do evento 51 que indica erro ao criar paginação para o disco que foi inserido.

CAUSA

Diferente de um disco USB que tem acesso limitado a recursos, os discos eSATA entram no mesmo barramento do disco fixo da maquina, o que faz com que ele apareça como unidade de paginação, como mostra a figura abaixo.

Configurado em modo automático, o Windows tentará criar no disco removível um arquivo de paginação, o que gera o erro.

SOLUÇÃO

Altere o gerenciamento de memória virtual desligando o modo automático em TODOS OS DISCOS e deixe apenas no disco C: ou outro fixo desejado e o problema não ocorrerá mais.

Recebo muitas perguntas sobre o funcionando do DPM após ter publicado os videos do produto (http://bit.ly/rh35b6).

Muitas questões estão relacionadas ao uso de fitas e robôs, por isso editei os post sobre uso de fitas no mes passado (http://bit.ly/nZY96w) e agora vou abordar outros erros muito comuns e como solucioná-los.

Erro com Volume Shadow Services (VSS)

O processo do DPM não é realizado diretamente nos dados e sim a partir dos dados de snapshot utilizando o VSS, que é conhecido pelo Shadow Copy.

Sendo assim, a maioria dos problemas com backups são relacionados ao VSS que não consegue gerar os dados necessários para o DPM.

A primeira e mais facil forma de resolver é criar manualmente um ponto de restauração full, o que cria o snapshot novamente no servidor origem do backup, e em geral resolve o problema quando o VSS está com a base corrompida.

A segunda forma de resolver o problema é executar um CHKDSK no disco de origem do backup, pois o VSS grava os dados em um espaço não alocado no disco e o checkdisk faz a verificação de problemas em áreas não alocadas (free space).

A terceira forma de resolver o problema é ir nas propriedades do Shadow Copy do disco (abrir o Explorer como administrador e clicar com o botão direito) e verificar se as propriedades estão corretas. Verifique se o Shadow está ocorrendo nos discos pelo tamanho alocado e entre nas propriedades e verifique se há espaço disponivel. Note que o Shadow Copy não precisa estar Enabled, pois trata-se de outra feature.

A quarta forma de resolver o problema é utilizando a ferramenta VSADMIN e utilizar os comandos de lista dos recursos. Se alguma das listas ocorrer erro o ideal é deletar todos os shadows com os parametros VSSADMIN DELETE. Com esta ação será reinicializado o VSS em todos os discos no próximo backup. Porem é importante que na primeira tentativa ocorra erro, pois os shadow serão reinicializados. Se isso ocorrer espere alguns minutos e tente novamente.

A quinta e ultima forma de resolver os problemas é verificar pelos hotfix e updates disponiveis para o servidor origem dos dados e também do próprio DPM que está no QFE 2 (http://www.microsoft.com/download/en/details.aspx?id=20953).

Problemas Especificos com Proteção do Hyper-V

Uma das grandes vantagens do DPM é fazer backup de maquinas virtuais (VMs) diretamente do serviço de Hyper-V, o que é muito mais rápido ao copiar e restaurar por incluir o VHD inteiro no backup.

Porem, neste caso é necessário tomar várias precauções.

A primeira delas tem a ver com DAS (Direct Attach SCSI), seja em um sotrage ou em discos locais se o DPM estiver no host do Hyper-V, o que eu nunca recomendaria por sinal.

Neste caso, o DPM irá ocupar toda a banda do storage para realizar o backup e o Hyper-V irá derrubar o serviço por entender que o VHD ficou indisponivel. Se você possuir cluster o serviço de cluster irá cair por indicar acesso simultâneo no mesmo disco. Portanto, não utilize o DPM conectado fisicamente na mesma controladora que está o Hyper-V.

Outro problema é o Hyper-V entender que houve acesso simultaneo ao mesmo dado (VHD) e neste caso aplique o KB 2545685 (http://support.microsoft.com/default.aspx?scid=kb;en-US;2545685) que costuma resolver o problema.

Se o seu ambiente Hyper-V for baseado em cluster também pode ser necessário caso o KB acima não resolva executar as tarefas descritas no documento http://technet.microsoft.com/en-us/library/ff634192.aspx que serve para influenciar a forma como os snapshots são gerados quando seu hardware não dá suporte a esta operação.

Por fim, siga os passos do documento http://technet.microsoft.com/en-us/library/ff634205.aspx desabilitando o protocolo chimney ou ativando a auto montagem dos volumes para o VSS.

Conclusão

Sistemas de backup são fáceis de serem implementados, mas exigem alto conhecimento do ambiente para serem gerenciados, já que a dependencia de recursos locais como o VSS e CSV no caso do Hyper-V em cluster não são tão simples de serem controlados.

Porem, com as dicas acima consegui resolver os problemas que tive em diversos clientes com sucesso!!!

Ao trocar o meu HD externo pelo que já possuía no note, tive o seguinte problema: “Invalid disk” tanto no Server Management quando no DiskPart.

O disco em questão era o de boot no meu antigo notebook que estava formatado como Dynamic e com 3 partições (System, SO e Dados).

Encontrei no Fórum TechNet referencia ao mesmo problema, mas não se aplicavam ou não adiantavam no meu caso e foi quando comentaram da ferramenta HxD (http://cnet.co/qe5H4H), que eu já havia utilizado mas para editar arquivos e não para editar setores de disco.

Então ai está a solução, usando o HxD edite o disco e altere o hexa 42 (dinâmico) para 07 (básico) e o disco passa a ser enxergado com todas as partições, mas com o sintoma de aparecem algumas partições “fantasmas”.

Na figura 1 veja a abertura do disco pelo menu “Extras –> Open Disk”

Na figura 2 encontramos a definição dos tipos de partição, que iniciam na posição 0000001C0 em diante e note o terceiro octeto com o DWORD 42 e altere para 07.

Na figura 3 veja que o disco foi visto como básico, as partições voltaram, inclusive a de 200MB utilizado como System e uma “fantasma” com a letra H que não tinha dono e que segundo referencias era a partição de controle do disco dinâmico.

Assim, após realocar os 200 MB para o disco G:, apagar o disco H: e reformatar a partição 1 que era boot fiquei com o meu disco recuperado e estou utilizando normalmente como uma única partição sem ter perdido dados que estavam na partição 2:

Importante: Não utilize este recurso em dados sem levar em conta o risco de perder partições, principalmente levando em conta que certos recursos não são suportados (Extend, Expand, RAIDs) em discos básicos. Este recurso é interessante e essencial caso deseje recuperar dados de discos que estejam nas especificações dos discos básicos, ou seja, até 4 partições sem recursos de RAID.