Hoje trago para vocês novidades em relação aos programas da comunidade para 2026. O saldo é extremamente positivo, afinal, das 4 aplicações que submeti, 100% foram aprovadas!! Sendo assim, nesse ano, continuarei como Veeam Vanguard, VMware vExpert, Object First Aces e também como líder do Veeam User Group Brazil.

Veeam Vanguard

2020 foi meu primeiro ano no programa. Antes disso, tinha tentado 2x fazer parte, mas não fui aceito. Entre 2020 e 2026, fiquei fora apenas no ano de 2023 pois estava trabalhando na Veeam (o programa não permite que um funcionário faça parte). Abaixo está a foto oficial do último Veeam 100 Summit, realizado em Praga – República Tcheca, em Novembro de 2025. Todos os membros do Veeam Vanguard são convidados a participar desse evento sensacional.

VMware vExpert

Já são oito anos fazendo dessa comunidade. Confesso que, no passado, estive mais ativo com participações e apresentações. O fato de ser líder do VMUG Paraná contribui exponencialmente para ser aceito como vExpert.

Object First Aces

Esse programa foi criado recentemente pela Object First. Existe desde 2024. Eu entrei no ano passado e consegui renovar minha participação em 2026. A comunidade ainda é nova e está se desenvolvendo. Entretanto, o fato de a Veeam ter comprado a Object First, deixa uma dúvida se ela será absorvida ou se continuará existindo e de forma independente.

Veeam User Group Brazil

Na liderança do VUGBR, dividimos a responsabilidade com outros líderes (Beth, Mateus, Jean e Pulia). Juntos, organizamos os encontros virtuais e cada um faz os encontros presenciais em suas respectivas cidades. Em Curitiba, está programado para o segundo semestre a realização desse evento.

Por hoje é isso pessoal! Todas as atualizações, compartilho no LinkedIn. Se quiser saber mais sobre o processo de aplicação ou como é fazer parte de alguma delas em específico, só me chamar!
Ótima semana a todos!

O post Comunidades 2026 – Veeam Vanguard | VMware vExpert | Object First Aces | Veeam User Group Brazil apareceu primeiro em Explain IT.

Fala galera, tudo em ordem? Chegou o momento esperado: vamos explorar, em alguns posts, o Veeam Data Cloud for Microsoft 365 (VDC365). A famosa ferramenta da Veeam Software para proteger recursos do Microsoft 365, que antes era instalada e operada em ambientes on-premisses, agora está disponível na oferta SaaS (Software as a Service).

Eu vou distribuir o conteúdo em vários posts pra não ficar carregado demais. Na primeira parte, uma breve introdução do produto e também o processo de on-boarding na ferramenta.

Mas antes, senta que lá vem história……

Por muito tempo, o Veeam Backup for Microsoft 365 foi destaque tanto comercialmente quanto tecnicamente. Porém, as evoluções do mercado e as recomendações das consultorias (tipo Gartner), apontavam que era o momento de inovar. E, baseado nisso, a Veeam adquiriu um produto chamado Cirrus, que foi desenvolvido originalmente pela CT4 e protegia o Microsoft 365 e o Azure.

Porque comprar o Cirrus se a Veeam já tinha backup para Microsoft 365?

A grande sacada aqui foi que o produto comprado (Cirrus) já estava sendo ofertado como SaaS (Software as a Service), ou seja, quem contratasse a solução, não precisava se preocupar com absolutamente nada! Tudo é responsabilidade do provedor, nesse caso, a CT4. No formato SaaS, o cliente só precisa pagar e gerenciar o backup. A camada de infraestrutura, disponibilidade, segurança, updates… tudo isso é feito pelo provedor. Quando a Veeam comprou o Cirrus, ela absorveu também todo time de desenvolvimento e suporte. A partir desse momento, nasceu o Veeam Data Cloud.

Esclarecendo

• Veeam Backup for Microsoft 365 (VBM365)
  • Solução “antiga”;
  • On-primesses;
  • Cliente precisa disponibilizar servidor e armazenamento;
  • Instalada e gerenciada pelo cliente/parceiro.
