Backup e Disaster Recovery para a virtualização de servidores

À medida que a tecnologia de virtualização de servidores evolui e sua adopção no sector aumenta, as organizações percebem benefícios que vão muito além da justificativa mais popular para a virtualização: reduzir os custos de infra-estrutura e aumentar a agilidade de TI. O próximo passo é usar a plataforma de virtualização como uma forma de habilitar ou aprimorar as estratégias de DR (Disaster Recovery – recuperação de desastre).

Por que a prontidão da DR é, de forma generalizada, um dos assuntos mais efervescentes no sector de TI? Estudos sugerem que as empresas perdem, em média, de US$ 80.000 a 90.000 por hora de inactividade, e que poucas empresas a sofrer uma perda de dados catastrófica alcançam uma sobrevida de longo prazo. Este post apresenta uma introdução à DR usando a plataforma de virtualização da Microsoft, uma análise detalhada das opções de backup e restauração existentes e algumas considerações sobre o Windows Server 2008 Hyper-V.

Noções básicas de planeamento da recuperação de desastre
A DR é o processo de restaurar serviços essenciais no caso de uma interrupção, e deve fazer parte do plano de continuidade de todas as empresas. Esse plano define como a empresa continuará a funcionar durante ou após um desastre, e constitui o fundamento de qualquer iniciativa de DR.

Alguns fornecedores afirmam que suas tecnologias de automatização de DR minimizam ou eliminam a necessidade de um plano detalhado e bem testado. Embora seja válido afirmar que a automatização pode reduzir o tempo de recuperação e diminuir a dependência da intervenção humana, vamos fazer uma pausa para um anúncio de utilidade pública: é impossível ter êxito na tentativa de atenuar um desastre contando somente com a tecnologia. As pessoas e os processos são sempre tão importantes quanto as tecnologias.

Na verdade, descobrirá que é praticamente impossível seleccionar as tecnologias certas, sem primeiro conhecer todas as restrições e os objectivos gerados pelo processo de planeamento de DR. Não vamos definir um plano completo de DR. Vamos, sim, enfatizar os elementos necessários para a escolha das tecnologias e implementações certas. Sendo assim, vamos descrever rapidamente alguns factores tecnológicos essenciais em um plano de DR.

Definições e priorização de serviços O que exatamente define todo o serviço que está tentando proteger e qual a sua importância para a organização? A Figura 1 mostra alguns exemplos de serviços de empresas que provavelmente seriam incluídos em qualquer plano de DR.


Figura 1 Exemplo de definições e priorização de serviços

Depois de definir os serviços, podemos começar a identificar os sistemas e as dependências a serem vinculados a que tipos de estratégias de DR. Talvez, depois de observar o conjunto completo de serviços e dependências, descubra que precisa adoptar alguns níveis diferentes de capacidade de DR, pois uma única solução de DR para todos os serviços essenciais seria muito cara e complexa.

SLAs (contratos de nível de serviço) Um SLA é um acordo ou contrato entre o provedor de serviço (TI) e o cliente (organização) que define as metas de disponibilidade para determinado serviço. Esses contratos podem ser extensos ou bastante directos. Por exemplo, “O sistema de email estará disponível 99,95% do tempo no horário comercial e 98% do tempo fora do horário comercial, excluindo-se as janelas de manutenção agendadas, com medição mensal.” Em geral, os SLAs são divididos em camadas às quais podem ser atribuídos serviços de TI, com medição em um período predefinido.

OLAs (contratos de nível de operação) Os OLAs descrevem, basicamente, os contratos entre diferentes grupos de TI que actuam no suporte a um SLA, inclusive os tempos de processamento e resposta para o fornecimento dos serviços. Suponha que tem um site essencial com uma meta de SLA de 99,99%, mas um banco de dados do qual ele depende para obter conteúdo tem uma meta de disponibilidade de apenas 95%. O OLA ajuda a solucionar essas divergências e a alinhar as equipes de TI no sentido de uma meta comum.

