Virtualização

Backup e recuperação de desastre para a virtualização de servidores

Adam Fazio

 

Visão geral:

• Considerações sobre o planejamento da recuperação de desastre
• Soluções de alta disponibilidade para a recuperação de desastre
• Backup e restauração com o Windows Server Backup

Sumário

Planejamento da recuperação de desastre 101
Recuperação de desastre e virtualização
Conversão de físico para virtual
Instantâneos de máquinas virtuais
Fazendo backup do Hyper-V
Backup do Windows Server
Fazendo backup de VMs com o WSB
Considerações
Restaurando VMs com o WSB
Data Protection Manager
Backups com scripts
DiskShadow
Conclusão

À medida que a tecnologia de virtualização de servidores evolui e sua adoção no setor 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 (recuperação de desastre).

Por que a prontidão da DR é, de forma generalizada, um dos assuntos mais efervescentes no setor de TI? Estudos sugerem que as empresas perdem, em média, de US$ 80.000 a 90.000 por hora de inatividade, e que poucas empresas a sofrer uma perda de dados catastrófica alcançam uma sobrevida de longo prazo. Este artigo 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 planejamento 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 automação de DR minimizam ou eliminam a necessidade de um plano detalhado e bem testado. Embora seja válido afirmar que a automação pode reduzir o tempo de recuperação e diminuir a dependência da intervenção humana, façamos 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, você descobrirá que é praticamente impossível selecionar as tecnologias certas, sem primeiro conhecer todas as restrições e os objetivos gerados pelo processo de planejamento de DR. Está fora do escopo deste artigo definir um plano completo de DR. Pretendo, sim, enfatizar os elementos necessários para a escolha das tecnologias e implementações certas. Então, descreverei rapidamente alguns fatores 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 você está tentando proteger e qual a sua importância para a organização? A Figura 1 mostra 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

Serviço	Componentes principais	Dependências	Uso comercial	SLA
Site público	Balanceador de carga de rede, três servidores Web, dois servidores de banco de dados	DNS, rede, firewall, diretório, armazenamento SAN (rede de área de armazenamento)	Compra de produtos e acompanhamento de pedidos; comércio eletrônico; portal de atendimento ao cliente; informações sobre a empresa	99,99%
Sistema financeiro	Dois servidores de banco de dados, um servidor de aplicativos	DNS, rede	Registro da receita da empresa, conforme exigido por leis e normas	99,99%
Sistema de email	Três servidores de email, um servidor Web	DNS, rede, firewall, diretório	Comunicações da empresa, atendimento ao cliente	99,5%

Depois de definir os serviços, você pode 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, você descubra que precisa adotar 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 diretos. 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 atuam no suporte a um SLA, inclusive os tempos de processamento e resposta para o fornecimento dos serviços. Suponha que você 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 (objetivos 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 você combinar isso com um RPO de, digamos, 24 horas, poderá definir técnicas e agendamentos de backup com precisão.

Diretivas de retenção de dados As diretivas de retenção de dados de uma organização especificam exatamente 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 Você também deve levar em conta a natureza dos dados. Se dividir seus dados em categorias, 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 diretó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 você deseja fazer um planejamento, 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 você deseja se concentrar ao trabalhar no planejamento 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 você queira também definir limites de recuperação com base nos seus 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 afetado for de 8 horas para a restauração do serviço e 48 horas para a restauração dos dados, talvez você 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.

Uau! Todo esse trabalho e ainda nem falamos de tecnologia! Não se deve subestimar a importância do planejamento. 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 planejamento 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 atualidade é que algumas ou todas as metas de DR podem ser alcançadas com soluções de HA (alta disponibilidade). A idéia por trás disso é que, se você 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 você poderá recuperar-se praticamente em tempo real.

Isso é verdade. No entanto, lembrando 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 a você 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 planejamento cuidadoso da camada de armazenamento, pois esse é um fator fundamental para possibilitar a capacidade de recuperação. Por exemplo, um cluster Hyper-V de 2 nós com armazenamento compartilhado 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 compartilhado é 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 (clique na imagem para ampliá-la)

Há alguns desenvolvimentos muito interessantes na área de replicação e sincronização de dados, mas não são recursos fornecidos atualmente pela Microsoft. Vale a pena conhecer os parceiros apresentados na página de clustering multissite do Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx). Outro recurso é o Windows Server Catalog (consulte windowsservercatalog.com), que lista fornecedores de armazenamento com tecnologias de replicação certificadas para o Windows Server 2008.