• Veeam Data Cloud for Microsoft 365 (VDC365)
  • Solução mais “nova” e moderna;
  • Formato SaaS;
  • Disponibilizada na nuvem da Veeam (servidor e armazenamento ilimitado);
  • Suportada inteiramente pela Veeam.

Produto

Assim como no VBM365, o VDC365 protege os seguintes itens do Microsoft 365:

• Microsoft Exchange Online (e-mails)
• Microsoft SharePoint Online
• Microsoft OneDrive for Business
• Microsoft Teams

Onboarding

Por se tratar de uma solução SaaS, não existe um processo de “instalação”. Ela já está instalada na nuvem da Veeam, que utiliza, por padrão, os recursos do Azure para hospedar a infraestrutura. Sendo assim,  precisamos apenas configurar nosso tenant do Microsoft 365 dentro do VDC. Esse processo chamamos de onboarding.

Quando o cliente compra o VDC365, ele informa um e-mail para receber o convite e ingressar na plataforma. Apenas como comparação, se fosse o VBM365, o cliente receberia nesse mesmo e-mail uma licença para ser aplicada na console local. O e-mail que o cliente receberá deve seguir mais ou menos o formato abaixo:

Ao clicamos em “Accept Invite“, somos direcionados ao portal do Veeam Data Cloud. Nesse portal precisamos entrar, obrigatoriamente, com o e-mail que foi enviado o convite. Ao se autenticar, começaremos a configurar o tenant dentro do VDC. Embora o processo seja simples, devemos ter bastante cuidado. Por exemplo, nessa primeira tela, além de escolher o nome que daremos pro tenant, também definiremos a região onde os dados ficarão armazenados.

Agora é o momento, de fato, de fazer a integração do VDC com o nosso tenant. Basta copiar o código que é exibido (2), clicar no link (1) e inserir as credenciais de um usuário que seja Admin Global do Microsoft 365 nesse tenant. Se clicarmos em “Advanced Settings (3)“, podemos escolher quais serviços vamos proteger. O Exchange Online já vem marcado e não é possível desmarcá-lo.

Depois, será exibida a tela abaixo informando as permissões que serão adicionadas ao Application do VDC. Parece meio óbvio, mas se você não aceitar, não vai ser possível continuar com a configuração.

A próxima tela nos guiará para definição da política que será aplicada. Aqui podemos escolher se vamos proteger o tenant todo ou se faremos a criação manualmente das políticas (1) após processo de onboarding. Também definimos aqui o período de retenção (2) e quais os itens que serão protegidos (3).

A última tela desse processo é um resumo com as configurações que foram definidas. A partir disso, seremos direcionados para a dashboard inicial e podemos começar a colocar a mão na massa e operar a ferramenta.

É isso ai povo! Nessa primeira parte cobrimos um pouquinho da história do VDC e também o processo de onboarding na ferramenta. Na sequência, vamos ver os processos de backup, restore e navegação na console.

Até a próxima!

O post Veeam Data Cloud for Microsoft 365 – Parte 01 apareceu primeiro em Explain IT.

Vamos fechar a conta e passar a régua em 2025?

Nesse ano, tive a oportunidade de acompanhar de perto diversos anúncios relevantes no ecossistema de proteção de dados, principalmente no que se refere a Veeam. Estive presencialmente no VeeamON, em San Diego, e também no V100 Summit, em Praga, conversando com clientes, parceiros, times técnicos e executivos da Veeam. Foram momentos importantes de troca, discussão técnica e visão estratégica.

Depois de tudo isso, se fosse para eu escolher o que mais causou impacto, facilmente escolheria o Veeam Software Appliance (VSA): não foi uma feature nova, nem um ajuste de software. Foi uma mudança estrutural na forma como o Veeam é entregue, operado e protegido.

O que mudou e por que isso importa (sempre considerando minha opinião )

Durante anos, o mercado se acostumou a tratar o Veeam Backup & Replication como um software que roda em Windows. Funcionalmente, isso nunca foi um problema, pelo contrário: todos gostavam dele rodar em Windows pela praticidade e facilidade. Porém, do ponto de vista operacional e de segurança, sempre houve um custo oculto envolvido. Hardening manual, patching constante, dependência de sistema operacional, licenciamento e uma superfície de ataque maior do que o necessário.

