Chegamos ao quarto e último post referente ao Veeam Backup for Google Cloud. Hoje vou mostrar os três possíveis cenários de restore, considerando, claro, que você já tenha realizado backup das instâncias anteriormente. Os modos são:

• Restore completo de uma instância;
• Restore de discos de uma instância;
• Restore granular de arquivos.

Como sempre, é importante validar se existe alguma limitação ou consideração para o processo que será realizado. Nesse link temos todos os pontos de atenção que devem ser levados em consideração para cenários de restore: Considerations and Limitations – Veeam Backup for Google Cloud User Guide.

Restore completo de uma instância

Ao se autenticar na console do Veeam Backup for Google Cloud, em Protect Data, podemos ver as instâncias que possuem backups.

Ao selecionar a instâncias que gostaríamos de recuperar, escolha a opção “Instance Restore”.

Clicando em Restore Point, podemos selecionar diferentes restore points para restauração, seja ele de snapshot ou então de backup.

Em Restore Mode teremos duas opções:

• Restore to original location, with original settings: A restauração acontecerá com as mesmas configurações e no mesmo local da instância original. Normalmente escolhermos essa opção quando a instância original é deletada.
• Restore to a new location, or with different settings: Utilizamos essa opção quando é necessário restaurar a instância em outro projeto/região e alterar as configurações originais da instância.

Nesse exemplo usarei a segunda opção para mostrar todas as opções que podemos alterar durante o processo.

Escolha primeiro o Projeto em que a instância será restaurada. A conta de serviço será selecionada automaticamente.

Escolha a região e a zona de disponibilidade para realizar a restauração.

Podemos manter a criptografia original ou, se desejar, alterar para uma chave diferente.

Na próxima tela vamos receber um erro informando que já existe uma instância com o mesmo nome (linux01). Nesse caso, é obrigatório alterar o nome da instância que será restaurada.

Podemos, além de alterar o nome, alterar também o tipo da instância. Basta clicar em Edit.

E agora podemos prosseguir com o restore, uma vez que o nome da instância restaurada será linux01-restored.

Na parte de Network Settings é necessário escolher a VPC e as demais opções de rede para seguir com o processo.

Defina a VPC, Subnet e se deseja restaurar as network tags.

Como sempre, no último passo, uma verificação das permissões da conta de serviço será realizada.

Por fim, teremos um resumo das opções escolhidas. Podemos definir ainda se a instância será ligada ao final do processo ou não.

Em Session Logs é exibido o andamento do restore.

Durante o processo de restore, os seguintes passos são executados:

• O Worker é criado na mesma região em que a instância será restaurada;
• É criado e anexado ao Worker um novo disco vazio e persistente;
  • O número de discos criados é igual ao número de discos que a instância possui.
• Os dados serão restaurados do bucket do Google Storage diretamente para o disco persistente, que está vazio;
• Um snapshot do disco persistente é criado;
• Um disco é criado no local que o restore será realizado
• O Worker e todos os snapshots são removidos;
• Uma instância é criada com as configurações escolhidas durante o processo de restauração, e o disco que foi criado anteriormente é atachado a essa nova instância.

Ao final do processo, teremos a instância pronta para ser utilizada no Google Cloud.

Restore de discos de uma instância

Em Protection Data, iremos escolher a opção Disk Restore.

Novamente, podemos escolher não somente o restore point desejado, mas também a opção de Exclusion. Essa opção permite excluir do restore discos que não são necessários.

Ao clicar em Exclusions, vamos definir os discos que serão removidos do processo. No exemplo utilizado eu possuo apenas um disco, logo, não tenho como excluir ele do restore.

Assim como a restauração de uma instância, durante a restauração de discos, também temos as opções abaixo. Neste exemplo, utilizarei a opção de restauração para um novo local.

Vou escolher para restaurar o disco em um projeto diferente de onde se encontra a instância original.

Defino a região e a zona de disponibilidade.

Escolho o tipo de criptografia e se deseja modificá-la.

Em Disk Restore, você pode alterar o nome do disco. Contudo, se um disco com o mesmo nome já existir no Google Cloud, o Veeam Backup for Google Cloud adicionará um sufixo automaticamente ao disco restaurado devido às limitações.

