Restore de Backups Armazenados no Azure usando Microsoft SSMS

Olá, espero que você esteja bem! 😉

Como já disse, vou trazer pra vocês sempre algo legal que aconteceu comigo no meu dia a dia como Consultor DBA SQL Server.

Neste primeiro Post do meu blog abordarei um assunto que a cada dia que passa, quanto mais aprendo, mais quero aprender, SQL x Azure.

No meu dia a dia, recebo várias demandas para fazer Restores de Databases, cujo backup estão sendo armazenados em um Blob Container, no Azure.

Através de um script pré pronto que tenho, sempre executava com sucesso e então finalizava a demanda. Porém na busca de melhorias e agilidade nos processos, aprendi algo novo e muito prático, por isso resolvi compartilhar com você.

Para detalhar o máximo possível e fazer com que você não fique perdido ou com dúvida de onde clicar, resolvi colocar muitos prints, mas não desista, acompanhe até o final, e qualquer dúvida pode me mandar um e-mail que será um prazer poder ajudar.

Vou fazer quase tudo via interface, no SSMS (Microsoft SQL Server Management Studio). Isso mesmo, via interface! Depois pode me enviar nos comentários se realmente achou esta opção melhor ou prefere tudo via T-SQL mesmo, rsrs. Bora lá?

Antes de iniciar, ressalvo que estou usando a versão 2019.

Portanto, vamos iniciar clicando com botão direito em Database e escolhendo a opção Restore Database…

Para abrir o local onde estão os arquivos de backups basta marcar a opção de Device em seguida clicar no “três pontinhos”.

O tipo de media será URL, então clique em Add.

Escolha em qual storage containers estão os arquivos, mas caso não tenha nenhum configurado no seu Servidor, clique em Add para adicionar.

Precisamos conectar na conta da Microsoft para conseguir gerar uma senha.

Entre com suas credenciais.

Pronto, logamos. 

Basta ir selecionando cada campo que carregará automaticamente os dados com base no seu Storage Account e blob containers. Após preencher, precisaremos gerar uma senha para fazer os Restores sempre que precisar. Escolha uma Data de Expiração e clique em Create Credencial

A senha gerada será parecida com esta abaixo. Caso queira mudar a data de expiração após já ter gerado, basta clicar no botão Create Credential novamente.

Copie a senha e guarde em um local seguro, pois vai ser usada muitas vezes, pode ter certeza disso, rsrs.

Antes de continuar, temos que ter certeza de quais arquivo(s) usar no Restore. Será apenas o FULL? Vamos precisar de DIFF? E os LOGs vão ser útil? Vamos então logar no Portal do Azure para validar quais arquivos temos.

Neste nosso exemplo vamos usar todos os últimos backups, portanto vamos desconsiderar este FULL do dia 20/03, pois temos um outro FULL mais recente do dia 21/03.

Dando continuidade no Restore pelo SSMS, após entrar com as credenciais corretas, escolher os campos pré-definidos e criar a credencial, vão aparecer todos os arquivos armazenados no blob container e então escolhemos justamente os backups com base na necessidade. Selecione todos os arquivos segurando a tecla “control” e clique em OK.

Valide se inseriu corretamente, caso contrário pode remover ou adicionar mais algum arquivo que faltou, logo depois clicar em OK.

Confira mais uma vez se todas as informações estão correta, inclusive, caso a database de destino não seja para substituir um database existente, será então necessário colocar um outro nome para a database que será restaurada. Neste exemplo como não vamos substituir, colocamos AzureBkp_Blog.

Próximo passo, opção a esquerda clica em Options. Vai ter vários opções de Restore. Marque a Overwrite caso o Restore seja um Replace, ou seja, irá substituir uma database já existente. Lembrando que esta tela tem que estar de acordo com a anterior onde neste nosso exemplo não vamos substituir e sim criar uma nova database. Um detalhe importante, quando optamos por fazer um Replace, se houver alguma conexão aberta na database de destino, será reportado um erro. Para evitar, é nesta tela que tem a opção para marcar de fechar conexões existentes referente a database de destino.

, se

Estando tudo correto, vamos clicar em Script, ao invés de dar o OK.

Com o script em tela é mais fácil pra visualizar todo o código o qual vai ser executado.

Veja que temos três blocos, FULL + DIFF + LOGs. Basta dar F5 para executar todo o script de uma vez só. 