RPOs/RTOs (objectivos de ponto de recuperação e tempo de recuperação) Um RTO define por quanto tempo um serviço pode ficar indisponível até que haja uma quebra de continuidade; já um RPO define o que a organização considera um nível aceitável de perda de dados. Então, se um serviço tem um SLA de 99%, com medição mensal, isso significa que o RTO é de 7 horas e 18 minutos. Se combinar isso com um RPO de, digamos, 24 horas, poderá definir técnicas e agendamentos de backup com precisão.

Politicas de retenção de dados As politicas de retenção de dados de uma organização especificam exactamente por quanto tempo é preciso manter os backups e onde devem ser armazenados. Em geral, elas são governadas por requisitos legais e normativos.

Categorização de dados Também se deve levar em conta a natureza dos dados. Se dividirmos os dados em categorias, vamos perceber rapidamente que nem todos exigem a aplicação do mesmo nível de DR. Por exemplo, um banco de dados único pode ter requisitos de disponibilidade diferentes daqueles encontrados em um Active Directory com vários controladores de domínio, cada um contendo uma réplica do directório. Da mesma forma, os dados de um servidor de arquivos têm procedimentos de restauração diferentes dos aplicáveis a dados de CRM.

Cenários de desastre É importante definir todos os cenários para os quais se deseja fazer um planeamento, pois cada um terá procedimentos de restauração, efeitos sobre os negócios e custos associados distintos. É útil observar todos os cenários possíveis e depois decidir em quais se deseja concentrar ao trabalhar no planeamento de DR para o seu ambiente:

  • Perda de todo o local
    ·         Perda de um único data center
    ·         Perda de um sistema (sistema operacional ou falha de hardware)
    ·         Perda de dados (exclusão ou corrupção de dados)
    ·         Perda de uma dependência essencial

Logicamente, há vários aspectos diferentes a serem considerados na recuperação da perda do local inteiro, em oposição à perda de um único sistema. É provável que queira também definir limites de recuperação com base nos SLAs. Digamos, por exemplo, que todo o local está offline devido a uma grave interrupção na rede ISP. Se o SLA do serviço afectado for de 8 horas para a restauração do serviço e 48 horas para a restauração dos dados, talvez realize procedimentos de failover do serviço para o seu local de backup, mas não chegue a executar o processo de recuperação de dados, por prever um failback rápido para o local de produção.

Todo esse trabalho e ainda nem falamos de tecnologia! Não se deve subestimar a importância do planeamento. Uma implementação de DR sem um plano documentado é apenas uma “esperança de DR”.

Recuperação de desastre e virtualização

Bem, agora que já estabelecemos as bases do planeamento de DR, o que muda com a virtualização? Muitas empresas relatam tempos de restauração de serviços de minutos com servidores virtualizados, em comparação com os dias ou as semanas necessárias no caso de servidores físicos. Como todo o sistema operacional do servidor passa a ser constituído apenas por um conjunto de arquivos, abstraído do hardware físico subjacente, surgem novas perspectivas, sob o ponto de vista da capacidade de recuperação.

A teoria predominante na actualidade é que algumas ou todas as metas de DR podem ser alcançadas com soluções de HA (alta disponibilidade). A ideia por trás disso é que, se tiver nós de cluster em locais físicos separados, com dados sincronizados entre os locais, o nó passivo poderá retomar as operações em caso de falha, e poderá recuperar-se praticamente em tempo real.

Isso é verdade. No entanto, convém lembrar os cenários de desastre definidos anteriormente, fica claro que essa não é a solução para todos eles. É preciso ter uma combinação de tecnologias que permita preparar-se para todos os cenários, e isso geralmente inclui algum tipo de backup regular. A HA não protege contra todas as interrupções possíveis e não elimina totalmente a necessidade de algum tipo de estratégia de backup.

A HA com Hyper-V exige um planeamento cuidadoso da camada de armazenamento, pois esse é um factor fundamental para possibilitar a capacidade de recuperação. Por exemplo, um cluster Hyper-V de 2 nós com armazenamento partilhado ainda tem o subsistema e os dados de armazenamento como ponto único de falha, mesmo que os nós do cluster estejam em data centers separados.

Contudo, saiba que o mesmo cluster Hyper-V de 2 nós com armazenamento não partilhado é capaz de resistir à perda de armazenamento ou de dados em qualquer um dos nós. Isso exige tecnologias de replicação para manter o armazenamento em sincronia e também introduz complexidades (veja a Figura 2).