Processo de verificação das permissões….

E, finalmente, o resumo do processo de restauração que será iniciado.

Em Session logs, podemos ver o restore iniciando.

Durante o restore, os seguintes passos são executados:

• O Worker é criado na mesma região em que o disco da instância será restaurado;
• Um disco persistente novo e vazio é criado e conectado ao Worker.
• Os dados são restaurados do bucket do Google Storage para um disco persistente vazio.
• Um snapshot do disco persistente é criado;
• Um disco de snapshot é criado no destino da restauração.
• O Worker e todos os snapshots são removidos;

Após o restore finalizar, o disco já estará disponível na instância.

Restore granular de arquivos

O restore de arquivos é um processo pouco diferente das opções anteriores. Antes de iniciarmos, precisamos fazer duas modificações importantes:

• Habilitar o Private Google Access na subnet utilizada pela instância;
• Habilitar o Access Scope na instância que faremos o restore de arquivos.

Isso é essencial para que possamos realizar a restauração de arquivos com a opção de restaurar no local original. 

Para habilitar o Private Google Access, basta editar a Subnet no Google Cloud e habilitar a opção.

Já Access Scope é uma opção disponível diretamente na instância. Ela precisa estar desligada para efetuar esta alteração.
Escolha a opção de Allow full access to all Cloud APIs.

Após configurar essas opções, estaremos prontos para efetuar o restore de arquivos. Novamente em Protect Data, escolha a opção File Level Recovery.

Por padrão, o último restore point disponível virá selecionado, mas, se necessário, podemos escolher um restore point diferente.

Neste exemplo, selecionarei a opção de restaurar para o local original e manterei a opção de deixar o utilitário de restauração instalado. Assim, se for necessário realizar a restauração novamente, o processo ocorrerá de maneira mais ágil.

Na próxima tela, além de verificar as permissões, também vamos verificar se o Private Google Access está habilitado na subnet da VM e se o Access Scope está configurado.

Na última tela temos o resumo do restore. Basta clicar em Restore para iniciar a recuperação.

Quando o Veeam terminar o processo, será disponibilizado um link para acessarmos o File Browser.

Ao abrir o link no seu navegador, será possível navegar entre o conteúdo dos discos, pastas e arquivos, além, é claro, de selecionar o que precisamos restaurar.

Nesse exemplo, escolhi um arquivo que havia criado anteriormente e deixei na pasta do usuário “wesmrt”. Para seguir, é obrigatório clicar em “Add to Restore List”.

Ao selecionarmos a opção de restauração para o local original, podemos optar por restaurar os arquivos para a sua origem, preservando ou substituindo o arquivo original, se ele ainda estiver presente no local.
Nesse caso vou escolher a opção “Keep”, que vai manter o arquivo original.

O arquivo será restaurado e podemos acompanhar no Session Logs.

Ao acessar a instância via SSH, consigo ver que o arquivo restaurado foi criado e o original foi mantido intacto.

Durante o File Level Restore para o local de origem, os seguintes passos são executados:

• Quando utilizado um restore point de Snapshot, o Veeam Backup for Google Cloud copia os discos persistentes da instância baseado no snapshot e anexa ao Worker;
• Ao utilizar um ponto de restauração de Backup, os discos não são removidos fisicamente do backup. O backup permanece em um estado somente leitura para ser usado na restauração.
• O deploy do Worker é feito com base no tipo de ponto de restauração utilizado:
  • Se for Snapshot, o Worker é criado na região em que a instância de destino dos arquivos reside;
  • Para Backup, o Worker será criado na mesma região onde o bucket do Cloud Storage está localizado.
• Ao usar o Snapshot como ponto de restauração, os discos persistentes criados desse snapshot são vinculados ao Worker.
• Quando utilizado o Backup como restore point, o Veeam Backup for Google Cloud emula a presença dos discos no Worker a partir dos dados do localizados no Cloud Storage;
• Dependendo do sistema operacional, o acesso a instância de destino é diferente:
  • Linux: uma SSH KEY para o usuário veeam_restore_user é criada e essa chave é enviada para a instância utilizando a API de Compute Engine;
  • Windows: a credencial veeam_restore_user é criada na instância de destino utilizando a API de Compute Engine.
• Um túnel IAM criptografado é criado entre o appliance do Veeam Backup para Google Cloud e a instância de destino, permitindo o acesso administrativo.;
• Um bucket é criado no Cloud Storage sob o nome “veeam-transfer-files-GUID” na região correspondente à VM de destino, a fim de copiar o utilitário de restauração.
  • Este mesmo bucket será usado para o restauro de arquivos futuros, a menos que seja excluído manualmente.
• A interface de restore é criada e a URL para acesso é exibida;
• Os arquivos e pastas selecionados para restore são enviados para a instância de destino utilizando o serviço Pub/Sub do Google Cloud;
• O utilitário de restore é removido do bucket criado;
• O Worker utilizado pelo restore é deletado.

Para concluir a sessão de restauração, devemos retornar ao console e selecionar a opção ‘Stop Recovery Session‘. Isso encerrará o processo e eliminará o Worker em execução.

Com isso, finalizamos a demonstração das três opções de restore disponíveis para instâncias utilizando o Veeam Backup for Google Cloud.

Ficou com alguma dúvida? Deixa aqui seu comentário!

O post Veeam Backup for Google Cloud – Parte 4 apareceu primeiro em Explain IT.

Chegou a hora de mostrarmos como um backup é realizado e como configurar as políticas para proteger o ambiente com o Veeam Backup for Google Cloud.

Como o Backup funciona

É importante entender exatamente como o backup das VMs funciona no Veeam Backup for Google Cloud, uma vez que cada ação envolve custos (as vezes altos) nos ambientes em cloud.

• Para realizar um backup, é essencial criar inicialmente um Snapshot. O processo de backup utiliza esse Snapshot como base.
• O Veeam Backup for GCP utiliza as APIs do Google Cloud para solicitar a criação de um snapshot de cada disco da VM e adiciona labels para identificá-los.
• Se a opção de criar backups estiver configurada, então o seguinte processo é realizado:
  • Um novo Worker é instanciado na região em que a VM se encontra. O tamanho desse Worker é baseado nas configurações de profile explicadas no post anterior.
  • É criado um volume para cada snapshot. Esses volumes são adicionados ao Worker.
  • Os dados são lidos dos volumes que foram adicionados ao Worker e transferidos para o repositório.
  • Ao final do backup, o Worker é removido e os volumes são deletados.

Importante salientar que, caso você possua quota de disco suficiente, um volume adicional de 4TB é criado junto com o Worker para ajudar na performance do backup. Caso não seja possível criar esse volume, o backup irá ser executado normalmente, mas com uma performance inferior.

No Veeam Backup for Google Cloud, a retenção dos restore points é configurada no momento da criação do backup. Já a aplicação da retenção nos backups é executada uma vez por dia.

Para maiores detalhes de como o backup funciona, acesse o link: VM Backup – Veeam Backup for Google Cloud User Guide

Criando uma Policy

Na seção das Policies, na aba VM, clique em Add.

Defina um nome para a policy.

Escolha o Source Type, que pode ser por Projeto ou pela Folder onde as VMs se encontram. A conta de serviço será automaticamente preenchida.

Escolha a região onde estão as VMs. É possível escolher mais de uma região.

Em Resources, escolha como as VMs serão selecionadas. No meu exemplo, vou escolher por tipo de recurso. Depois disso, posso selecionar a VM que quero proteger. Também é possível utilizar Labels para proteger todos os recursos que foram associados com essa Label. Após selecionar o recurso, clica em Add to Protected.

Você pode também excluir recursos que não devem ser incluídos na política.

Selecione se você gostaria de criar Snapshots Regionais ou Multi-Regionais. Utilizarei Regionais pelo fato de o custo ser menor.

Habilite a opção de Backups e selecione o repositório criado.

Em Schedule, vamos definir quando os snapshots e backups serão criados, assim como a retenção deles. Marcarei apenas a opção Daily nesse exemplo, mas todos os agendamentos podem ser feitos nesse momento.