Quando o VSA chegou, essas barreiras foram superadas. O Veeam passou a ser entregue como um appliance de software, baseada em Linux no conceito JeOS (Just Enough OS), pré-configurado e pré-hardened.

Esse reposicionamento ficou muito claro nas conversas que tive no V100 Summit.

Segurança deixa de ser um projeto paralelo

Um dos pontos que mais me chamou atenção é que o VSA, finalmente, removeu aquele “jeitinho” de implementar rápido pra sair fazendo backup logo e proteger depois. O hardening já vem aplicado, o modelo de privilégios é mais restritivo, a separação de papéis, como Security Officer, é nativa e o MFA para operações sensíveis deixa de ser boa prática e passa a ser requisito.

Impacto real no dia a dia das equipes

Outro fator que reforça o peso desse lançamento é o impacto na utilização diária da ferramenta. Com o VSA, o tempo é melhor aproveitado uma vez que gasta-se menos com:

• Administração de sistema operacional;

• Hardening manual;

• Dependências e atualizações de Windows;

• Discussões sobre sizing e licenciamento de SO.

Mais tempo dedicado a:

• Estratégia de proteção de dados

• Testes de recuperação

• Imutabilidade

• Continuidade de negócio

Isso muda não somente nos recursos operacionais economizados, mas também em implementações mais baratas e mais efetivas, com menor tempo e mais segurança. No final do dia, o VSA simplifica a operação e reduz risco.

E se você quiser saber como é o processo de instalação/configuração do VSA, tem 2 posts aqui no blog que mostram isso:

Instalação do Appliance Veeam v13 – Explain IT

Configuração Inicial do Appliance Veeam v13 – Explain IT

É isso turma! Encerro 2025 com essa opinião, baseada em tudo que vi e vivi nos eventos, em clientes e parceiros. E pra vocês, qual foi a mudança que mais causou impacto em 2025 no ecossistema Veeam?

Aproveito para deixar meus votos de um excelente 2026 para todos vocês!
Grande abraço.

O post Fechamento de 2025 apareceu primeiro em Explain IT.

Hoje estou iniciando uma série de posts sobre a Object First. Vamos passar pelo processos de instalação, ajustes iniciais, atualização e até mesmo a criação de um bucket e configuração dele no Veeam.

Falando bem resumidamente sobre a Object First, é uma empresa que foi criada pelos mesmos fundadores da Veeam (talvez o mais conhecido seja o Ratmir Timashev). E não por coincidência, é 100% compatível e pensada para funcionar em conjunto com a Veeam. Mas é importante saber: embora utilize o protocolo S3, nenhuma outra ferramenta está homologada para trabalhar com Object First.

Outro ponto interessante é que os appliances são sempre físicos. Existe um virtual appliance, entretanto, é apenas para testes/demonstração. Vocês também vão encontrar o mercado chamando a solução da Object First de #Ootbi, que significa Out-of-the-Box Immutability. Um dos grandes diferenciais da solução é a segurança implementada, de uma maneira bem simples, e o desempenho.

Antes de iniciarmos, vale lembrar que a Object First, assim como várias empresas da área de tecnologia, tem um programa de comunidade. Ele é chamado de Object First Aces, composto por pouquíssimos profissionais do mundo todo (menos de 40). Esse ano tive a honra se ser escolhido para fazer parte dele. Se quiserem conhecer quem são os membros ou saber um pouco mais sobre o programa, clique aqui.

Agora que as apresentações foram realizadas, mãos a massa. Primeiro passo é fazer o deploy do .OVA no VMware. Não vou entrar no passo-a-passo desse processo, vamos direto para a instalação.

Considerando que a imagem foi importada e VM ligada, nos deparamos com a primeira tela da instalação. Nela podemos escolher entre Object First Ootbi, Advanced options for Object First Ootbi ou UEFI Firmware Settings. Para a instalação básica inicial, selecionaremos Object First Ootbi.

