Um dos meus clientes tem um Windows Server 2016 e usa wbadmin para fazer algum backup de recuperação bare-metal para algum Synology NAS usando SMB. Isso funcionou no passado, onde "passado" é algumas semanas / meses não especificados no passado por várias razões, e não funciona mais. É bem provável que "alguma coisa" tenha mudado por causa das atualizações do NAS, pacotes adicionais instalados e qualquer outra coisa, mas é claro que ninguém sabe mais e não fui eu. ; -)
Após alguns testes e logs com diferentes versões SMB, Wireshark, Process Monitor, etc., o problema parece ser que, por alguma razão, wbadmin é capaz de criar os arquivos VHDX brutos necessários para os volumes para backup no compartilhamento NAS, mas parece ser incapaz de inicializar esses discos e publicar o sistema de arquivos necessário para eles. O processo de backup sempre aborta bem cedo após a criação de um arquivo VHDX com um tamanho fixo, seja de, e. 4 MB para Esp.vhdx ou 6 MB para o VHDX contendo C: . Isso simplesmente depende das configurações de backup, como -allCritical vs. somente -include:C: .
Sempre que esse problema ocorre, há a seguinte mensagem de erro no visualizador de eventos:
Log Name: System
Source: Virtual Disk Service
Date:[...]
Event ID: 9
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer:[...]
Description:
Unexpected provider failure. Restarting the service may fix the problem. Error code: 80070037@02000014
Eu não vejo nenhuma outra mensagem de erro relevante no Wireshark dentro da comunicação SMB, os logs do Samba no NAS ou no Process Monitor, mas especialmente para o último, eu não tenho certeza, porque o Windows faz muitas coisas automaticamente no fundo que estão perfeitamente bem para falhar. O NAS fornece alguns protocolos Samba que também são um pouco estranhos, porque registra muita comunicação SMB para um usuário que não está configurado para ser usado por wbadmin . Mas como todos os usuários testados têm as mesmas / todas as permissões nesse destino de backup, não acho que isso seja parte do problema e testei com usuários diferentes também.
O interessante é que eu posso anexar os arquivos VHDX criados automaticamente por wbadmin manualmente com sucesso, pode inicializá-los, adicionar algum sistema de arquivos e depois, por exemplo. o backup de apenas -include:C: é bem-sucedido sem problemas. -allCritical continua falhando porque Esp.vhdx parece ser excluído e recriado toda vez, apresentando o mesmo erro novamente como antes.
Outra coisa interessante é que o uso de algum dispositivo iSCSI hospedado pelo mesmo NAS como destino de backup, mesmo -allCritical , é bem-sucedido cada vez que é testado. Todos os arquivos VHDX são criados, inicializados e formatados automaticamente, sem intervenção manual. Portanto, não parece ser o Windows / wbadmin ou relacionado à rede em si.
Portanto, estou assumindo que há algum problema com relação ao Samba, mas eu já tentei com a versão mais baixa do SMB1 que o NAS é capaz, tentei coisas como
strict allocate = yes pessoas estão sugerindo, embora tenha deixado claro que o NAS não está criando arquivos esparsos de qualquer maneira e eu posso anexar, inicializar e publicar os arquivos VHDX criados por
wbadmin manualmente. O que não deveria ser possível no caso de arquivos esparsos do que eu li.
A única coisa que resta por enquanto é o código de erro do Virtual Disk Service, sobre o qual não encontro muita coisa. A parte 0x37 pode ser ERROR_DEV_NOT_EXIST e isso pode fazer sentido, mas qual é a @ -part? Onde posso encontrar o que significa toda a sintaxe desse erro? A @ -part é alguma linha de código ou algum detalhe adicional ou algo completamente diferente? Espero que isso me dê pistas adicionais sobre o problema subjacente real, porque não entendo porque as coisas falham em wbadmin em si, o que posso fazer manualmente.
Obrigado!