Ir para o conteúdo principal
Veeam

Bare Metal Recovery com Veeam Agent for Windows: restaurando um servidor perdido em uma VM nova

Procedimento completo de recuperação de um Windows Server a partir de backup em share SMB, usando a Veeam Recovery Media — com as armadilhas que aparecem no caminho real.

E Equipe Callister

O cenário é sempre parecido: um servidor sai do ar de forma definitiva — hardware, corrupção, ransomware ou simplesmente uma VM que se perdeu — e o único ativo que sobrou é o backup. Quando esse backup foi feito pelo Veeam Agent for Microsoft Windows, a recuperação não acontece pelo console de gerenciamento: ela acontece a partir de uma mídia bootável, chamada Veeam Recovery Media, executada em uma máquina vazia.

Este procedimento cobre o caminho completo, do zero até o servidor novamente em produção, com foco no cenário mais comum em ambientes gerenciados: backup armazenado em um share SMB (NAS local) e destino em uma VM VMware.

Antes de começar: o que este procedimento não é

Vale delimitar o escopo, porque a escolha errada de ferramenta custa horas.

  • Não é restore pelo console de gerenciamento. O Veeam Service Provider Console faz apenas file-level restore (arquivos e pastas) de máquinas com agente. Máquina inteira não sai por ali.
  • Não serve para backup de imagem feito pelo VBR. Se a VM era protegida pelo Veeam Backup & Replication no nível do hipervisor, o caminho correto é o Instant VM Recovery no console do VBR — muito mais rápido, com a VM ligando em minutos.
  • Não serve a mídia do agente Linux. A ISO pública do repositório da Veeam é do Veeam Agent for Linux e não restaura backups de máquinas Windows. É um erro fácil de cometer, porque a ISO Linux está disponível para download imediato e a de Windows precisa ser gerada. O sintoma é claro: se o boot abre um menu de texto cinza com as opções Restore volumes, Restore files, Configure network e Exit to shell, você está na mídia errada — ela monta o share normalmente e não encontra nenhum backup de máquina Windows.

Menu de texto da recovery media do Veeam Agent for Linux, com as opções Restore volumes, Restore files, Configure network, Exit to shell, Reboot e Shutdown

Este procedimento é para: backup feito pelo Veeam Agent for Microsoft Windows, restaurado em uma máquina nova.

Pré-requisitos

ItemDetalhe
Versão do agenteA recovery media precisa ser da mesma versão ou mais nova que o agente que criou o backup
Acesso ao repositórioCredencial de leitura do share SMB (ou credencial de tenant, se Cloud Connect)
Cadeia de backup íntegraArquivo .vbm + .vbk + todos os .vib da cadeia até o ponto desejado
Espaço no destinoDisco igual ou maior que o original, e o mesmo número de discos
Senha de criptografiaSe o job era criptografado, sem ela não há restore — confirme antes de prometer prazo

Etapa 1 — Levantar as informações do backup

  1. No console de gerenciamento, localize a máquina e anote a versão do Veeam Agent instalada.
  2. Verifique se o job usava criptografia. Se sim, obtenha a senha antes de qualquer outra coisa.
  3. Abra o repositório e confirme a integridade da cadeia. Você deve ver o .vbm com os metadados, um .vbk (full) e um .vib para cada incremental até a data desejada. Todos os arquivos precisam estar presentes.
  4. Anote o tamanho total dos arquivos que serão lidos. É esse número — não o tamanho do servidor — que determina a janela de restore.
  5. Desabilite o job dessa máquina. Um merge de cadeia rodando durante a leitura quebra o restore.

Listagem de arquivos do repositório mostrando um arquivo .vbm, um arquivo .vbk e oito arquivos .vib com datas e tamanhos

Dica de estimativa: para chegar ao ponto mais recente, o wizard lê o full inteiro mais todos os incrementais posteriores. Um servidor de 350 GB com full de 78 GB e oito incrementais de ~5 GB significa ler ~120 GB, não 350 GB.

Etapa 2 — Gerar a Veeam Recovery Media

Não existe ISO genérica para Windows: ela é gerada por uma instalação do agente.

  1. Em qualquer Windows x64 — pode ser uma VM descartável — instale o Veeam Agent for Microsoft Windows na versão identificada na Etapa 1.
  2. Menu Iniciar → Create Recovery Media.
  3. Selecione ISO image file e o caminho de destino.
  4. Mantenha a inclusão dos drivers de hardware do computador local. Se o destino exigir drivers específicos (VirtIO em Proxmox, por exemplo), adicione-os na etapa de drivers customizados.
  5. Não é necessário embutir configuração de rede nem localização do backup — tudo isso é informado no boot.