Agora, temos o License Agreement. Para “passar de fase”, tem que aceitar… sem choro.

A próxima tela é bem importante. Nela escolhemos se vamos fazer uma instalação nova, do zero e criar um novo cluster… ou se vamos ingressar o nó em um cluster já existente. Como no nosso exemplo é o primeiro nó, então selecionamos I don’t have an Ootbi cluster. Configure a new cluster for the appliance e depois Next.

Mais um passo importante: configurações de rede. Insira os parâmetros do seu ambiente e selecione Next.

Após definir as configurações de rede, vamos dar um nome para o appliance. No exemplo, eu coloquei ootbi-lab. Feito isso, vamos em Next.

Como cada segundo é importante, uma configuração que deve ser realizada já no deploy é a definição do NTP server. Usei o servidor do ntp.br para fazer o sincronismo.

Depois de definir o NTP server, o wizard vai realizar uma sincronização do relógio já tentar se conectar à internet para fazer um update. Como essa VM não tinha acesso à internet ainda, não foi possível atualizar. O assistente ainda nos pergunta se desejamos configurar um servidor de proxy para tentar novamente. Aqui vamos pressionar Esc e ignorar essa configuração, afinal, é possível fazer tudo isso depois na console web.

Agora precisamos definir as configurações de rede do cluster. Lembrem-se que, no futuro, posso adicionar mais nós e será através desse IP (que vamos configurar agora) que faremos gerenciaremos de toda a solução. Meu cluster vai se chamar ootbi-cluster.

Já estamos caminhando para o final da instalação, mas antes, precisamos definir uma senha para se conectar. O usuário padrão “objectfirst” é criado automaticamente. A senha deve conter, no mínimo: 12 caracteres, incluindo uma letra maiúscula, uma minúscula, um número e um caractere especial. Se você não atender algum dos requisitos, vai receber uma mensagem igual essa:

Se isso acontecer, pressione Enter ou Esc, volte na tela anterior e crie uma senha que atenda aos requisitos especificados.

A próxima tela do instalador mostra um resumo das configurações:

Depois pergunta se você deseja ativar os serviços de telemetria, onde você permite que alguns relatórios de eventos críticos e estatísticas básicas sejam compartilhados com a Object First. Nenhum dado backupeado ou algo do tipo é enviado ao ativar a telemetria.

Feito isso, finalizamos a instalação do Ootbi. Pra quem conhece VMware, vai perceber que a tela a seguir não é nenhum pouco estranha:

Agora, para validar que está funcionando, basta digitar o IP do node ou o IP do cluster no navegador, usar a porta 8443, e teremos acesso a console gráfica da solução:

E aí pessoal, o que acharam do processo de instalação? Particularmente, achei muito fácil e intuitivo. Nos próximos posts vou navegar na console e mostrar como fazer algumas operações.

Um abraço.
Até a próxima!

O post Object First – Instalação apareceu primeiro em Explain IT.

Agora que ele foi instalado, partiremos para as configurações e ajustes iniciais. Se você não acompanhou o processo de instalação, clique aqui e veja como é fácil.

Após finalizar a instalação, a tela abaixo será mostrada. Nela daremos os primeiros passos, que, é claro, passam por ler e aceitar os termos exibidos. Se você quiser continuar, aceite o contrato navegando até o [Accept] no canto inferior direito da tela.

Primeira ação, de fato, é darmos nome ao servidor. Para nosso exemplo, o servidor vai se chamar explainit-v13. Feito isso, clique em [Next].

Agora definiremos as configurações de rede. Como eu tenho servidor DHCP no ambiente, perceba que já foi atribuído um IP automaticamente. Se esse não for o seu caso, basta navegar até [Static] para definir as configurações manualmente. Depois, selecione [Next].

Agora vamos configurar o servidor NTP para sincronização do horário e também vamos definir o time zone. Configurei para o time zone do Brasil (America/Sao_Paulo) e o servidor NTP usei o ntp.br.