Figura 2 Cluster Hyper-V multissite

Outro recurso é o Windows Server Catalog, que lista fornecedores de armazenamento com tecnologias de replicação certificadas para o Windows Server 2008.

Como se pode ver, há muitas configurações possíveis de HA e armazenamento que precisam ser levadas em consideração. Mais uma vez, é por isso que precisa ter os requisitos de negócios definidos e permitir que eles conduzam os requisitos técnicos, e não o contrário.

Conversão de físico para virtual

Sem dúvida, a virtualização oferece uma agilidade sem precedentes na recuperação. Mas e quanto aos sistemas físicos que não são bons candidatos à virtualização? O SCVMM (System Center Virtual Machine Manager) inclui a capacidade de realizar conversões P2V (de físico para virtual) de servidores Windows em execução, resultando em uma VM (máquina virtual) Hyper-V inicializável que é uma réplica exacta do servidor físico de origem. Agora, é possível replicar essa VM, assim como suas cópias virtualizadas, em várias partes de um campus ou de um país, obtendo tempos de recuperação semelhantes.

Essa abordagem é diferente da restauração tradicional, pois o local de recuperação não precisa mais ter o mesmo número ou tipo de sistemas físicos do local de produção. Então, é possível sobre utilizar o hardware de recuperação e dimensioná-lo conforme a necessidade, dependendo do impacto do desastre.

O SCVMM não inclui um agendador para conversões P2V. Porém, como a GUI é totalmente executada com base no Windows PowerShell, é fácil criar um script para isso usando o cmdlet New-P2V. Na verdade, todos os assistentes do SCVMM mostram o código usado para executar uma tarefa, e pode copiar o código de um P2V de teste no seu ambiente e modificá-lo para futuro uso automatizado. Abaixo mostra um exemplo de código; pode executar o assistente de P2V do SCVMM no seu ambiente para obter um script exclusivo e personalizável do Windows PowerShell.

Exemplo do código produzido pelo assistente de P2V do SCVMM

$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName “<SOURCE P2V SERVER>”
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq “<TARGET HYPER-V HOST>”}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq “<SOURCE P2V SERVER>”}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID “00:14:D1:3C:66:2F”
-PhysicalAddress “00:14:D1:3C:66:2F” -PhysicalAddressType Static -VirtualNetwork “External”
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq “<TARGET HYPER-V HOST>”}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq “<SOURCE P2V SERVER>”}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID “C” -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq “<TARGET HYPER-V HOST>”}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq “<SOURCE P2V SERVER>”}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
“C:\ProgramData\Microsoft\Windows\Hyper-V” -Owner “DOMAIN\username” -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name “<SOURCE P2V SERVER>” -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

Snapshots de máquinas virtuais
Embora não seja tecnicamente um backup, um Snapshots de VM fornece um momento determinado ao qual se pode reverter o sistema, utilizando discos diferenciais e uma cópia do arquivo de configuração da VM. Se o desastre envolver a exclusão acidental de dados dentro da VM, isso poderá ser considerado um recurso de DR, pois a VM poderá ser revertida ao Snapshot, desfazendo os danos.

Fazendo backup do Hyper-V
Backups baseados em host Uma vantagem interessante da virtualização de servidores é a perspectiva de não precisar mais fazer backup individual dos sistemas virtualizados. Agora que esses sistemas são simples arquivos residentes no sistema de arquivos de um host, basta fazer backup dos arquivos e pronto, certo? Não exactamente. Por tratar-se de computadores activos constituídos por dados na memória, dados em disco, configurações de sistema e arquivos abertos, alguns aspectos precisam ser levados em conta. Então, como garantir a consistência dos dados de backup, diante de todas essas partes móveis?

Um aperfeiçoamento significativo na história do backup do Windows Server ocorreu com o Windows Server 2003 e o VSS, que fornece um conjunto padrão de APIs extensíveis usadas pelos gravadores VSS (ganchos em aplicativos e serviços que ajudam a fornecer cópias de sombra consistentes) para criar backups de arquivos e aplicativos abertos. Com a ajuda do serviço VSS, dos provedores e dos gravadores, o aplicativo de backup é capaz de gerar com rapidez a cópia de um momento específico de um volume. O aplicativo reconhece essa cópia e pode processá-la correctamente.

