Isenção de responsabilidade: A nota é divertida. A densidade específica de informações úteis é pequena. Foi escrito "para você".
Introdução lírica
O despejo de arquivos em nossa organização está girando em uma máquina virtual VMware ESXi 6 no Windows Server 2016. E isso não é apenas um despejo. Este é um servidor de compartilhamento de arquivos entre divisões estruturais: existe colaboração, documentação do projeto e pastas dos scanners de rede. Em geral, esta é toda a vida útil da produção.
E esse recipiente de toda a vida útil da produção começou a pendurar. Além disso, o hóspede poderia se enforcar silenciosamente, sem afetar o resto. Pode travar após si próprio o host inteiro e, consequentemente, todas as outras máquinas convidadas. Eu poderia me desligar e desligar os serviços do cliente vSphere: ou seja, os processos dos outros convidados estão ativos, as máquinas estão funcionando corretamente e estão respondendo, mas não há corrupção de arquivos e o vSphere Client não se apega ao host. Em geral, nenhum sistema pode ser identificado. Travas podem ocorrer durante o dia durante uma carga fraca. Poderia à noite durante carga zero. Poderia durante a noite durante backup diferencial e carga média. Poderia no fim de semana durante um backup completo e alta carga. E houve uma clara degradação da situação. No início, era uma vez por ano, depois a cada seis meses. No final da minha paciência, duas vezes por semana.
Pequei pela RAM. Mas eles não me deixaram parar o lixo nem nos fins de semana e afastar o Memtest. Esperou as férias de maio. Nos feriados de maio, saí do Memtest e ... nenhum erro foi encontrado.
Fiquei espantado e decidi sair de férias. Enquanto eu estava de férias - o depósito de lixo não tinha um único jeito. E quando na segunda-feira o primeiro dia foi trabalhar - a lata de lixo estava pendurada. Sustentou um backup completo e, no final, ele travou. Uma reunião tão calorosa das férias levou-me à decisão de arrastar fisicamente a unidade de convidados para outro host.
E, embora se saiba há muito tempo que, no primeiro dia após as férias, nada sério pode ser feito, embora eu me preparei para o trabalho todo o caminho para o trabalho, minha indignação com o próximo congelamento derrubou minha mente, meu humor e votos ...
Os discos físicos foram reorganizados para outro host. Conexão quente. Os discos aparecem nas configurações de armazenamento na guia
Unidades . Na guia
Datastores, o armazenamento nessas unidades não é.
Atualizar - não aparece. Bem, é claro, o primeiro impulso é
Adicionar armazenamento . O Assistente para adicionar informa o que ele suporta. Claro que também suporta VMFS. Eu não tinha dúvida. Uma rápida olhada nas mensagens do assistente em cada etapa: Avançar, Avançar, Avançar, Concluir. Seu olhar nem chegou perto de pegar um pequeno círculo amarelo com um ponto de exclamação na parte inferior da janela de uma das etapas do mestre.
No final do assistente, um Datastore novo apareceu na lista ... e com ele Datastores de outros discos físicos.
Estou migrando para a navegação no armazenamento de dados recém-adicionado e ele está vazio. Claro, fiquei novamente espantado. Às 8 horas da manhã, nos primeiros 15 minutos de trabalho após as férias, o açúcar do café ainda não foi mexido. E aqui está. Meu primeiro pensamento foi que eu peguei a unidade errada do host "nativo". Procurei se o armazenamento de dados necessário está presente no host "nativo": não, não está presente. O segundo pensamento foi: "merda # b!". Não tenho certeza, mas me parece que o terceiro, quarto e pelo menos quinto pensamento eram os mesmos.
Para dissipar dúvidas, instalei rapidamente um ESXi novo na amostra, peguei a unidade esquerda e, depois de ler, passei pelas etapas do assistente. Sim Ao adicionar um armazenamento de dados usando o assistente, todos os dados no disco são perdidos sem a capacidade de reverter a operação e restaurar os dados. Mais tarde, li em um dos fóruns uma avaliação desse design pelo mestre: porcaria de merda. E agora eu realmente concordei.
Começando com o sexto, os pensamentos fluíram de uma maneira mais construtiva. Ok. A inicialização leva uma questão de segundos, mesmo para uma unidade de 3 TB. Portanto, essa é a formatação de alto nível. Portanto, a tabela de partição foi simplesmente reescrita. Portanto, os dados ainda estão lá. Então agora vamos procurar algum formato e pronto.
Carrego o carro a partir da imagem de inicialização do Strelec ... E descubro que os programas de recuperação de partição são conhecidos por todos, exceto o VMFS. Por exemplo, eles conhecem o layout da partição do Synology, mas o VMFS não.
A enumeração de programas não é reconfortante: na melhor das hipóteses, GetDataBack e R.Saver encontram partições NTFS com estruturas de diretório ativo e nomes de arquivos ativos. Mas isso não combina comigo. Eu preciso de dois arquivos vmdk: com um disco do sistema e uma lixeira.
E entendo que, ao que parece, agora instalarei o Windows e implementarei o backup do arquivo. E, ao mesmo tempo, lembro que tinha uma raiz DFS lá. E também um sistema completamente selvagem de volume e ramificação de direitos de acesso às pastas de unidades. Não é uma opção. A única opção aceitável no tempo é restaurar o estado do sistema e do disco com dados e todos os direitos.
Mais uma vez pesquisando, fóruns, KB'shki e novamente chorando Yaroslavna: VMware ESXi não fornece um mecanismo de recuperação de dados. Todos os tópicos de discussão têm duas finais: alguém se recuperou com a ajuda do DiskInternals VMFS Recovery, que não é barato, ou alguém que estava promovendo ativamente seus serviços com a
ajuda do
vmfs-tools e do
dd ajudou. A opção de comprar uma licença do DiskInternals VMFS Recovery por US $ 700 não é uma opção. A admissão de um estranho do “território de um potencial adversário” aos dados corporativos também não é uma opção. Mas foi pesquisado que as partições VMFS também podem ler o UFS Explorer.
Recuperação de DiskInternals VMFS
A versão de avaliação foi baixada e instalada. O programa viu com êxito uma seção vazia do VMFS:
No modo
Undelete (Fast Scan) , também encontrei um Datastore gasto com pastas de máquinas virtuais com discos dentro:
A visualização mostrou que os arquivos estão ativos:
A montagem da partição no sistema foi bem-sucedida, mas, por algum motivo, todas as três pastas tinham a mesma máquina virtual. Obviamente, a lei da maldade não é o que é necessário.
Três linhas de vergonhaUma tentativa de bloquear descaradamente o software terminou em falha. Mas o UFS Explorer estava bloqueado.
Sou extremamente negativo em relação ao roubo de software. Em nenhum caso, exorto o uso de contornar a proteção contra o uso não licenciado.
Eu estava em uma situação catastrófica e não estava nem um pouco orgulhoso das medidas que havia adotado.
UFS Explorer
A varredura do disco mostrou a presença de 7 nós. O número de nós de uma “maneira incrível” coincidiu com o número de arquivos * -flat.vmdk detectados pelo VMFS Recovery:
A comparação de tamanhos de arquivo e de nó também mostrou uma correspondência de até byte. Ao mesmo tempo, os nomes dos arquivos * -flat.vmdk e, portanto, seus pertences às máquinas virtuais foram restaurados.
Em geral, do ponto de vista do ESXi, os discos vmdk consistem em dois arquivos: um arquivo de dados (<nome da máquina> -flat.vmdk) e um arquivo de particionamento físico (<nome da máquina> .vmdk). Se você enviar o arquivo * -flat.vmdk da máquina local para o Datastore, o ESXi não o reconhecerá como um arquivo de disco válido. Há um artigo na base de conhecimento da VMware sobre como criar manualmente um arquivo de descritor de disco:
kb.vmware.com/s/article/1002511 , mas não precisava, apenas copiei o conteúdo dos arquivos correspondentes da área de visualização de conteúdo do arquivo no DiskInternals VMFS Recovery :
Após 4 horas de descarregamento de um nó de 2,5 TB do UFS Explorer e 20 horas de carregamento no hypervisor do Datastore, os arquivos de disco com falha foram conectados a uma máquina virtual recém-criada. Rodas levantadas. Nenhuma perda de dados foi notada.