Na guia Host Administrator, muita atenção. Aqui começamos a configurar a parte de segurança do appliance. Nesse momento, precisamos definir a senha que será utilizada pelo usuário “veeamadmin“. Lembrete: toda a construção do appliance foi baseada no framework DISA STIG, sendo assim, a senha para essa conta deve conter, minimamente: 15 caracteres, um número, uma letra minúscula, uma letra maiúscula e 1 caracter especial.

Para nosso exemplo, usei a senha ******************

Tão logo você digite a senha, próximo passo é cadastrar o MFA. Não é possível seguir com a instalação sem fazer esse processo. Mais uma vez podemos notar o quanto a questão de segurança foi levada a sério nessa versão. Não existe nenhuma indicação de qual aplicativo gerenciador de MFA usar, por isso, escolha um de sua preferência. Particularmente, eu gosto de usar o Bitwarden para isso.

Ao finalizar a configuração do MFA, chegamos na guia Security Officer. Aqui criaremos a senha para o usuário “veeamso”. Esse novo “papel” fica responsável por fazer (ou autorizar a fazer) alterações mais críticas no ambiente. Para essa conta, deve-se seguir os mesmos critérios para escolha da senha. Caso contrário, você verá isso:

Notem que existe uma opção chamada [Skip setting up Security Office], ou seja, esse usuário não é obrigatório ser criado, entretanto, se ele não for criado nesse momento, não será possível adicionar depois. Caso você decida por criar o usuário, na primeira vez que ele for logar, será solicitado para ele configurar o MFA.

Ao avançar, chegamos na tela de resumo das configs. Quando selecionamos [Finish], as configurações são aplicadas e os serviços do Veeam são reiniciados.

E se tudo ocorreu corretamente, você verá uma tela similar a essa abaixo. Nela podemos encontrar os endereços para gerenciamento do host, que é feito pela porta 10443 e também o endereço para operação do Veeam (também conhecida como console), que funciona na porta 443.

Host management (porta 10443):

Console para gerenciamento do backup (porta 443):

Legal observar que na da tela de login (console), tem um link para que você possa baixar a console Windows para se conectar no servidor. Lembrando sempre que a versão Web não está com todas as funcionalidades implementadas ainda, por esse motivo, é importante fazer o download e instalar a console versão desktop também.

Ao se autenticar na console web, temos a nova cara do Veeam:

E aí pessoal, o que acharam? Na minha visão, o processo de instalação foi muito simplificado, ficou mais seguro e funcional. Nos próximos posts, vamos avançar nas configurações de gerenciamento do host e, por último, uma revisada na console.

Por enquanto é isso. Um abraço e até a próxima.

O post Configuração Inicial do Appliance Veeam v13 apareceu primeiro em Explain IT.

Conforme falei no post anterior, a ideia agora é mostrar para vocês como o deploy da nova versão do Veeam (v13) é bem diferente, entretanto, simples e muito segura. Lembrando que essa versão foi construída com base em Rock Linux 9.2 e possui console web (um pouco limitada nessa primeira versão) para gerenciamento. A console Windows e a instalação no modo tradicional permanecem disponíveis.

Vou dividir em dois posts diferentes: esse aqui, cobrindo a instalação e o próximo, para configuração inicial (clique aqui).

Recursos: para fazermos o deploy da v13 em uma VM (ISO), os seguintes pré-requisitos são necessários:

• Obrigatório dois volumes de 240GB (mínimo) cada.
• 8 vCPUs.
• 16 GB de vRAM. 

Os requisitos e a documentação oficial podem ser encontradas aqui: System Requirements – User Guide

Depois de baixar o arquivo ISO, atachar no VMware e subir a VM, já podemos ver a console para escolhermos o que vamos instalar. Nesse caso, selecionaremos o Veeam Backup & Replication. Ainda é possível, através dessa tela, instalar o Veeam Enterprise Manager.

Na próxima tela, temos as opções:

• Install – fresh install, wipes everything (including local backups): para instalar do zero, limpando tudo que tenha nos discos. Vamos escolher essa opção.
• Reinstall – keeps backups, erase settings, reinstalls the OS: para reinstalar o sistema operacional, mantendo os backups e apagando todas as configurações.