Aguarde, o script finalizará após a execução de cada bloco. Terminando a database ficará ONLINE e acessível.

Script terminado com sucesso.

Um pequeno detalhe que passou despercebido propositalmente foi a files. Observa que esta database que restauramos possui apenas 2 arquivos, sendo um .mdf e outro .ldf , respectivamente dados e log.

Agora vem alguns questionamento que você pode estar fazendo… Você pode estar pensando: “mas Éder, você fez todo esse passo a passo para fazer um Restore, eu tenho um script simples que passo a SAS TOKEN e com ele faço o Restore perfeitamente e muito mais rápido”.

Sim, eu, (Éder) também fazia assim, até que as coisas começaram a ficar mais complexas. 🙂

Imagina agora um Restore de uma Database que tem não apenas 2 arquivos (mdf e log), mas sim mais de 30 arquivos. E esses arquivos terei que trocar o caminho (Path) de cada um, pois não quero eles no caminho Default.

Vamos complicar mais um pouquinho, além de vários arquivos, temos um outro fator diferente do primeiro Restore: devido a database ser muito grande, o Azure tem uma limitação de tamanho de upload por arquivo, e com isso eles estão sendo enviados em mais de uma arquivo. No exemplo, veja que são quatros arquivos. Para quem não conhece, estes quatro juntos equivale a um, ou seja, não posso escolher um deles e fazer o Restore, vai dar erro. Portanto e agora, como fazer?

Como disse, por script T-SQL (sem telinhas) também é possível, já fiz muitas vezes, mas não achei nada prático.

Vamos para uma opção que considero mais prático. Lembra que já cadastramos a credencial na primeira vez? Portanto agora não vamos precisar cadastrar novamente, já temos cadastrado (caso necessário, repita os passos citados neste post anteriormente, fazendo o login para cadastrar a credencial).

Vamos conferir.

Pronto, vamos repetir o passo inicial, botão direito do mouse em Databases, depois Restore Databases… e então Device e 3 pontinhos (…). Em seguida URL. Ao clicar em Add veja que já retornou a credencial cadastrada (url contendo o container e o blob) . Agora só vamos precisar daquela senha que geramos (lembra que falei que ia ser muito útil).

Basta pegar a senha guardada a “sete chaves” em meu cofre de senhas e pronto, copiar e colar. Oba, que fácil essa parte, rsrs!

Após logar na conta, vamos escolher os arquivos de backups. Lembra dos 4 arquivos gerados como backup FULL? Vamos marcar eles (4 partes) e o backup DIFF (que no caso tem apenas um, mas se tivesse mais, marcaria todas a partes também). Neste exemplo não vamos pegar backups de logs, mas caso precise, o procedimento é o mesmo, basta selecionar eles também.

Um detalhe que não citei no primeiro restore foi que assim que marcamos os arquivos e demos OK, o SSMS faz uma validação em arquivo por arquivo, pois neste momento caso algum arquivo este fora da sequência (cadeia de backup) ele é descartado. Ou no caso estiver faltando o FULL, vai retornar um erro. Portanto se tiver muitos arquivos sendo restaurados, esta validação costuma demorar um pouco.

Após validação concluída com sucesso veja que legal, os quatros arquivos de backup FULL transformaram em um apenas. Hum, é mágica!

Na aba de files temos mais uma mudança a ser feita conforme citado anteriormente. Temos mais de 30 arquivos e precisamos mudar os caminhos deles. Que tal outra mágica rápida?!

Basta marcar esta “caixinha Relocate e colocar qual será o caminho onde será armazenado os arquivos de Dados (Data file folder) e os arquivos de Log (Log file folder). E plin!

Caminhos alterados em todos os arquivos “automaticamente”.

Vamos agora gerar o script e dar uma olhada no T-SQL.

No script gerado podemos ver que possui muito mais linhas do que no anterior. Lembrando que neste Restore nem pegamos backups de logs.

Pronto, demos F5 e só aguardar o Restore concluir com sucesso.

Ufa, terminou. Se você continuou até agora e ainda está por aqui, agradeço pela atenção. E espero ter contribuído pelo menos um pouco para o seu conhecimento, pois tentei detalhar o máximo. E me diga nos comentários, gostou da ideia ou não? Prefere tudo via T-SQL e nada de telas?

Se curtiu, compartilhe com um amigo, pode ser que ele também vai gostar.

Abraços e até a próxima! 😉

ederlelis Administrator
DBA Consultor SQL Server

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *