Backup e restauração
Em organizações grandes ou pequenas, acidentes e incidentes podem ocorrer. É por isso que você sempre precisa ter um plano para restaurar seus sistemas se eles forem interrompidos. No SQL Server, se você quiser restaurar um banco de dados para um ponto no tempo, poderá fazer isso somente se estiver executando no modelo de recuperação completa. No modelo de recuperação bulk-logged, é mais provável que você precise recuperar o banco de dados no final do backup do log de transações.
Um dos benefícios do SQL do Azure é que o Azure pode cuidar de tudo isso para você. Como o SQL do Azure gerencia seus backups e é executado em um modelo de recuperação completa, ele pode restaurar o seu banco de dados para qualquer ponto no tempo. Você pode até mesmo restaurar um banco de dados excluído dentro da política de retenção configurada. A Microsoft também criptografará automaticamente seus backups se a TDE estiver habilitada no servidor lógico ou na instância.
Por padrão, um backup completo do banco de dados é feito uma vez por semana. Os backups de log são feitos a cada 5 a 10 minutos e os backups diferenciais, a cada 12 a 24 horas. Os arquivos de backup são armazenados no Armazenamento do Azure, no RA-GRS (armazenamento com redundância geográfica com acesso de leitura) por padrão. No entanto, você pode optar por ter seus backups em ZRS (armazenamento com redundância de zona) ou LRS (armazenamento com redundância local). De maneira contínua, a equipe de engenharia do SQL do Azure testa automaticamente a restauração de backups automatizados colocados em pools elásticos e servidores lógicos. Para migrações para a Instância Gerenciada de SQL do Azure, um backup inicial automático com soma de verificação de bancos de dados restaurados com o comando RESTORE nativo ou o Serviço de Migração de Banco de Dados do Azure ocorre. E, na Instância Gerenciada de SQL do Azure, você pode opcionalmente usar um backup copy-only nativo e armazená-lo no Armazenamento de Blobs do Azure.
Criar uma estratégia de backup para a Instância Gerenciada de SQL do Azure e o Banco de Dados SQL do Azure
O SQL do Azure se encarrega do trabalho pesado, mas ainda é importante entender como os backups são armazenados e processados e quais são suas opções de retenção e restauração. Por fim, você ainda é responsável pela estratégia geral para restauração pontual, retenção de longo prazo e restauração geográfica.
PITR (restauração pontual)
No banco de dados SQL do Azure e na Instância Gerenciada de SQL do Azure, você pode executar uma restauração por autoatendimento. Você pode escolher o ponto exato no tempo para o qual deseja restaurar e iniciar o processo usando o portal do Azure, o PowerShell/CLI do Azure ou as APIs REST. A PITR (restauração pontual) criará um novo banco de dados (com um nome diferente) no mesmo servidor lógico. Se você precisar substituir o banco de dados original pelo banco de dados de PITR, precisará renomear o banco de dados original e o novo para voltar a uma condição de funcionamento. Você não precisará atualizar as cadeias de conexão.
A retenção de PITR varia de um a 35 dias. Por padrão, o período de retenção (para todas as camadas de serviço e opções de implantação) é de sete dias. Na maioria das opções de implantação e camadas de serviço, você pode configurar a política entre um e 35 dias, dependendo dos requisitos do seu cenário. Por exemplo, talvez seja necessário apenas um dia para um banco de dados de teste, mas escolher o máximo de 35 dias para um banco de dados crítico.
LTR (retenção de longo prazo)
Se 35 dias não forem o suficiente para atender às necessidades ou requisitos de conformidade de sua organização, você poderá escolher a LTR (retenção de longo prazo). Essa opção permite criar automaticamente backups de banco de dados completos que são mantidos em armazenamentos RA-GRS, ZRS ou LRS por até dez anos. Para o banco de dados SQL do Azure, a LTR está em disponibilidade geral. Para a Instância Gerenciada de SQL do Azure, a LTR está disponível em uma versão prévia pública limitada.
Restauração geográfica
Se houver um evento catastrófico, sua organização precisará ser capaz de se recuperar. Os backups são armazenados automaticamente em RA-GRS (a menos que você opte por ZRS ou LRS), o que significa que os backups serão armazenados na região emparelhada. Portanto, se uma região inteira falhar e seus bancos de dados ou instâncias gerenciadas estiverem nela, você estará protegido. Usando o backup replicado geograficamente mais recente, você pode fazer uma restauração geográfica para qualquer outra região. Esse backup pode ter um pouco de atraso em relação ao primário, pois a replicação do blob do Azure para outra região leva algum tempo. Você pode executar facilmente uma restauração geográfica usando o portal do Azure, o PowerShell/CLI do Azure ou as APIs REST.