Vai aparecer uma mensagem solicitando sua confirmação de que os dados todos serão apagados. Clique em Sim e vamos adiante.

O processo de instalação será iniciado. Esse é o momento de pegar um café e aguardar…aguardar…aguardar….

Uma vez que o processo de instalação seja finalizado sem erros, vamos iniciar a configuração inicial do appliance. Para o conteúdo não ficar muito extenso, essa segunda parte será explicada no próximo post (clique aqui).

Resumindo: poucas ações, eliminando muito a possibilidade de erro e garantindo a segurança da ferramenta. Essa é a instalação do Veeam Appliance.

O post Instalação do Appliance Veeam v13 apareceu primeiro em Explain IT.

Fala pessoal, tudo certo?

Guardei esse post para lançar após a realização do VeeamON Tour Brazil, que acontecerá dia 28/08, em São Paulo. Minha ideia era esperar mais alguma novidade que pudesse aparecer, entretanto, devido a um imprevisto, não estarei presente. Sendo assim, vou compartilhar com vocês o que rolou de mais importante (na minha visão) durante o VeeamON, que aconteceu entre os dias 21 e 23 de abril em San Diego (Califórnia) e que tive a oportunidade de participar presencialmente graças ao programa #VeeamVanguard e a #SeprolIT.

Em linhas gerais, posso dizer: foi um evento cheio de novidades importantes para o universo de proteção de dados. A pegada da Veeam em deixar de ser uma ferramenta de backup e restore está cada vez mais forte. Agora, eles posicionam o Veeam Data Platform como uma ferramenta de cibersegurança.

O ápice do evento, com toda certeza, foi o anúncio da versão 13, com melhorias que vão desde a interface até a segurança e recuperação em nuvem. Aqui vão alguns pontos, resumidos, do que acredito ser legal de compartilhar:

Veeam Software Appliance

Talvez, o anúncio que causou mais alvoroço na galera: um appliance da Veeam!! Ele será baseado em Linux com JeOS (Just Enough OS), pré-hardened e com gerenciamento via web. Além disso: sem acesso root para administradores, MFA obrigatório e uma “função” chamada Security Officer. Lembra da pegada sobre cibersegurança que comentei acima? Então, o Security Officer será o responsável por aprovar ações críticas, tais como exclusões de backups. Esse usuário não vai gerenciar o backup ou o ambiente de backup, pelo contrário, ele realmente terá apenas o papel de aprovar (ou não) ações específicas no Veeam.

Veeam Server com alta disponibilidade (HA) nativa

Ao disponibilizar o Veeam Appliance, de “carona” chega também um dos itens mais requisitados pelos clientes e parceiros: suporte a HA (High Availability) para o Veeam Backup & Replication. Isso significa que, em caso de falha do servidor principal, outro servidor (previamente cadastrado e configurado) pode ser requisitado a assumir a função, reduzindo drasticamente o tempo de recuperação do VBR para alguns segundos.

Nova interface web

Outro “benefício” que chegará graças ao Veeam Appliance ter sido arquitetado em Linux: na v13, o Veeam Data Platform terá uma interface web novinha em folha. Essa console trará dashboards com informações úteis, como o novo “Resiliency Score” (métricas que avaliam a saúde geral do ambiente de backup). A navegação é mais intuitiva, com foco em usabilidade e visual limpo.

E ainda teve um tempo para falarem sobre um recurso”diferenciado” da console web: ela terá o famoso, mas discutível dark mode theme. 

Console Windows repaginado

A tradicional console em Windows também foi repaginada. Agora está mais leve, com visual atualizado e, claro, com suporte ao dark mode theme. Os gráficos dos trabalhos de backups continuam presentes, mas com melhor legibilidade e performance. A experiência, em geral, ficou mais fluida, especialmente em ambientes com muitos jobs simultâneos. E por incrível que pareça, a Veeam conseguiu deixar mais fácil uma console que já era tranquila de usar.

RBAC avançado e gestão de acesso refinada

Na v13, devido ao novo design da solução, uma nova abordagem de controle de acesso permitirá criar perfis com permissões granulares. A console se adapta ao que cada usuário pode ver e fazer, com uma granularidade que até então nunca foi vista nos produtos Veeam. Nem mesmo o RBAC que o Enterprise Manager possui pode ser comparado ao que está por vir na v13 do Veeam Data Platform. Adicionalmente, o novo RBAC vai contar também com integração nativa ao Entra ID e suporte a alguns provedores de identidade externos.

E aí turma, o que acharam das novidades? O acesso a versão beta só foi possível pelo fato de ser membro do #VeeamVanguard, que é um programa pertencente ao grupo #Veeam100. Estou preparando um material sobre o processo de instalação e configuração inicial da v13. Em breve publico aqui no blog.

O post VeeamON 2025 em San Diego apareceu primeiro em Explain IT.

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.

Na segunda parte dos posts sobre Veeam Backup for Google Cloud, faremos as configurações adicionais e os ajustes necessários para proteger os workloads que estão sendo executados dentro do GCP.

Adicionando um novo Projeto

Após concluir a instalação, ao entrar na tela de configuração, serão apresentados alguns passos necessários para serem completados antes de proceder com a criação do primeiro backup.

Como nós já adicionamos a conta de serviço durante a instalação, não é necessário executar essa parte agora. Junto com a conta de serviço, também foi adicionado o nosso projeto onde está o servidor do Veeam Backup for Google Cloud.

Em um ambiente de produção, é normal termos diferentes projetos onde existirão recursos para serem protegidos. Então vamos adicionar um novo projeto para simular essa situação. No Google Cloud eu criei um projeto chamado “Production”.

No Veeam Backup for Google Cloud vamos adicionar esse novo Projeto clicando em “Add”.

Optaremos por uma conta de serviço já existente e selecionaremos a opção “Specify granular roles” para definir precisamente as permissões que serão concedidas ao projeto nessa conta de serviço.

Em Roles, vamos escolher as permissões que queremos adicionar a conta de serviço para o projeto. Nesse exemplo irei marcar apenas as permissões relacionadas ao backup e restore de VMs.

Na próxima tela vamos logar com a conta do Google para adicionar as permissões automaticamente. No meu ambiente de laboratório, isso não será possível porque eu precisaria registrar a aplicação (o próprio Veeam Backup for Google Cloud) para efetuar essa conexão. Para isso é preciso ter um FQDN válido configurado no appliance, o que e não é meu caso.

Caso queira fazer o registro da aplicação, pode seguir os passos indicados no User Guide: Registering Application – Veeam Backup for Google Cloud User Guide.

Nesse caso vamos apenas indicar o ID do Projeto que estamos adicionando. É possível verificar o ID do Projeto ao selecioná-lo no Google Cloud.

Em Permissions faremos a verificação das permissões. Obviamente, a conta de serviço estará sem nenhuma permissão, então vai falhar.

Caso tenha feito o registro da aplicação é possível clicar em “Grant”, fazer o login com sua conta do Google e adicionar as permissões necessárias automaticamente. Como não é nosso caso, faremos o download do script que contém todos os comandos para criar as IAM Roles e adicionar as permissões no Projeto. O script deve ser parecido com o exemplo abaixo.

Podemos executar o script de diferentes formas. No meu exemplo farei pelo Cloud Shell na console do Google Cloud.

Após a execução, se formos em IAM no novo Projeto, veremos que as Custom Roles foram criadas.

Em IAM Roles, veremos que a conta de serviço do projeto onde o Veeam Backup for Google Cloud está instalado é membro das novas Roles.

Ao acessar novamente o console do Veeam para Google Cloud e realizar uma nova verificação de permissões, o sistema deverá confirmar que as permissões estão corretamente atribuídas.

Por fim, revise as configurações e confirme a criação do Projeto.

Com isso teremos nossos dois projetos adicionados ao Veeam Backup for Google Cloud.

Criando Repositório

Agora iremos criar o repositório para armazenar nossos backups. Inicialmente, precisamos criar nosso bucket no Cloud Storage. Na console do Google Cloud iremos selecionar a opção “Buckets”.

