Cópia de segurança e restauro
Em organizações grandes ou pequenas, podem acontecer acidentes e incidentes. É por isso que tem sempre de ter um plano sobre como restaurar os sistemas se forem afetados. No SQL Server, pode optar por restaurar uma base de dados para um ponto anterior no tempo, mas só o poderá fazer se estiver a executar no modelo de recuperação completa. No modelo de recuperação de registo em massa, é mais provável que tenha de recuperar a base de dados até ao fim da cópia de segurança do registo de transações.
Um dos benefícios do Azure SQL é que o Azure pode tratar de tudo isto por si. Uma vez que o Azure SQL gere as cópias de segurança e funciona no modelo de recuperação completa, pode restaurar a base de dados para qualquer ponto anterior no tempo. Pode até restaurar uma base de dados eliminada dentro da política de retenção configurada. A Microsoft também encriptará automaticamente as suas cópias de segurança se a Encriptação de Dados Transparente estiver ativada na instância ou servidor lógico.
Por predefinição, é realizada uma cópia de segurança de dados completa uma vez por semana. Os backups de log são feitos a cada 5-10 minutos e os backups diferenciais a cada 12-24 horas. Os ficheiros de cópia de segurança são armazenados no Armazenamento do Microsoft Azure no armazenamento georredundante com acesso de leitura (RA-GRS) por predefinição. No entanto, você pode optar alternativamente por ter seus backups em armazenamento com redundância de zona (ZRS) ou armazenamento com redundância local (LRS). De uma forma continuada, a equipa de engenharia do Azure SQL testa automaticamente o restauro das cópias de segurança de bases de dados automatizadas colocadas em servidores lógicos e conjuntos de bases de dados elásticas. Para migrações para o Azure SQL Managed Instance, ocorre uma cópia de segurança inicial automática com a soma de verificação das bases de dados restauradas com o comando RESTORE nativo ou o Azure Database Migration Service. Além disso, no Azure SQL Managed Instance, pode utilizar opcionalmente uma cópia de segurança nativa e armazená-la no Armazenamento de Blobs do Azure.
Criar uma estratégia de cópia de segurança com o Azure SQL Managed Instance e a Base de Dados SQL do Azure
O SQL do Azure cuida 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. Em última análise, você ainda é responsável pela estratégia geral de restauração point-in-time, retenção de longo prazo e restauração geográfica.
Restauro para um ponto anterior no tempo (PITR)
Na Base de Dados SQL do Azure e no Azure SQL Managed Instance, pode realizar um restauro self-service. Pode escolher o ponto exato no tempo para o qual quer restaurar e iniciar o processo com o portal do Azure, o PowerShell/CLI do Azure ou as APIs REST. A restauração point-in-time (PITR) criará um novo banco de dados (com um nome diferente) no mesmo servidor lógico. Se precisar de substituir a base de dados original pela base de dados PITR, terá de mudar o nome da base de dados original e da nova para que volte a funcionar. Não tem de atualizar as cadeias de ligação.
A retenção do PITR varia entre 1 e 35 dias. Por predefinição, o período de retenção (para todos os escalões de serviço e opções de implementação) é de sete dias. Na maioria das opções de implementação e escalões de serviço, pode configurar a política entre 1 e 35 dias, consoante os requisitos do seu cenário. Por exemplo, você pode precisar de apenas um dia para um banco de dados de teste, mas pode escolher o máximo de 35 dias para um banco de dados de missão crítica.
Retenção de longo prazo (LTR)
Se 35 dias não forem suficientes para satisfazer as necessidades ou a conformidade da sua organização, poderá optar pela retenção de longo prazo (LTR). Essa opção permite que você crie automaticamente backups completos de banco de dados que são armazenados no armazenamento RA-GRS, ZRS ou LRS por até 10 anos. Para a Base de Dados SQL do Azure, a LTR está em disponibilidade geral. Para o Azure SQL Managed Instance, a LTR está disponível numa pré-visualização pública limitada.
Restauro geográfico
Se ocorrer algum evento catastrófico, a sua organização precisará de ser capaz de recuperar os dados. As cópias de segurança são automaticamente armazenadas no RA-GRS (a menos que opte pelo ZRS ou LRS). Isto significa que as suas cópias de segurança serão armazenadas na região emparelhada. Assim, se uma região inteira ficar inativa e as bases de dados ou instâncias geridas estiverem nessa região, estará protegido. Pode fazer um georrestauro para qualquer outra região a partir da cópia de segurança georreplicada mais recente. Esta cópia de segurança pode estar um pouco atrasada em relação às primárias porque demora tempo a replicar o blob do Azure para outra região. Pode realizar facilmente um georrestauro com o portal do Azure, o PowerShell/CLI do Azure ou as APIs REST.