O Hyper-V vem com seu próprio gravador VSS, que permite aos fabricantes de software criar soluções interessantes de backup. O gravador possibilita aos aplicativos de backup obter backups VSS baseados em host de VMs em execução. Se o sistema operativo executado na VM tiver os Componentes de Integração do Hyper-V instalados, além do serviço VSS (disponível no Windows XP SP1 e no Windows Server 2003 e versões posteriores), o backup baseado em host ocorrerá como se fosse executado dentro do guest; o backup será realizado com a VM em execução e os dados serão consistentes (veja a Figura 3).

Figura 3 Backup VSS

No entanto, se o sistema operacional guest não oferecer suporte aos Componentes de Integração ou ao VSS, o processo de backup exigirá que a máquina guest seja colocada em estado salvo e que seja tirado um Snapshot VSS baseado em host dos arquivos de dados da VM, que poderá ser usado para a recuperação pontual. Os Snapshots VSS de estado salvo irão produzir algum tempo de inactividade da VM (em geral, isso se limita a um período de 5 a 10 minutos), com a realização de procedimentos completos de backup em fita a partir da cópia VSS dos dados.

Backups baseados em guest Em um ambiente físico, é preciso fazer backups individuais de servidores e aplicativos. Logicamente, esses backups podem continuar em um data center virtualizado. Nessa situação, deve-se ter em conta as mesmas considerações ao fazer backup de uma VM, como os requisitos de capacidade de rede para backups baseados em rede e o impacto sobre o desempenho do sistema durante a janela de backup. Com os backups baseados em guest, é possível optar por ter uma NIC física dedicada no host associada a uma rede virtual usada por todos os guests.

Backup do Windows Server

O WSB (Backup do Windows Server) compatível com VSS vem incluído no Windows Server 2008 e pode ser usado para realizar backups do Hyper-V baseados em host e em guest das suas VMs. Por ser totalmente compatível com VSS, o WSB pode realizar backups baseados em host das VMs em execução, o que é, logicamente, a opção preferencial.

Mas, se tiver VMs sem os Componentes de Integração instalados, o VSS não será usado. Nesse caso, poderá escolher entre algumas opções. Ainda será possível usar o WSB para fazer backup de uma VM sem os Componentes de Integração instalados. Isso significa que o estado da VM será salvo e, depois, o backup irá capturar os discos virtuais e os arquivos de configuração da VM.

Contudo, é possível que isso não seja desejável para um aplicativo como o Exchange, pois ele não reconhecerá que um backup foi executado, e os logs do aplicativo não serão truncados. Além disso, a VM terá um tempo de inactividade, que irá variar dependendo do tempo necessário para a realização do backup.

Como alternativa, é possível executar um backup dentro da VM como se ela fosse uma máquina física, utilizando o NTBackup ou o WSB, irá depender do sistema operativo da VM. Vejamos como usar o WSB em guests compatíveis que têm os Componentes de Integração instalados.

Fazendo backup de VMs com o WSB

O Hyper-V não regista automaticamente seu gravador VSS para uso com o WSB. Precisa adicionar manualmente a chave e o valor do Registo mostrados abaixo para que o WSB ofereça suporte a um backup do Hyper-V. Também é possível adicioná-los via linha de comando, desta forma:

reg add “HKLM\Software\Microsoft\windows nt\

currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}”

reg add “HKLM\Software\Microsoft\windows nt\
currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}” /v
“Application Identifier” /t REG_SZ /d Hyper-v

Isso não exige reinicialização, pois o WSB procura essa chave/valor no runtime do backup. O seguinte comando mostrará se a entrada foi definida:

reg query “HKLM\Software\Microsoft\windows nt\

currentversion\WindowsServerBackup\Application
Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}” /s