Na criação do Bucket, primeiro devemos escolher um nome único para ele.

Escolha o tipo de localidade e em qual local será criado. Em meu exemplo, vou utilizar Single Region.

Escolha o tipo de classe do bucket. O Veeam Backup for Google Cloud não suporta o tipo Coldline na v5, mas pode ser que seja adicionado o suporte a esse tipo de classe no futuro. Sempre verifiquem o User Guide para saber quais tipos são suportados para o repositório: Considerations and Limitations – Veeam Backup for Google Cloud User Guide.

Em meu exemplo escolherei o tipo Standard.

Não mudaremos nada no tipo de acesso.

Em Data Protection devemos desabilitar a opção de Soft Delete. Essa opção não é suportada para os buckets utilizados como repositório.

Com o Bucket criado podemos iniciar a criação do repositório no Veeam Backup for Google Cloud.

Escolha um nome para o repositório.

Escolha o projeto onde o repositório será criado.

A conta de serviço já virá preenchida. Apenas precisamos clicar em Generate HMAC Credentials para adicionar o Access Key e Secret Key para ter acesso ao bucket.

Na próxima tela vamos escolher o bucket, criar uma pasta para os backups e a classe dos dados.

Podemos também habilitar a criptografia para os dados. Não é obrigatório, mas é sempre recomendado.

Ao final do processo teremos nosso repositório pronto para receber os backups.

Configurando os Workers

Os Workers são utilizados para diversas operações no Veeam Backup for Google Cloud, como, por exemplo, backup, restore e retenção. O Worker é uma VM Linux provisória, com binários da Veeam, que, após a finalização da operação, é removida automaticamente.

Precisamos configurar algumas opções do Worker antes de poder utilizá-los. Na seção de Worker, vamos clicar em “Add”.

Primeiro devemos escolher a região. Para executar os backups de VMs em diferentes regiões vamos sempre precisar adicionar a configuração do Worker para aquela região.

Na próxima tela iremos escolher a VPC, Subnet e Firewall Rule que os Workers vão utilizar quando forem criados.

Na próxima tela iremos verificar os pré-requisitos da rede escolhida para o Worker.

• A subnet utilizada deve possuir o Private Google Access configurado;
• O acesso a porta 443 deve estar acessível da internet para a Subnet para que seja possível utilizar o File Level Restore;
• Caso haja a necessidade de backup e restore do Cloud SQL, a VPC precisa ter o Private Access configurado.

Para habilitar o Google Private Access na subnet devemos editar a Subnet e alterar a opção abaixo para “On”.

Não há a necessidade de configurar o Private Access na VPC, mas, caso seja necessário para o seu ambiente, é possível seguir a documentação do Google Cloud para isso: Private services access  |  VPC  |  Google Cloud.

Ao fazer o recheck, o único Warning que teremos deve ser referente ao Private Access.

Por último, devemos configurar os Profiles do Worker. Por padrão, dependendo da operação que será executada e do tamanho da VM a ser processada, o tipo de VM do Worker irá variar.

• Primary Profile (e2-highcpu-8) – é utilizado enquanto temos quota de disco disponível;
• Secondary Profile (e2-highcpu-2) – é utilizando quando a quota de disk está acabando;
• Archiving profile (e2-sdatandard-4) – é utilizado para transferir dados pro repositório de archive.

Ao adicionar um profile, podemos alterá-los posteriormente. Escolha a região onde o Worker será iniciado.

Se necessário, altere o tipo de VM para cada profile. Por padrão isso não é necessário, mas, dependendo do tamanho da VM que você irá restaurar, pode ser necessário modificar o tipo de VM que o Worker usa.

Ao final teremos nosso Profile criado.

Na guia “Label” podemos configurar Labels para serem adicionadas ao os Worker. Os Labels funcionam como se fossem Tags. Para configurar só devemos escolher o “Name” e “Value” do Label e clicar em Save.

Ao retornar à seção “Getting Started”, teremos todos os passos configurados e nosso ambiente estará pronto para criar os backups.

Mais um passo concluído! Próximo post vamos criar os trabalhos de backup e começar a proteger o ambiente.

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