No meu exemplo, selecionarei 1 backup por dia, às 21h. Na retenção para os Snapshots, vou manter como 1. Para os backups, 7 dias. Como o Backup depende do Snapshot, você é obrigado a criar pelo menos 1 Snapshot.

Nosso agendamento ficará dessa forma:

Em Labels você pode escolher se gostaria de copiar as labels originais dos recursos para o backup.

Na próxima tela podemos configurar quantas vezes gostaríamos que o backup rodasse novamente em caso de falha. Também temos a opção de Health Check, que irá verificar a cadeia de backup toda vez que for executada para validar se existe restore point corrompido. É super recomendado habilitar essa opção e executar ao menos uma vez por semana. Por último, caso as notificações estejam habilitadas, podemos configurar na política.

Na próxima tela será mostrado uma estimativa de custo baseado nas opções selecionadas. Isso é apenas uma estimativa, os valores não são exatos e, caso necessário, devem ser verificados direto no Google Cloud.

E, por último, uma verificação de permissões é realizada para garantir que tudo esteja correto.

Em Summary teremos um resumo da nossa política e podemos finalizar a criação.

Ao executar a policy, veremos que primeiro o Snapshot é criado.

Após finalizar o Snapshot, o backup será iniciado.

Conforme explicado anteriormente, durante o backup, o Worker é criado.

Ao verificar os discos da VM, veremos que um disco adicional foi criado para ler os dados da VM.

No exemplo, ao final do backup foi apresentado o alerta que não foi possível criar o disco de 4TB devido a quota de disco, mas o restore point foi criado com sucesso.

Na seção de Protect Data, teremos os dois restore points criados, referente ao Snapshot e ao Backup.

Com isso podemos efetuar o restore tanto do Snapshot quanto do Backup, não há diferença entre eles.

Além disso, é possível verificar a policy e os backups na console do Veeam Backup & Replication.

Dessa forma, finalizamos essa parte que demonstra como a proteção é realizada. No próximo e último post relacionado ao GCP, mostraremos como pode ser feito o restore dos dados já backupeados.

O post Veeam Backup for Google Cloud – Parte 3 apareceu primeiro em Explain IT.

Habilitando APIs

Antes de iniciar a instalação do Veeam Backup for Google Cloud, vamos preparar o ambiente para receber a instalação. Nesse primeiro passo, iremos habilitar as APIs que necessitamos no GCP para utilizar o produto. Todas as APIs necessárias estão descritas nesse link: Google Cloud APIs – Veeam Backup for Google Cloud User Guide

Para habilitar as APIs navegue até a opção “Enabled APIs & services” na console do GCP.

Clique em “Enable APIs and Services” e procure por “Compute Engine” no nome da API.

Clique em “Enable”.

Repita esse processo para cada uma das APIs descritas no User Guide.

Criando VPC e regras de firewall

Criaremos uma VPC e configuraremos as regras de firewall, caso ainda não as tenha no seu ambiente do Google Cloud. Vá até a opção “VPC networks” na console do Google Cloud.

Já existirá uma VPC default, mas iremos criar nossa própria VPC clicando em “Create VPC Network”.

Defina um nome para a VPC e uma descrição (opcional).

Escolha o nome da primeira subnet, a região onde será criada e o range de IP. No meu exemplo estou utilizando apenas IPv4.

Ignore a sessão de Firewall Rules porque vamos criar as regras no próximo passo. Clique em “Create” para finalizar.

Após a criação da VPC clique no nome para abrir as opções e vá até a aba Firewalls.

Clique em Add Firewall Rule. Ao implementar o Veeam Backup for Google Cloud, as regras de firewall necessárias são estabelecidas automaticamente. No entanto, uma regra que permita ao appliance acessar a internet para atualizar os pacotes não é criada por padrão. É essencial criar uma regra adicional que libere as portas 80 e 443 para todas as VMs na sub-rede, garantindo assim a capacidade de atualização.

Escolha um nome para a regra. Defina também a prioridade. Como essa é nossa primeira regra, não faz diferença a prioridade e por isso vou deixar o valor padrão.