Como você 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 você precisa ter seus 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 exata 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 bare-metal 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 sobreutilizar 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 você pode copiar o código de um P2V de teste no seu ambiente e modificá-lo para futuro uso automatizado. A Figura 3 mostra um exemplo de código; você pode executar o assistente de P2V do SCVMM no seu ambiente para obter um script exclusivo e personalizável do Windows PowerShell.

Figura 3 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 

Instantâneos de máquinas virtuais

Embora não seja tecnicamente um backup, um instantâneo de VM fornece um momento determinado ao qual você pode reverter o sistema, usando 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 instantâneo, desfazendo os danos (mais tarde, veremos os instantâneos do VSS, Serviço de Cópias de Sombra de Volume).

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 exatamente. Por tratar-se de computadores ativos 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 advento do 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 corretamente.

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 operacional 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 convidado; o backup será realizado com a VM em execução e os dados serão consistentes (veja a Figura 4).

Figura 4 Backup VSS (clique na imagem para ampliá-la)

No entanto, se o sistema operacional convidado não oferecer suporte aos Componentes de Integração ou ao VSS, o processo de backup exigirá que a máquina convidada seja colocada em estado salvo e que seja tirado um instantâneo VSS baseado em host dos arquivos de dados da VM, que poderá ser usado para a recuperação pontual. Os instantâneos VSS de estado salvo produzirão algum tempo de inatividade 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 convidado 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 levar 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 convidado, é possível optar por ter uma NIC física dedicada no host associada a uma rede virtual usada por todos os convidados.

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 convidado 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 você tiver VMs sem os Componentes de Integração instalados, o VSS não será usado. Nesse caso, você 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 inatividade, 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, usando o NTBackup ou o WSB, dependendo do sistema operacional da VM. Vejamos como usar o WSB em convidados compatíveis que têm os Componentes de Integração instalados.

Fazendo backup de VMs com o WSB

O Hyper-V não registra automaticamente seu gravador VSS para uso com o WSB. Você precisa adicionar manualmente a chave e o valor do Registro mostrados na Figura 5 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

Figura 5 Chave e valor para registrar o gravador VSS do Hyper-V

Caminho	Chave ou valor do Registro	Tipo
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}	Chave	n/d
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier	Valor	REG_SZ (Hyper-V, por exemplo)

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

Veja como instalar o WSB. Clique em Iniciar | Gerenciador de Servidores. No painel esquerdo, clique em Recursos. Depois, clique em Adicionar Recursos no painel direito. Na página Selecionar Recursos, expanda Recursos de Backup do Windows Server e marque as caixas de seleçã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. Selecione 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, selecione Backup.

Considerações

• Você precisa fazer backup de todos os volumes relacionados a uma VM. Isso inclui VHDs (discos rígidos virtuais), arquivos de configuração e instantâneos da VM.
• Se estiver criando um Agendamento de Backup, você 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, você poderá armazenar o backup em um volume local não dedicado, em um dispositivo removível ou em um compartilhamento de rede.
• Se os Componentes de Integração não estiverem instalados na VM da qual você estiver fazendo 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, você precisa restaurar volumes inteiros.

Para fazer isso, é preciso ir para Iniciar | Ferramentas Administrativas | Backup do Windows Server e, no painel Ações, selecionar 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, você pode selecionar o tipo de recuperação.

Neste ponto, é preciso tomar uma decisão. Se você precisa da VM inteira, inclusive de sua configuração, instantâneos e discos virtuais (por exemplo, no caso de uma falha completa do host), selecione Restaurar Aplicativo e depois Hyper-V, conforme mostrado na Figura 6. Nesse caso, você 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 6 Restaurando um backup do Hyper-V (clique na imagem para ampliá-la)

Se você precisar apenas do VHD, e os dados de configuração e os instantâneos da VM estiverem íntegros, poderá selecionar 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 mente ao fazer o backup da VM, salvando primeiro seu estado.

Se você sofreu uma perda total do sistema e dos dados e precisa recuperar o host Hyper-V propriamente dito, incluindo o sistema operacional 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

Fizemos uma análise das etapas e considerações sobre backup e restauração de hosts e convidados Hyper-V usando o WSB, um recurso confiável, gratuito e interno, mas que não é uma solução de proteção de dados de nível empresarial. Quando o WSB sai de cena, entra o DPM (Data Protection Manager) 2007 SP1. Com lançamento programado para o final de 2008, o DPM SP1 dará suporte ao Hyper-V e trará alguns recursos interessantes:

