
Olá, pessoal!
Na v12 do Veeam Backup & Replication foi introduzido a possibilidade de criar o backup dos seus workloads direto na cloud, ou seja, você pode agora utilizar um repositório de Object Storage para envio dos backups sem a necessidade da utilização do Scale-Out Backup Repository.
Nesse artigo demonstrarei todo o processo utilizando um repositório na Azure como exemplo.
Antes de iniciarmos a configuração do repositório e job no Veeam Backup & Replication, primeiro precisamos criar todos os recursos que serão utilizados na Azure.
Nesse exemplo irei criar uma vNet, Subnet, Network Security Group para o Helper Appliance e também um Storage Account com imutabilidade habilitado para armazenar nossos backups.
Criação do Storage Account na Azure
O primeiro passo será criar um Storage Account. Dentro do Resource Group, clique em Create:

Procure por Storage Account e clique em Create:

Escolha um nome para o Storage Account, ele deve ser único na região.
Escolha também as opções para Peformance e Redundancy. No meu exemplo estou escolhendo as com o menor custo.

Em Data protection desabilite as opções de Soft Delete. É essencial que isso seja feito porque o Veeam Backup & Replication não suporta Storage Account com soft delete habilitado.

Ainda em Data protection, habilite apenas a opção “Enable versioning for blobs”.

Revise as informações escolhidas e clique em Create.

Com o Storage Account criado, navegue até a seção de “Containers” e escolha a opção para criar um novo container.

Escolha um nome para o container e seleciona a opção “Enable version-level immutability support”.

Vá até a opção “Access Keys” e anote o nome do Storage Account a key. Essas informações serão utilizadas durante a criação do repositório no Veeam Backup & Replication.

Criação de Network na Azure
Esse passo é necessário apenas se você decidir habilitar a opção de Health Check no job de backup ou se for utilizar um repositório do Archive Tier no futuro.
Entretanto, é bom já ter os recursos de rede criados ao invés de deixar o próprio Veeam Backup & Replication criar automaticamente.
Primeiro vamos criar a Virtual Network e Subnets.
Volte ao Resource Group, clique em Create e procure por virtual network.

Escolha um nome e a região para a vNet.

Por padrão a vNet já vem um bloco de IPs /16 e uma Subnet criada. Você pode manter eles ou criar novos.
Em meu exemplo irei criar um bloco com o endereço 192.168.0.0/16 e uma subnet 192.168.1.0/24.

Revise as informações e clique em Create.

Por último, vamos criar um Network Security Group para ser usado pelo Helper Appliance.
Durante a criação, escolha “Network security group”.

Escolha um nome e a região.

Revise as informações e clique em Create.

Precisamos adicionar as portas necessárias para o servidor do Veeam Backup & Replication conectar no Helper Appliance.
As portas necessárias são 443 e 22. Vá até “Inbound security rules” e clique em “Add”.

Em meu exemplo não vou filtrar o “Source”, mas em seu ambiente você deve definir o IP público que o Veeam Backup & Replication irá utilizar para fazer a conexão com o Helper Appliance, evitando assim deixar a conexão aberta de qualquer originem.

Crie a regra para a porta do SSH também.

Após a criação do Network Security Group precisamos associá-lo com a Subnet que criamos.
No menu de Subnets da vNet, clique no nome da Subnet.

Em Network Security Group escolha a que criamos e clique em Save.

Agora temos tudo que precisamos do lado da Azure.
Criando repositório no VBR
Na console do VBR escolha a opção “Object storage” durante a criação do repositório.

Escolha Microsoft Azure Storage.

Escolha Azure Blob Storage.

Escolha um nome para o repositório.
Você pode limitar o número de tasks concorrentes que esse repositório irá aceitar, no caso dos grandes provedores de Cloud não é necessário limitar.

Clique em “Add” para criar a credencial de acesso ao storage account que criamos.

Em Account preencha com o nome do Storage Account e em Shared key utilize a key que copiamos anteriormente.

Em “Connection mode” você pode escolher qual servidor fará a conexão com a Azure.
Escolhendo “Direct” o Proxy será reponsável por enviar os dados processados direto para a Azure.
Escolhendo um Gateway Server você pode definir qual servidor será responsável por esse envio.

O Container que criamos durante a criação do Storage Account já virá selecionado. Devemos criar uma Folder onde o backup será armazenado.

Escolha o nome que deseja e clique em OK.

