O SQL Server oferece um recurso de backup e restauração bastante confiável para seus dados. Se você tiver uma estratégia eficaz de backup e restauração caso ocorra um problema, poderá recuperá-lo com um tempo de inatividade mínimo e interrupção mínima para seus usuários.
Segue aqui 10 dicas para aproveitar ao máximo o utilitário de backup e restauração do SQL Server.
1. Use o software de backup nativo do SQL Server;
Os programas de backup do Windows Server não fazem backup de arquivos abertos. Sempre que o SQL Server estiver em execução, todos os arquivos do banco de dados estarão abertos; portanto, esses arquivos não serão incluídos em um backup do Windows. Você pode parar o serviço SQL Server e fazer backup dos arquivos do banco de dados, mas isso afeta negativamente a produção. O utilitário de backup do SQL Server pode fazer backup de um banco de dados em uso e até incluir as alterações feitas durante o tempo necessário para executar a tarefa de backup.
2. Avalie completamente o software de terceiros antes de usá-lo;
Vários pacotes de software de terceiros podem fazer backup do SQL Server, embora alguns cobram mais por esse recurso. Verifique se qualquer pacote de software de terceiros que você escolher pode fazer backup de bancos de dados ativos. Na verdade, alguns desses pacotes interrompem o serviço do SQL Server e fazem backup dos arquivos, algo que você pode fazer com um arquivo em lotes simples e o programa de backup do Windows Server.
3. Tenha uma estratégia de backup;
Seu plano de backup e recuperação deve incluir não apenas como você fará o backup dos dados, mas também como os restaurará. De fato, a melhor maneira de projetar sua estratégia de backup é avaliar o que você precisaria se tivesse que restaurar o banco de dados em várias situações. Por exemplo, como você se recuperaria se perdesse um dos discos no servidor? E se o disco fosse um disco de dados ou o disco que continha o log de transações? Como você se recuperaria se todo o servidor fosse destruído, digamos, em um incêndio? A consideração mais importante não é apenas como você se recuperará, mas a rapidez com que você pode recuperar o banco de dados em produção. Embora os backups sejam executados rapidamente e permitam que os usuários continuem se conectando ao banco de dados, lembre-se de que uma restauração demora mais que um backup e os usuários não podem se conectar ao banco de dados durante o processo de restauração.
4. Considere usar backups do grupo de arquivos;
Se seu banco de dados é tão grande que você não pode executar um backup completo no tempo alocado, uma estratégia de grupo de arquivos pode ajudar. Essa estratégia também pode reduzir significativamente o tempo necessário para restaurar o banco de dados em caso de falha no disco.
A primeira etapa na implementação de uma estratégia de grupo de arquivos é projetar o banco de dados para usar grupos de arquivos efetivamente (por exemplo, colocando tabelas diferentes em diferentes grupos de arquivos). Agora, em vez de executar um backup completo, você pode fazer backup de apenas um grupo de arquivos.
Suponha que você precise fazer backup de um sistema de entrada de pedidos. Em vez de fazer backup de todo o banco de dados todas as noites, você o divide em quatro grupos de arquivos. Você deixa as tabelas de sistema e as tabelas de referência menores no grupo de arquivos principal.
5. Use backups diferenciais quando apropriado
Um backup diferencial faz backup de todas as alterações desde o último backup completo.
Com o backup diferencial, uma restauração é executada mais rapidamente porque você restaura apenas o backup completo mais o backup diferencial e ignora todos os valores de dados intermediários.
6. Use uma mistura de backups diferenciais e de log
Suponha que você execute um backup completo do seu banco de dados ativo no fim de semana. Todas as noites, você executa um backup diferencial para registrar o estado dos dados no final do dia. E várias vezes durante o dia, você faz backup do log de transações, que captura todas as alterações feitas nos dados durante o dia. Agora, suponha que o sistema falhe às 10:00 da manhã de quinta-feira. Para restaurar, você aplica o backup completo, o backup diferencial a partir de quarta-feira à noite e quaisquer backups do log de transações que você fez desde esse backup diferencial. Essa estratégia mista é mais rápida do que restaurar o backup completo do banco de dados e vários backups do log de transações que você criou ao longo de vários dias.
7. Não use backups diferenciais se não forem apropriados
A chave para saber quando os backups diferenciais são adequados é ver como seus dados são indexados e atualizados. Se suas tabelas tiverem índices agrupados e as colunas de índice aumentarem números, como número do pedido ou número do cliente, o SQL Server adicionará todos os novos dados ao final das páginas de dados existentes. Esse fato é bom para backups diferenciais porque todos os novos dados estão concentrados em um intervalo limitado de páginas. No entanto, se a entrada de dados ocorrer aleatoriamente nas tabelas, os backups diferenciais poderão não ser a melhor solução. Se alguma página – e implicitamente, qualquer linha – dentro de uma extensão for alterada, o SQL Server deverá incluir toda a extensão no backup. (Uma extensão é de oito páginas contíguas, ou 64 KB.) Mesmo que uma porcentagem muito pequena dos dados seja alterada – em alguns casos, apenas 1% – você pode realmente estar fazendo backup de quase todas as extensões em uma tabela. Portanto, considere como seus dados são indexados, armazenados e modificados antes de assumir que você precisa de um backup diferencial.
8. Faça backup primeiro nos arquivos e depois na fita
Uma restrição comum nos backups do banco de dados é que eles devem ocorrer dentro de uma janela de tempo estreita. O backup em fita pode ser lento, embora alguns sistemas de fita mais novos ofereçam velocidades respeitáveis, e o backup distribuído pode ser extremamente rápido para uma matriz de fitas. Uma estratégia eficaz é primeiro fazer backup em um arquivo usando o processo de backup do SQL Server. Em seguida, você pode fazer backup dos arquivos em fita usando o software de backup que preferir. Para restaurar os dados, primeiro restaure os arquivos no local em disco e use o processo de restauração do SQL Server para recuperar o banco de dados.
9. Use Vários dispositivos de backup, especialmente se você fizer backup em fita
O SQL Server pode usar vários dispositivos de backup para distribuir o backup da mesma maneira que uma matriz RAID distribui dados por vários discos. Se o seu dispositivo de fita estiver criando um gargalo de backup, a adição de mais dispositivos poderá acelerar significativamente o processo de backup. Um backup que leva 6 horas em uma unidade de fita pode levar 2 horas quando três unidades estiverem funcionando simultaneamente. E o SQL Server pode restaurar a partir dessas três fitas de backup, usando apenas uma unidade, se necessário.
O backup em vários dispositivos também funciona para backups de arquivos. Se o seu arquivo de backup tiver 40 GB e você tiver apenas um conjunto de unidades de 20 GB, use vários arquivos em discos separados como destino do backup. Como alternativa, você pode criar um conjunto de volumes com o Windows ou mesmo um conjunto de faixas. Qualquer configuração forneceria uma unidade eficaz de 40 GB para o seu backup.
10. Teste seu plano
A hora de garantir que o processo de restauração funcione é agora, e não quando um desastre já ocorreu. Talvez você não consiga executar uma restauração em um servidor de produção, mas poderá restaurar a partir dos arquivos ou fitas de backup em um servidor de teste. Esse método de teste também pode ajudá-lo a verificar problemas com suas unidades de fita. A restauração das fitas em um sistema diferente, usando uma unidade diferente, verifica se as fitas estão legíveis em outra unidade. Teste seu plano e garanta que o processo de restauração funcione como deveria. Então, quando ocorrer um desastre, você estará pronto.