Como instalar o WSB
Clique em Iniciar | Gestão de Servidores. No painel esquerdo, clique em Recursos. Depois, clique em Adicionar Recursos no painel direito. Na página Seleccionar Recursos, expanda Recursos de Backup do Windows Server e marque as caixas de selecção Backup do Windows Server e Ferramentas da Linha de Comando. Agora, siga estas etapas para configurar seu backup:

1.       Vá para Iniciar | Ferramentas Administrativas | Backup do Windows Server.
2.       Se estiver fazendo backup de um host remoto, escolha Conectar a Outro Computador e digite o host Hyper-V.
3.       Escolha Backup Único ou Agendamento de Backup.
4.       Seleccione a configuração do backup — Servidor Completo ou Personalizado. Se você escolher Personalizado, certifique-se de obter todos os volumes contendo dados relacionados à VM da qual está fazendo backup, inclusive dados de configuração, discos virtuais e instantâneos da VM.
5.       Escolha o local para armazenar o backup.
6.       Escolha Backup Completo de VSS ou Backup de Cópia de VSS. Para backups baseados em host sem que nenhum outro backup esteja ocorrendo nas VMs, escolha Backup Completo de VSS.
7.       Depois de confirmar os detalhes, seleccione Backup.

Considerações
·         É preciso fazer backup de todos os volumes relacionados a uma VM. Isso inclui VHDs (discos rígidos virtuais), arquivos de configuração e Snapshots da VM.
·         Se estiver criando um Agendamento de Backup, deverá usar um volume local dedicado, que será formatado e utilizado exclusivamente pelo WSB. Por outro lado, se estiver realizando uma tarefa de Backup Único, poderá armazenar o backup em um volume local não dedicado, em um dispositivo removível ou em uma partilha de rede.
·         Se os Componentes de Integração não estiverem instalados na VM da qual estiver a fazer backup, o WSB salvará o estado da VM em execução para garantir a consistência dos dados de backup.
·         Depois de concluído, o conjunto de backup será portátil e poderá ser usado com qualquer host Hyper-V.

Restaurando VMs com o WSB
Embora o WSB tenha a capacidade de restaurar arquivos individuais, esse recurso não utiliza o VSS e, portanto, pode resultar em uma restauração inconsistente, se a VM estiver em execução no momento do backup. Para fazer restaurações durante a execução das VMs, precisa de restaurar volumes inteiros.

Para fazer isso, é preciso ir para Iniciar | Ferramentas Administrativas | Backup do Windows Server e, no painel Acções, seleccionar Recuperar. Escolha o servidor do qual deseja recuperar dados (aquele onde estão localizados os dados do backup do WSB). Depois, escolha a data a partir da qual deseja restaurar os dados. Agora, pode selecionar o tipo de recuperação.

Neste ponto, é preciso tomar uma decisão. Se precisa da VM inteira, inclusive de sua configuração, snapchots e discos virtuais (por exemplo, no caso de uma falha completa do host), seleccione Restaurar Aplicativo e depois Hyper-V, conforme mostrado na Figura 6. Nesse caso, não tem a opção de restaurar arquivos individuais. Será preciso restaurar tudo o que estiver incluído no conjunto de backup. Observe que isso não substituirá dados de configuração do Hyper-V e da VM existentes que tenham sido alterados desde o backup.

Figura 4 Restaurando um backup do Hyper-V

Se precisar apenas do VHD, e os dados de configuração e os instantâneos da VM estiverem íntegros, poderá seleccionar Arquivos e Pastas e escolher o arquivo de VHD individual de que precisa. Esse processo não utiliza o gravador VSS. Então, é preciso ter isso em conta ao fazer o backup da VM, salvar primeiro o estado.

Se sofreu uma perda total do sistema e dos dados e precisa recuperar o host Hyper-V propriamente dito, incluindo o sistema operativo Windows Server 2008 e todas as VMs executadas nele, faça uma reinicialização para o Ambiente de Recuperação do Windows e realize a restauração a partir dele. É possível fazer isso com o disco de instalação do Windows Server 2008 ou em uma partição de disco pré-configurada.

Data Protection Manager