A geração leva poucos minutos. A ISO final tem entre 700 MB e 1,5 GB e não contém dados de backup: é apenas o ambiente de recuperação. A mesma ISO serve para restaurar qualquer máquina do mesmo ambiente, o que a torna um bom item de acervo — gere uma, guarde, e atualize a cada upgrade de versão do agente.

Sobre licença: para restaurar de share SMB, a edição Free é suficiente. Para restaurar de repositório Cloud Connect, a opção correspondente só aparece com licença aplicada — nesse caso, licencie a instalação antes de gerar a mídia.

Etapa 3 — Preparar a VM de destino

Esta etapa concentra a maior parte das falhas. O ambiente de recuperação roda sobre WinPE, que tem um conjunto reduzido de drivers.

Configure a VM assim:

  • Firmware idêntico ao original — BIOS ou UEFI. Restaurar um sistema UEFI em uma VM BIOS conclui sem erro e depois não dá boot. É a falha mais comum e a mais frustrante, porque só aparece no final.
  • Secure Boot desabilitado.
  • Controladora SCSI: LSI Logic SAS. O driver PVSCSI não existe no WinPE — com Paravirtual, o wizard sobe e não enxerga disco nenhum. Troque em Change Type, nas propriedades da VM, antes de ligá-la.
  • Placa de rede: E1000E. Mesmo motivo: VMXNET3 não é reconhecido pelo ambiente de recuperação.
  • Disco igual ou maior que o original, e o mesmo número de discos do servidor de origem.
  • ISO montada no drive de CD/DVD, com boot pela mídia.

Janela de propriedades da máquina virtual no vSphere com a controladora SCSI selecionada, mostrando o tipo Paravirtual e o botão Change Type

Se a máquina original já era uma VM VMware, o sistema restaurado trará VMware Tools e os drivers PVSCSI/VMXNET3 instalados. LSI Logic SAS e E1000E são necessários apenas para o WinPE — depois do restore você pode reverter para as controladoras de alta performance.

Etapa 4 — Boot e configuração de rede

Dê boot pela ISO. A recovery media abre em um menu com Bare Metal Recovery, Tools e opções de diagnóstico.

O menu Tools desta mídia não tem item de rede — ele traz apenas Command Prompt, Memory Diagnostic, Reset Password, Startup Repair, Load Driver e Export Logs. A configuração de rede é feita pelo prompt de comando ou dentro do próprio wizard de restore.

Menu Tools da recovery media com os ícones Command Prompt, Memory Diagnostic, Reset Password, Startup Repair, Load Driver e Export Logs

Abra Tools → Command Prompt e execute:

ipconfig /all
  • Se nenhum adaptador aparecer, é driver. Volte, troque a NIC para E1000E ou use Tools → Load Driver.
  • Se aparecer com endereço 169.254.x.x, há link mas o DHCP não respondeu.

Configure IP estático:

wpeinit
netsh interface ipv4 show interfaces
netsh interface ipv4 set address name="Ethernet0" static 192.168.0.50 255.255.255.0 192.168.0.1

Use o nome exato do adaptador retornado pelo comando anterior — costuma ser Ethernet0, mas varia. Se o repositório está na mesma sub-rede, o gateway é opcional.

Valide antes de entrar no wizard. Dois minutos aqui economizam meia hora depois:

ping 192.168.0.10
net use Z: \\192.168.0.10\NOME-DO-SHARE /user:usuario

Interpretação dos erros:

ErroCausa provável
Erro 5 / 1326Usuário ou senha incorretos — tente servidor\usuario
Erro 53 / 67Nome do share errado, ou rede sem alcance
Erro 1219Já existe sessão aberta com outra credencial — net use * /delete
Ping sem respostaVLAN ou port group errado, ou NIC desconectada

Confira a grafia exata do share. Uma letra trocada no nome gera exatamente o mesmo erro de “share não encontrado” que um problema de VLAN, e leva muito mais tempo para ser percebida.

Feche o prompt e volte ao menu — o wizard herda a configuração de rede aplicada.

Etapa 5 — Executar o restore

  1. No menu principal, escolha Bare Metal Recovery.
  2. Backup LocationNetwork storageShared folder.
  3. Informe o caminho UNC completo (\\servidor\share) e as credenciais. Deixe o domínio em branco para contas locais do NAS.
  4. Navegue até a pasta do job e selecione o arquivo .vbm — não o .vbk. O .vbm traz os metadados da cadeia inteira e permite escolher qualquer restore point, inclusive um anterior, em caso de suspeita de ransomware; abrindo o .vbk diretamente você fica preso ao full.
  5. Selecione a máquina e o restore point pela data.
  6. Em Restore Mode, escolha Entire computer.
  7. Abra View automatically detected disk mapping e confira o mapeamento. Em hardware diferente do original, o mapeamento automático erra com frequência — ajuste manualmente em Customize disk mapping se necessário.
  8. Revise o Summary e confirme.

Acompanhe o log de progresso. Ele lista cada volume restaurado com a taxa de transferência.

