Contents
- Informações gerais
- Informações gerais sobre os backups do XenServer
- Backup e recuperação do XenServer sem software de terceiros
- Instalação do cliente Bacula em cada VM guest
- Usando o módulo Citrix Hypervisor para criar backups de imagem
- Processo de backup
- Processo de restauração
- Outras soluções de backup para XenServer
O Citrix Hypervisor (anteriormente chamado de XenServer) é uma plataforma abrangente de gerenciamento de virtualização com uma variedade de funcionalidades e tipos de infraestrutura suportados. O Citrix Hypervisor é o resultado de um rebranding de um produto anteriormente conhecido como XenServer.
Informações gerais
Além da cobertura de integração nativa do Bacula Enterprise com outros tipos de hypervisors, ele também proporciona integração nativa com o Citrix Hypervisor através de um plugin específico (ou “Módulo”; os termos são intercambiáveis nesse contexto). Esse nível de integração permite aos usuários da Bacula Systems realizar várias operações de backup e recuperação do XenServer em diferentes níveis com o Citrix Hypervisor, não importando o tamanho ou complexidade do data center em questão. Há também um potencial especialmente grande no que diz respeito à flexibilidade e à personalização da solução, incluindo locais de implantação, tipos de dados, métodos de recuperação, e assim por diante.
O backup e recuperação para XenServer Citrix Hypervisor do Bacula Enterprise oferece uma variedade de recursos diferentes, incluindo:
- Backups completos, incrementais e diferenciais a nível de imagem para XenServer;
- Capacidade de fazer backup online com uma tecnologia de snapshots para VMs guests;
- Capacidade total de restauração de imagem de VM;
- Suporte para os formatos e tipos de backup mais antigos;
- Capacidade de tirar snapshots de VMs guests com base no SAV;
- Uma opção para mudar o diretório de um arquivo de VM, e muito mais.
Informações gerais sobre os backups do XenServer
Há três tipos diferentes de backups que a máquina virtual XenServer distingue: Cold, Warm e Hot. A principal diferença entre esses tipos de backups é o estado da VM durante o processo. O cold backup, ou “backup frio”, só pode ocorrer quando a própria máquina virtual está completamente desligada. O warm backup, ou “backup morno”, não tem que fazer isso, mas ainda são esperadas interrupções do serviço da VM durante o processo de backup. Um hot backup, ou “backup quente”, por outro lado, é feito com um serviço de VM totalmente funcional, mesmo que isso possa afetar o desempenho dela.
Quanto aos backups propriamente ditos, eles podem ser diferenciados entre os backups do servidor XenServer e de suas VMs. Os hosts do XenServer raramente precisam de backups, se é que alguma vez precisam. O principal motivo disso é que os metadados de um host XenServer raramente mudam e é extremamente rápido e fácil instalar o próprio XenServer em um servidor, do zero. Isso resume a tarefa de backup de um host XenServer a simplesmente fazer backup dos metadados do host de tempos em tempos, algo que pode ser feito com um simples comando “xe host-backup” do próprio XenServer.
Os backups das VMs do XenServer, por outro lado, são um pouco diferentes em sua natureza. Esse processo é tipicamente mais complicado do que o processo de backup do host, e é por isso que podemos separá-lo em dois grupos diferentes de opções de backup: básico e avançado.
Os backups básicos de VMs do XenServer geralmente existem para aquelas decisões “tomadas no calor do momento”, incluindo opções como snapshots, exportação de VMs e funcionalidades existentes de backup do servidor. Tanto snapshots, quanto VMs não podem ser considerados como parte de uma estratégia de backup abrangente por uma série de motivos.
Por exemplo, os snapshots tendem a ser extremamente custosos em termos de espaço de armazenamento e são também backups tecnicamente “hot” (com todos os inconvenientes desse tipo de backup). Pode haver algumas complicações de restauração com os snapshots (tais como restauração a nível de arquivo), e a falta geral de opções de personalização, além da automatização, faz com que ele esteja longe de ser suficiente para ser considerado uma estratégia de backup completa.
As opções avançadas de backup do XenServer, por outro lado, são mais variadas, já que esse é o grupo onde entram todas as soluções de backup de terceiros. Como tal, podemos determinar três categorias diferentes de backup, dependendo da abordagem da solução de backup para VM do XenServer: backups a nível de OS, backups com a XenAPI e replicação de armazenamento.
Backups a nível de OS é muito provavelmente o método de backup mais antigo da lista, empregando uma tecnologia que já existe há algum tempo. É verdade que as VMs são virtuais em sua natureza, mas também são consideradas servidores com plena funcionalidade, com drivers e hardware diferentes, mas com o mesmo sistema operacional.
Esse sistema operacional pode ser usado como um link para que as VMs recebam o tratamento clássico de backup do servidor, instalando um agente no sistema operacional para criar backups de diferentes partes dos dados. Tecnicamente falando, até mesmo o Windows Backup integrado pode ser usado como alternativa em termos de backups a nível de OS para o XenServer (mais útil para empresas menores com orçamentos apertados).
Os snapshots da XenAPI são outra maneira de criar backups do XenServer, e esse método particular pode ser o mais difundido entre os três. O uso da XenAPI permite que um servidor inteiro seja copiado como uma imagem, e há muita variedade quando se trata de personalização de backups e recursos adicionais. Por exemplo, alguns dos scripts de backup mais básicos que usam XenAPI podem ser encontrados na internet, e são gratuitos (o NAUbackup seria um bom exemplo disso), mas esses scripts não teriam a personalização e o suporte que soluções de backup com XenAPI de terceiros proporcionam.
A replicação de armazenamento como estratégia de backup pode ser a opção mais cara entre as três, já que tem várias exigências para que funcione em primeiro lugar. Dois ou mais dispositivos de armazenamento são necessários para que essa estratégia funcione, assim como uma conexão entre eles suficientemente forte para suportar a quantidade de tráfego transmitida regularmente. Essa abordagem também torna mais difíceis de implementar alguns recursos úteis, tais como a restauração a nível de arquivo.
Evidentemente, a melhor opção para qualquer empresa seria adquirir uma solução que oferecesse múltiplas abordagens de backup de VM do XenServer, a nível de OS e API, por exemplo, abrangendo tanto as interações físicas quanto as virtuais do sistema. No entanto, isso nem sempre é uma opção, e é por isso que existem tantas soluções diferentes no mercado. O Bacula Enterprise é uma dessas soluções, mas primeiro temos que ver como funcionam as funcionalidades de backup de VM do próprio XenServer.
Backup e recuperação do XenServer sem software de terceiros
Antes de dar uma olhada nas funcionalidades do Bacula para XenServer, é também importante mencionar que existe uma maneira de fazer operações de backup e restauração com o próprio Xen. No entanto, existem algumas limitações: os backups do servidor podem tomar muito espaço de armazenamento, você pode precisar reiniciar com o CD de instalação original para realizar um processo completo de restauração, e você não deve criar backups do domínio de controle do XenServer (domínio 0).
É assim que se realiza o processo de backup:
- Selecione o servidor designado no painel Resources, clique no menu Server e vá para a linha Back Up Server….
- Localize e especifique a pasta que deseja usar como local de armazenamento do arquivo de backup, digite o nome do arquivo e clique em Save. O processo de backup começará. Você também pode usar a guia Logs para ver o processo.
E é só isso, todo o processo de backup consiste apenas nesses dois passos. O processo de restauração também é relativamente simples:
- Primeiro, você terá que localizar esse mesmo menu Server e clicar na linha Restore From Backup….
- No menu seguinte, localize o arquivo de backup que você deseja restaurar.
- Use o CD de instalação do XenServer para reiniciar o servidor e completar todo o processo de restauração.
Instalação do cliente Bacula em cada VM guest
Quando se trata de operações reais de backup e restauração de VMs do XenServer com o Bacula, há uma série de abordagens diferentes, e o processo é um pouco mais sofisticado do que o método original. Antes de mais nada, vamos trabalhar com a maneira como Bacula e Citrix conseguem operar com VMs guests e quais estratégias de backup do XenServer funcionam para eles.
Essa estratégia particular funciona instalando um Bacula Enterprise File Daemon em cada VM guest, tratado como se fossem clientes normais, físicos. Você terá que aproveitar manualmente a programação do Bacula, priorizando e fazendo tarefas paralelas para otimizar o uso de E/S do Citrix Hypervisor e evitar gargalos.
A instalação de um Bacula Enterprise File Daemon em uma VM específica permite à você administrá-la como um servidor físico, permitindo uma série de recursos úteis do Bacula Enterprise, inclusive:
- Compressão a nível de arquivo;
- Verificação de tarefa;
- Precisão de backup;
- Restauração de arquivo individual;
- Exclusão de arquivos ou diretórios específicos;
- Verificação do checksum para procurar spywares.
Usando o módulo Citrix Hypervisor para criar backups de imagem
A estratégia de nível de imagem permite que o módulo Citrix Hypervisor do Bacula use o nível de disco bruto para criar backups. Também não há necessidade de instalar um Bacula Daemon em cada VM para que essa técnica funcione. O módulo Xen aproveita a API do XenServer para localizar e salvar o conteúdo de cada uma de suas VMs usando a tecnologia snapshot e os métodos vm-export/vm-import.
Esse método normalmente economiza recursos significativos, já que não há necessidade de o Bacula “caminhar” através de cada sistema de arquivos de cada VM, permitindo aliviar a carga de trabalho de uma infraestrutura do Citrix Hypervisor em geral. Por outro lado, como esse tipo de backup de VM do XenServer salva literalmente tudo em uma VM particular, isso também inclui arquivos inúteis que você realmente não precisa em seu backup, tais como arquivos temporários ou arquivos de swap. Entretanto, isso também é uma vantagem, já que os arquivos de configuração da VM também são salvos por esse método, permitindo uma restauração muito mais fácil.
Processo de backup
Há quatro passos principais no processo básico de criação de um backup de uma única VM usando o módulo de backup do XenServer:
- Exclusão de versão mais antiga;
- Criação de um novo snapshot da VM e fase de preparação do backup;
- Execução do comando vm-export e dados salvos em um armazenamento Bacula;
- Exclusão do snapshot assim que o backup é feito.
Tanto os estados “em execução”, quanto “parado” da VM guest são adequados para realizar um processo de backup. Os únicos snapshots que seriam considerados antigos pelo sistema são os que se encaixam no modelo específico: BaculaSnapshot_<UUID>_JobID_<NR>. Esses são automaticamente apagados nos estágios iniciais do processo de backup do Xen, portanto é recomendável evitar a criação de snapshots manuais que se ajustem a esse modelo de nomenclatura. O console de status do módulo Citrix Hypervisor ofereceria a você as informações sobre as VMs guests que estão fazendo backup, os estágios de cada backup do XenServer, as atividades de snapshot, quais backups foram apagados, etc. Você pode ver um exemplo dessas informações abaixo:
JobId 135: Start Backup JobId 135, Job=xen.2017-12-28_15.52.21_11
JobId 135: Using Device “FileChgr1-Dev1” to write.
JobId 135: Volume “Vol-0002” previously written, moving to end of data.
JobId 135: xenserver: Start Backup vm: CentOS 7 (fe1ccf3b-1865-3942-c928-d98138397ff1)
JobId 135: xenserver: Old stalled backup snapshots found.
JobId 135: xenserver: Snapshot deleted: 12e387c0-eac5-84b1-8e40-1d0601c9eebf
JobId 135: xenserver: Snapshot created: 03afdf67-4ae3-7b0a-5eb0-2c2520c8580f
JobId 135: xenserver: Snapshot deleted: 03afdf67-4ae3-7b0a-5eb0-2c2520c8580f
JobId 135: xenserver: Backup of vm: CentOS 7 (fe1ccf3b-1865-3942-c928-d98138397ff1)
OK.
…
Cada VM guest que participa do processo significa mais um arquivo de backup do XenServer, nomeado da seguinte maneira:
/@xen/<name-label>/<vmuuid>.xva.
Há também vários parâmetros que são usados para definir partes específicas e variações do processo de backup do Xen.
- vm=<name-label> representa o nome de uma VM guest que você vai fazer backup. Será feito backup de todas as correspondências com o nome entre parênteses. O parâmetro em si é opcional e não é necessário para que todo o processo funcione.
- uuid=<uuid> especifica um UUID da VM guest específica. O UUID é o identificador universalmente único: um número de 128 bits que identifica informações em vários sistemas. O parâmetro em si é opcional e não é necessário para que todo o processo funcione.
- include=<name-label-regex> é uma lista de nomes de VMs guest para backup, expressa através de sintaxe regular. Nesse caso, será feito backup de todas as VMs guest com nomes correspondentes. O parâmetro em si é opcional e não é necessário para que todo o processo funcione.
- exclude=<name-label-regex> é uma lista de nomes de VMs guest para excluir do processo de backup, expressa através de sintaxe regular. Todas as correspondências seriam totalmente excluídas do processo de backup. Não afeta nem os parâmetros vm= nem o uuid=. O parâmetro em si é opcional e não é necessário para que todo o processo funcione.
- quiesce=<0|1> se trata de VMs guest específicas que você deseja que sejam criadas usando o método quiesce. Esse método só é suportado pelo sistema operacional Windows com ferramentas para guests instaladas. Todo a tarefa de backup é abortada se o snapshot da VM convidado não puder ser criado pelo método quiesce.
Vale notar que, como todos os parâmetros de especificação em si são opcionais, o sistema realizaria o backup de todas as VMs guest disponíveis se não houvesse entradas de vm=, uuid=, excluir ou incluir. Há também um parâmetro específico chamado abort_on_error, que ordena que toda a tarefa seja interrompida se houver um erro encontrado no processo de instalação, como a falta de parâmetros vm=, ou qualquer outro parâmetro.
Processo de restauração
O processo de restauração como uma operação autônoma visa dois objetivos principais:
- Restauração para um diretório local a partir de um arquivo XVA;
- Restauração para um XenServer Hypervisor como VM guest nova ou original.
Há vários métodos que podem ser utilizados para o processo de restauração. Podemos usar como exemplo um método de restauração para o XenServer. Ele requer o estabelecimento de um parâmetro de restauração “where=/” no Bacula. Nesse caso, o arquivo da VM guest em questão seria restaurado como uma nova VM via Citrix Hypervisor, ou restaurado como a forma original dessa VM, se a opção de preservação for definida de antemão. O não estabelecimento de um caminho correto para o processo de restauração resultará na criação da VM guest no diretório padrão do Citrix Hypervisor.
Há também o método de restauração para o diretório local, que utiliza o parâmetro “where=/some/path”. Esse caminho precisa representar um local específico no servidor onde o módulo está instalado, e mesmo que não exista, ele seria criado pelo próprio plugin.
O processo básico de restauração é relativamente fácil por si só. Ele só requer um comando específico para ser executado, com o parâmetro “where” adicionado de uma maneira ou de outra:
* restore where=/…
Com relação aos parâmetros de restauração que são usados para incluir ou excluir VMs específicas, esses são similares aos usados no processo de backup. Mas, também há outras adições:
- server: <address> é usado para especificar o endereço da API do XenServer para realizar a operação, e no caso de esse parâmetro estar incorreto ou ausente, o padrão será utilizado em seu lugar;
- port: <number> especifica a porta da API do XenServer a ser usada. Deve estar na faixa de 1 a 65536. O parâmetro inválido faz com que a tarefa seja abortada, e a omissão desse parâmetro leva ao processo usando a porta padrão.
Outras soluções de backup para XenServer
Usar o Bacula também significa se beneficiar do acesso à sua arquitetura mais ampla, altamente segura e robusta, e de um amplo suporte tecnológico, permitindo a integração completa de todo um patrimônio de TI, tudo a partir de uma única plataforma.
É claro que o Bacula Enterprise não é a única solução de backup para XenServer no mercado. De fato, existem várias outras soluções e plataformas de backup e recuperação que têm funcionalidades de backup para XenServer. Isso inclui tanto players populares no mercado quanto empresas menos conhecidas nessa área.
O Vembu BDR é nosso primeiro exemplo, oferecendo uma plataforma de backup e recuperação altamente personalizável, com suporte para muitos tipos de dados e locais de armazenamento diferentes. As funcionalidades de backup do Vembu XenServer são baseadas em um backup a nível de OS (que já comentamos anteriormente), o que implica em backups de imagem para VMs que executam o Xen Hypervisor. O Vembu BDR pode oferecer uma abundância de recursos diferentes para seus usuários do Citrix Xen, tais como backups de VMs com reconhecimento de aplicativos, tecnologia CBT (Changed Block Tracking), migração mais fácil de VMs para outros hypervisors, e mais.
O Acronis Cyber Protect é outro nome bem conhecido na área de backup e recuperação, e seu backup de VM é bastante versátil. Ele suporta não apenas ambientes VMware vSphere e Microsoft Hyper-V, mas também Oracle VM, RHV, Linux KVM e, é claro, Citrix XenServer. O Acronis usa suas próprias funcionalidades massivas para fornecer backup de imagens em disco e operações de restauração para VMs do XenServer, oferecendo tanto um backup completo, quanto um processo de recuperação rápido, enquanto também fornece funcionalidades de proteção de dados via Acronis Active Protection e oferece muitas opções em termos de locais de armazenamento (SAN, fita, NAS, armazenamento em nuvem da própria Acronis e discos locais).
O Commvault também está nesse mercado, com foco em empresas que estão procurando uma solução simples, mas eficaz, de backup para XenServer. Ele oferece uma infraestrutura extremamente flexível, planos de proteção fáceis de usar baseados em SLAs (Service Level Agreements), bem como um controle fácil de toda a arquitetura de backup usando um console de gerenciamento centralizado de VM. A solução de backup para XenServer do Commvault pode atuar como uma base para uma estratégia forte e flexível de recuperação de desastres para uma empresa de qualquer tamanho.
O Unitrends é uma solução de backup que atua de uma perspectiva ligeiramente diferente dos outros, alegando ser capaz de fornecer uma solução abrangente de backup para XenServer, que supre todas as necessidades do cliente quando se trata de proteger suas VMs. A parte de backup e recuperação da plataforma é abrangida pelo Unitrends em parceria com a própria Citrix, para resolver o maior problema do backup de snapshot: suas necessidades de espaço de armazenamento massivo. O Unitrends também pode realizar restauração granular de arquivos, tem um extenso sistema de proteção de ransomware com análise preditiva e aprendizagem de máquina, e muitos outros recursos.
Passando para soluções menores, com conjuntos de recursos específicos, temos o Alike DR, uma solução de backup e recuperação para Citrix Hypervisor que afirma ter um nível sem precedentes de integração com o XenServer, combinada com uma interface fácil de usar. Alguns dos recursos que o Alike DR fornece, incluem o rastreamento de blocos alterados (CBT), interface baseada na web para melhor mobilidade e tomada de decisões, bem como uma variedade de diferentes métodos de backup, uma proteção cruzada dos dados do cliente, e muito mais.
O Xen Orchestra (XO) é também uma solução especialmente focada em suportar e funcionar com todos os tipos de ambientes XenServer. Ele é uma solução sem agentes com uma variedade de recursos de backup e recuperação, que também oferece múltiplos benefícios relacionados a nuvens e uma interface de gestão centralizada para seus usuários. O XO também oferece amplo suporte ao cliente, restauração a nível de arquivo, e fornece uma infinidade de diferentes métricas relacionadas ao XenServer para seus clientes.
A SEP Software tem sua própria solução de backup para XenServer chamada apenas de SEP, que oferece total suporte ao Citrix XenServer em múltiplos níveis. O SEP tem todos os recursos comuns que uma solução de backup do XenServer oferece, tais como CBT, várias opções de backup, restauração a nível de arquivo, e assim por diante. Outros recursos do SEP incluem console de administração centralizada, funcionalidade de criptografia de dados, capacidade de recuperação de desastres, deduplicação de dados, conversão de servidor, etc.
Simplicidade é a base fundamental de outra solução de backup para XenServer: o Vinchin Backup & Recovery. O Vinchin fornece uma solução de backup para VM altamente eficiente tanto para ambientes host, quanto para pool XenServer, combinada com uma proteção de dados abrangente. Ele pode fazer backups sem agente, tem amplas capacidades de automatização e um console de gerenciamento centralizado. Ele também possui a capacidade de recuperar VMs em um curto espaço de tempo, a tecnologia CBT que já mencionamos, a capacidade de criar backups com consumo zero de banda de rede, e assim por diante.
O último, mas não menos importante exemplo na lista é o Xackup, uma solução simples, mas eficaz, de backup para XenServer da Fungusware. Ele tem uma interface amigável, orientada pelo assistente virtual, que ajuda em todos os tipos de operações, como migração de VM, backup de dados, restauração de dados, e assim por diante. Cada um desses processos é muito mais fácil e rápido com o Xackup: o processo de backup tem múltiplos locais de armazenamento alvo, o processo de restauração é capaz de realizar recuperação completa ou a nível de arquivo, e o processo de migração pode transferir VMs entre hypervisors e pools tanto remota, quanto localmente. Também há a possibilidade de automatizar algumas operações, como inicialização, desligamento, etc.