Após análise das etapas e considerações sobre backup e restauração de hosts e guests Hyper-V usando o WSB, um recurso confiável, gratuito e interno, mas que não é uma solução de protecção de dados de nível empresarial. Quando o WSB sai de cena, entra o DPM (Data Protection Manager) 2007 SP1. O DPM SP1 dá suporte ao Hyper-V e traz alguns recursos interessantes:

  • Um único console de gestão para todos os hosts e guests Hyper-V.
    ·         Protecção contínua de dados, tirando Snapshots baseados em VSS em intervalos de até 15 minutos e capturando somente os bits alterados no processo.
    ·         Reconhecimento de cluster Hyper-V, permite que o backup acompanhe a VM conforme ela se move entre os nós do cluster.
    ·         Replicação de servidor DPM para servidor DPM.
    ·         Suporte para mídia de disco e de fita (de disco para disco, de disco para fita ou de disco para disco e para fita).
    ·         Recursos de backup e restauração em todo o espectro de dados, incluindo hosts e guests Hyper-V; backups VSS sem agente de guests em execução; suporte para restauração de VMs individuais; dados de cluster de failover; e os melhores recursos específicos de aplicativo da categoria para SQL Server, Exchange, SharePoint, Hyper-V e Virtual Server.
    ·         Scripts pré e pós-backup.

Se utiliza actualmente uma solução de backup de terceiros, fique atento às actualizações do aplicativo. A maioria dos fornecedores está a empenhar para lançar (ou já lançou) no mercado soluções baseadas em host Hyper-V.

Backups com scripts
O WSB inclui uma interface de linha de comando, WBadmin.exe, além de um conjunto de cmdlets do Windows PowerShell para uso com scripts. Ao utilizá-los, aplicam-se as mesmas regras de backup descritas anteriormente, além da necessidade de registar manualmente o gravador VSS do Hyper-V no Registo.


A Figura 5 mostra alguns comandos de WBAdmin.

Como vemos, não há nada em WBAdmin para configurar a politica de backup propriamente dita, mas há um snap-in do Windows PowerShell para gerir essas configurações. Pode fazer um teste para verificar se esse snap-in está registado com o seguinte comando:

Get-PSSnapin -Registered

E pode usar o seguinte comando para carregar um snap-in chamado Windows.ServerBackup:

Add-PSSnapin windows.serverBackup

Quando ele estiver carregado, terá acesso aos cmdlets do Windows PowerShell para o WSB, conforme mostrado na Figura 8. Para obter uma descrição detalhada de cada cmdlet, execute este comando:

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

Figura 6 Os cmdlets do Backup do Windows Server

Há outro utilitário interno do Windows Server 2008 que também pode utilizar o gravador VSS do Hyper-V e que acrescenta um pouco de flexibilidade às suas opções de script. O DiskShadow.exe permite que uma cópia de sombra seja realizada e montada como uma unidade, o que possibilita aos administradores fazer um backup mais selectivo do que seria possível usando o WSB. E é importante que se lembre de que o DiskShadow não aceita entrada do pipeline do Windows PowerShell; em vez disso, ele exige que os comandos sejam passados por meio de um script, que pode ter uma aparência como esta:

Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit

Este script primeiro exclui qualquer cópia de sombra existente da unidade C:, depois, garante que a cópia de sombra persistirá após a execução do DiskShadow. Em seguida, cria um bloco transaccional — se qualquer uma das etapas falhar, o processo inteiro falhará. Nesse bloco, o DiskShadow verifica se o gravador para o Hyper-V está carregado e adiciona a unidade C: à lista de unidades das quais será feito backup.

A unidade C: irá obter um GUID para identificá-la, e esse GUID será armazenado em uma variável de ambiente chamada “MyShadow”. Quando esse procedimento for concluído, a cópia de sombra será criada.

O backup é exposto como unidade X: usando a variável de ambiente. É possível fazer muitas coisas com os dados em X:, e depois DiskShadow pode ser executado novamente com o comando Unexpose X: para remover a unidade.

Observe que a restauração de VMs Hyper-V com backup feito via DiskShadow é actualmente um processo manual (a VM precisa ser recriada, os Snapshots não são preservados, e assim por diante). Embora isso tenha algumas desvantagens evidentes, os dados são protegidos.

Fonte: GetVirtual