Atenção aos volumes: se o servidor original tinha mais de um volume de dados, confirme que todos aparecem na fila. Um restore que lista apenas “Reservado pelo Sistema” e “C:” deixou os demais para trás — nesse caso, execute um Volume Level Restore adicional apontando para o mesmo restore point. O log desse assistente é idêntico ao do Bare Metal Recovery:

Log de progresso do assistente Volume Level Restore, listando os volumes Reservado pelo Sistema e C: com as respectivas taxas de transferência e durações

Como referência de tempo: em rede gigabit, taxas entre 20 e 60 MB/s são normais. A oscilação vem da I/O aleatória no NAS ao consolidar a cadeia de incrementais, não de erro no processo. Não interrompa por lentidão — recomeçar custa mais que a diferença.

Etapa 6 — Pós-restore

Concluído o restore, na ordem:

  1. Desmonte a ISO antes de reiniciar, senão a VM volta na recovery media.
  2. Primeiro boot com a configuração de restore (LSI Logic SAS + E1000E). Confirme que o sistema sobe até a tela de logon.
  3. Desligue, reverta a controladora para Paravirtual e a NIC para VMXNET3, e boote novamente. Fazer isso em duas etapas isola a causa se algo falhar.
  4. Instale ou atualize o VMware Tools.
  5. Reconfigure a rede. O endereço MAC mudou, então o Windows cria um adaptador novo e o IP fixo antigo permanece preso a um adaptador fantasma. Para limpar:
set devmgr_show_nonpresent_devices=1
devmgmt.msc

Em Exibir → Mostrar dispositivos ocultos, remova a placa antiga em Adaptadores de rede.

  1. Verifique data e hora. Servidor com relógio dessincronizado derruba autenticação de todo o ambiente.
  2. Valide os serviços de aplicação antes de liberar aos usuários — banco de dados, compartilhamentos, serviços customizados.
  3. Reinstale ou reconecte o agente Veeam e reabilite o job.
  4. Execute um backup full novo. Não deixe a cadeia antiga continuar sobre uma máquina restaurada.

Tabela de diagnóstico rápido

SintomaCausaSolução
Wizard não enxerga disco algumControladora PVSCSITrocar para LSI Logic SAS
Nenhum adaptador em ipconfigNIC VMXNET3Trocar para E1000E ou carregar driver
Restore conclui e a VM não dá bootFirmware divergenteRecriar a VM com BIOS/UEFI igual ao original
Share monta mas não lista backupsMídia do agente LinuxGerar ISO do agente Windows
Wizard pede senha desconhecidaJob com criptografiaRecuperar a senha; sem ela não há restore
Restore falha no meioMerge de cadeia concorrenteDesabilitar o job antes de iniciar
Só C: foi restauradoVolumes adicionais não selecionadosVolume Level Restore complementar

Variante: restore a partir de repositório Cloud Connect

Se o backup está em um repositório de service provider em vez de share local, muda apenas a Etapa 5:

  • Em Backup Location, escolha Veeam Cloud Connect repository.
  • Informe o endereço do gateway do provedor e a porta 6180.
  • A tela de obtenção do certificado pode demorar vários minutos — não é travamento.
  • Autentique com usuário e senha do tenant, sem prefixo de empresa. A credencial de tenant enxerga também os backups dos subtenants.

Dois pontos de atenção nesse cenário: a licença precisa estar aplicada na instalação que gerou a mídia, e o volume de dados atravessa a WAN — se o repositório do provedor está sobre object storage em nuvem pública, há custo de retrieval e egress proporcional ao tamanho lido.

Fechando: o custo de escolher errado a proteção

Este procedimento leva de uma a duas horas quando tudo corre bem, e uma tarde inteira quando alguma premissa está errada. É o preço de recuperar uma máquina inteira a partir de backup de agente.

Vale a pergunta de pós-mortem: se a máquina perdida era uma VM em um hipervisor, ela deveria estar protegida por backup de imagem, não por agente. Com backup no nível do hipervisor, o mesmo incidente se resolve com um Instant VM Recovery — a VM sobe em minutos, com os dados migrando em segundo plano, sem ISO, sem WinPE e sem preparação de VM.

Backup de agente tem seu lugar: servidores físicos, workstations, cargas em nuvem sem acesso ao hipervisor. Para VMs, é plano B. O melhor momento para revisar essa escolha é justamente depois de um restore bem-sucedido — quando ainda está fresco quanto tempo ele custou.

Precisa de um backup que você tenha certeza de que restaura? Conheça nosso serviço de backup gerenciado ou entre em contato.

#Veeam #Backup #Bare Metal Recovery #Disaster Recovery #VMware #Windows Server

Precisa de ajuda com segurança de redes?

Fale com um especialista certificado SonicWall e Fortinet.

Falar com Especialista