• Um único console de gerenciamento para todos os hosts e convidados Hyper-V.
• Proteção contínua de dados, tirando instantâneos baseados em VSS em intervalos de até 15 minutos e capturando somente os bits alterados no processo.
• Reconhecimento de cluster Hyper-V, permitindo 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 convidados Hyper-V; backups VSS sem agente de convidados 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 você utiliza atualmente uma solução de backup de terceiros, fique atento às atualizações do aplicativo. A maioria dos fornecedores está se empenhando para lançar 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 registrar manualmente o gravador VSS do Hyper-V no Registro.

A Figura 7 mostra alguns comandos de WBAdmin. Para obter a documentação completa de WBAdmin, consulte go.microsoft.com/fwlink/?LinkId=124380. Como você pode ver, não há nada em WBAdmin para configurar a diretiva de backup propriamente dita, mas há um snap-in do Windows PowerShell para gerenciar essas configurações. Você pode fazer um teste para verificar se esse snap-in está registrado com o seguinte comando:

Get-PSSnapin -Registered

Figura 7 Comandos de WBAdmin

Comandos de WBAdmin	Descrição
ENABLE BACKUP	Habilita ou modifica um backup diário agendado.
DISABLE BACKUP	Desabilita backups diários agendados em execução.
START BACKUP	Executa um backup.
STOP JOB	Interrompe o backup ou a recuperação em execução no momento.
GET VERSIONS	Lista detalhes de backups recuperáveis a partir de um local específico.
GET ITEMS	Lista os itens contidos no backup.
START RECOVERY	Executa uma recuperação.
GET STATUS	Emite um relatório sobre o status da função em execução no momento.
GET DISKS	Lista os discos online no momento.
START SYSTEMSTATERECOVERY	Executa uma recuperação de estado do sistema.
START SYSTEMSTATEBACKUP	Executa um backup de estado do sistema.
DELETE SYSTEMSTATEBACKUP	Exclui um ou mais backups de estado do sistema.

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

Add-PSSnapin windows.serverBackup 

Quando ele estiver carregado, você 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 8 Os cmdlets do Backup do Windows Server

Cmdlet	Descrição
Add-WBBackupTarget	Adiciona um destino de backup à diretiva de backup.
Add-WBVolume	Adiciona um volume à diretiva de backup.
Get-WBBackupTarget	Obtém destinos de backup de uma diretiva.
Get-WBDisk	Obtém todos os discos.
Get-WBPolicy	Obtém a diretiva de backup atual.
Get-WBSchedule	Obtém o agendamento de backup na diretiva.
Get-WBSummary	Obtém o histórico e o resumo de backups.
Get-WBVolume	Obtém todos os volumes.
New-WBBackupTarget	Cria um novo destino de backup.
New-WBPolicy	Cria uma nova diretiva vazia.
Remove-WBBackupTarget	Remove um destino de backup da diretiva.
Remove-WBPolicy	Exclui a diretiva de backup.
Remove-WBVolume	Remove um volume da diretiva.
Set-WBPolicy	Salva o objeto WBPolicy para criar um backup agendado.
Set-WBSchedule	Define o agendamento da diretiva de backup.

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 seletivo do que seria possível usando o WSB. E é importante que você 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

Esse 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 transacional — 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 é atualmente um processo manual (a VM precisa ser recriada, os instantâneos não são preservados, e assim por diante). Embora isso tenha algumas desvantagens evidentes, os dados são protegidos.

Conclusão

A DR pode ser um processo árduo, que parece nunca terminar. Mas a virtualização de servidores traz novas possibilidades, devido às tecnologias e também ao ponto de entrada resultante de menor custo. A Microsoft fornece não apenas a virtualização, mas todo um ecossistema. Juntos, a plataforma de virtualização de servidores e a família System Center oferecem soluções mais abrangentes para os desafios de complexidade crescente enfrentados pelas organizações, o que inclui a DR.

Gostaria de agradecer a James O'Neill por sua contribuição para este artigo.

Adam Fazio atua nos Serviços de Consultoria Microsoft há mais de 2 anos e agora se dedica às práticas para o setor público dos EUA. Ele presta serviços no setor de TI há mais de dez anos, tendo trabalhado em diversos projetos de infra-estrutura e operações de data center para empresas emergentes de Internet na lista Fortune 100. Atualmente, é chefe de escalonamento técnico no Programa Global de Implantação Rápida de Virtualização da Microsoft.