Você pode definir um limite de consumo para o repositório habilitando a opção “Limit object storage conumption”. Caso o limite seja alcançado o VBR não iniciará novas tasks nesse repositório.

Em “Make recente backups immutable for” podemos escolher por quanto tempo desejamos que os restore points sejam imutáveis.

Por último, temos a opção de usar o Cool Blob Storage. Isso fará com que os arquivos gravados no Blob já sejam criados como Cool. Caso você não marque essa opção será utilizado o tier que foi definido durante a criação do Storage Account.

Em “Mount Server” podemos escolher o servidor que será utilizado para o processo de restore como Mount Server.
Podemos definir também a pasta de cache para o Instant recovery e habilitar o vPower NFS.

Ainda em Mount Server, se quisermos utilizar o Health Check para os Jobs de backups, precisamos configurar o Helper Appliance.

O Helper Appliance, como ditor anteriormente, é uma VM Linux que será iniciada para verificar a cadeia de backup no Blob, por isso ele é criado diretamente na Azure para ficar o mais próximo possível dos arquivos.
Para executar esse processo precisamos adicionar uma conta que possua acesso a Azure para efetuar esse processo de criação.
Clique em “Add” para abrir o wizard de criação do Microsoft Azure Compute Account.

Escolha um nome para a conta.

Escolha o tipo de conta utilizada.

Escolha “Create a new account”.

Abra a URL informada e cole o código fornecido.

Faça login com uma conta que possua a Role de Owner na Azure. É importante que o usuário tenha essa permissão porque durante esse processo um AD Application será criado na Azure com as permissões necessárias.

É esperado que você veja uma mensagem como a abaixo caso a autenticação ocorra corretamente.

De volta ao VBR, não há necessidade de marcar a opção de “Enable direct restore of Linux-based machines” porque nesse exemplo estamos utilizando a conta para criar o Helper Appliance para efetuar o Health Check.

No Summary mostrará que foi criado um Application e quais Subscriptions esse application possui acesso.

Voltando ao Helper Appliance Settings, vamos definir o tipo de VM, Resource Group, Virtual Network e Subnet.

Em Review, se for necessário será instalados os componentes do VBR.

Aguarde a configuração do repositório.

No final teremos um resumo de todas as configurações escolhidas.

Criando Job de backup
Agora que temos o repositório criado já podemos criar o job de backup.
Nesse exemplo criarei um job de backup para VMs do vSphere. Comece escolhendo o nome do job.

Escolha as VMs que deseja proteger.

Escolha o repositório criado em “Backup repositor” e defina a retenção do job.

Em Advanced podemos selecionar a opção de criar um backup full periodicamente.
Como estamos utilizando um repositório na cloud o job irá funcionar no modo Forever Foward Incremental onde temos um backup full e incrementais sequenciais. Não existe a opção de Synthetic Full quando utilizamos um repositório na cloud.

Na aba de Maintenance podemos habilitar a opção de Health Check e configurar para ser executado seguindo um agendamento específico.

Escolha as opções de agendamento e finalize a criação do job.

Após a execução o job deve criar o primeiro backup full.

Teremos o backup apenas em Object Storage.

Se tentarmos deletar o restore point receberemos uma mensagem de erro dizendo que o arquivo está imutável.

Ao iniciar o Health Check a cadeia de backup das VMs será verificada.

Na Azure veremos que o Helper Appliance será criado.

Após o processo finalizar o helper appliance será automaticamente deletado.

Se navegarmos nas pastas do Container no Storage Account vamos ver que várias pastas foram criadas e em algumas delas teremos os arquivos com os dados.
Não teremos os arquivos VBK/VIB porque a estrutura de backup é diferente na cloud.

Com isso finalizamos todo esse processo de envio de backups para cloud.
Abaixo vou deixar alguns links da documentação que utilizei durante a criação do artigo.
- Adding Azure Blob Storage
- Microsoft Azure Compute Account
- Microsoft Azure Storage Accounts
- Immutability for Capacity Tier
- Block Generation
- Creating Backup Jobs
- Health Check for Object Storage Repositories
Até breve!
Compartilhe!
Você é o cara!!!!!
Você é o cara!!!!! Top
Excelente artigo Wesley.
Sugestão para o próximo artigo poderia ser restaurando uma VM da Cloud para diferentes tipos de provedores: On-Premisses, própria Cloud e Cloud terceiras.