Escolha a direção do tráfego: “Ingress” para o tráfego entrante na subnet e “Egress” para o tráfego saindo da subnet. Determine se a regra deve permitir ou negar o tráfego e selecione o destino. Embora seja possível utilizar Network Tags para especificar o destino, neste caso, optarei por “All instances in the network“.

Em Destination filter, vamos filtrar como 0.0.0.0/0 para liberar qualquer destino.

Em Protocols and ports, vamos definir as portas ou protocolos que vamos liberar. Nesse caso, definiremos as portas 80 e 443. É possível verificar todas as portas necessárias nesse link: Ports – Veeam Backup for Google Cloud User Guide. Clique em “Create” para criar a regra.

Criando IAM Role e Service Account

Para fazer o deploy do appliance do Veeam Backup for Google Cloud, precisamos adicionar uma conta no Veeam Backup & Replication que possua todas as permissões necessárias no projeto do Google Cloud. É possível escolher a opção de criar essa conta automaticamente na console do VBR, mas isso criará uma conta no Google Cloud como Owner, o que não é recomendável. Por isso, nesse passo, vamos criar uma IAM Role no Google Cloud apenas com as permissões necessárias e, depois, uma Service Account que iremos associar com a IAM Role criada.

Em “IAM & Admin” iremos até a opção “Roles”.

Vamos clicar em “Create Role” para criar uma role customizada.

Defina um nome, uma descrição e em “Role launch stage” escolha “General Availability”.

Todas as permissões necessárias estão listadas nesse link na seção Google Cloud Service Account Permissions: Plug-In Permissions – Veeam Backup for Google Cloud User Guide. Clique em “Add Permissions” e adicione as permissões.

Ao final do processo teremos as permissões adicionadas e podemos clicar em “Create” para criar a IAM Role.

Agora iremos até a seção de “Service Accounts” para criar a conta.

Clique em “Create Service Account”.

Escolha um nome e clique em “Create and Continue”.

No segundo passo, selecione a IAM Role que criamos no passo anterior. Clique em “Continue” e “Done”.

Para adicionar a conta no VBR, precisaremos antes criar uma Key para a conta de serviço. Clique na conta criada e vá até a seção de Keys e escolha a opção “Create new key”.

Escolha JSON e clique em “Create”. Guarde o JSON que será criado para ser utilizado no VBR posteriormente.

Assim, finalizamos a criação de tudo que é necessário para realizar o deploy do Veeam Backup para Google Cloud. Os passos subsequentes devem ser executados na console do VBR.

Deploy do Appliance

Primeiro, na console do VBR, vamos adicionar a conta de serviço do Google Cloud. No Menu principal, vá até “Credentials & Passwords” e “Cloud Credentials”.

Em “Add”, escolha “Google Cloud Platform service account”.

Escolha a opção “Use the existing service account”.

Em Key File, escolha o JSON que foi criado anteriormente.

Com a conta criada, vamos em “Backup Infrastructure”, “Managed Servers” e “Add Server”.

Em Veeam Cloud-Native Backup Appliance, vamos escolher o Veeam Backup for GCP.

Escolha a opção “Deploy a new appliance”.

Escolha primeiro a conta de serviço que criamos. Depois, em Data Center, a região que queremos fazer o deploy do appliance e, por último, a Availability Zone.

Escolha o nome da VM do appliance e clique em “Advanced”.

Em Advanced podemos definir o tipo de VM que será utilizado. Por padrão é utilizado o e2-standard-2 com 2 vCPU e 8GB de RAM, que deve ser suficiente para grande parte dos ambientes. Para proteger acima de 100 VMs, devemos seguir as recomendações descritas nesse link: Backup Appliance – Veeam Backup for Google Cloud User Guide. Como estou apenas fazendo o deploy para testes, vou diminuir para uma VM com 2vCPU e 4 GB de RAM.

Na próxima seção devemos escolher a VPC e a Subnet que criamos anteriormente. O Network tag será criado durante o deploy, e o IP público que será mostrado na última opção é apenas o IP público que a console do VBR está utilizando para acessar o Google Cloud e, normalmente, não precisa ser modificado.

Em seguida, devemos selecionar se vamos utilizar um IP Dinâmico ou IP Estático para o appliance. Eu não criei nenhum IP Estático no GCP porque não há necessidade, então vamos selecionar a opção de Dynamic IP address.

Em “Guest OS” devemos criar um usuário e senha para acessar a interface Web do Veeam Backup for GCP e para fazer a autenticação entre o VBR e o appliance.

Clique em “Apply” e aguarde o deploy do appliance. Esse processo pode demorar um tempo considerável.

Clique em Next após finalizar a instalação.

Ao final do processo, veremos que a VM foi criada com sucesso no Google Cloud.

Ao acessar a VM pelo IP público ou IP privado (caso tenha acesso), seremos redirecionados para a tela de login.

No VBR, podemos clicar em “Open console” para abrir a console Web já autenticada.

Com isso finalizamos o deploy do appliance e estamos prontos para iniciar a configuração do produto para proteger os recursos no Google Cloud.

O post Veeam Backup for Google Cloud – Parte 1 apareceu primeiro em Explain IT.

Pré-requisitos e Limitações de Uso

Antes de configurar os backups para os produtos suportados, é essencial validar todos os pré-requisitos e limitações envolvidos. No caso do Azure File Share, considere os seguintes pontos:

• Backup de NFS não é suportado: O Veeam Backup for Azure não realiza backups de compartilhamentos de arquivos NFS no Azure File Share.
• Snapshots vinculados ao compartilhamento: Se o Azure File Share for excluído, os snapshots associados a ele serão removidos automaticamente, incluindo os backups que o Veeam criou com base nesses snapshots.
• Requisitos para Indexing: Para que o Veeam Backup for Azure utilize a funcionalidade de Indexing, o compartilhamento precisa ter habilitados o SMB v3 e NTLM v2, pois são esses os métodos de autenticação necessários.
• Disponibilidade do Indexing: A funcionalidade de Indexing está disponível apenas nas versões pagas do Veeam Backup for Azure. A versão gratuita não permite o uso desse recurso.
• Limite de snapshots: O Azure File Share permite um máximo de 200 snapshots devido a limitações da própria plataforma Azure.

Criando uma Policy

Para simular a policy eu criei um File Share em um Storage Account que já possuía no Microsoft Azure. Nesse File Share eu tenho cerca de 2GB de dados com algumas pastas e arquivos, conforme imagem abaixo:

O File Share já possui SMBv3 e NTLMv2 habilitados para que seja possível utilizar o Indexing:

Na console do Veeam Backup for Azure, clique em “Add” na seção de Azure Files, em Policies:

Escolha um nome e uma descrição para a Política:

Em “Account”, escolha a conta a conta que possui acesso ao Azure File Share:

Em “Region”, selecione a região onde o Azure File Share está localizado:

Em “Resources”, escolha o File Share e adicione na lista de recursos a serem protegidos. Caso não apareça na lista, clique em “Browse to select a target from global list…”.

Marque a opção “Enable indexing” para criar o index durante a execução da Policy.

Habilite o tipo de retenção que necessita (Daily, Weekly ou Monthly). É possível habilitar todas para criar diferentes agendamentos.

Ao editar o schedule, é possível definir o horário e dias que a policy será executada. Também é nessa seção que definimos a quantidade de snapshots que serão retidos.

Em “Settings” podemos definir as notificações e a quantidade de tentativas que a Policy fará caso ela falhe.

Ao final, teremos uma estimativa de custo para Policy baseado nos agendamentos e retenções escolhidos.

Ao executar a Policy, veremos que primeiro é criado o Snapshot.

Em seguida começa o processo de Indexing, onde um Worker será criado para montar o File Share baseado no snapshot e então verificar toda a estrutura de pastas e arquivos para criação do índice.

Quando a Policy finalizar, poderemos ver o Restore Point criado e pronto para executar uma restauração em “Protected Data”.

Na seção de Snapshots do Azure File Share no Azure Portal é possível visualizar os snapshots criados também.

Para mais informações de como funciona o backup do Azure File Share acessem os links abaixo:

• Considerations and Limitations
• How File Share Backup Works
• Performing File Share Backup

O post Protegendo o Azure File Share com Veeam Backup for Azure apareceu primeiro em Explain IT.