Alternativas ao backup em rede

Em nosso ambiente, temos alguns servidores que estão em um grupo Always On Availability e alguns que são independentes.

Normalmente, fazemos backup em um compartilhamento de rede, mas recentemente observamos que, à medida que os bancos de dados aumentam, o tempo gasto é cada vez maior, o que torna a rede inteira mais lenta.

O script de Ola hallengren está sendo usado com compactação e também dividindo os arquivos de backup. Estou executando apenas backups "completos" diários. Os backups vão para a unidade de compartilhamento de rede EMC isilon.

Nunca me sinto confortável com o EMC DD Boost. A única alternativa é fazer um backup local e copiá-lo para o mesmo compartilhamento de rede.

Existe uma maneira eficiente diferente da acima?

A alternativa que você mencionou parece ser a melhor escolha.

O que você pode fazer é um processo de duas etapas:

• Faça backups nativos do servidor sql com compactação usando a solução de backup do Ola localmente.
• Use Robocopy para fazer as transferências para um compartilhamento de rede. Isso é dissociado e pode ser executado como uma tarefa agendada do Windows.

Dessa forma, seus backups são locais e serão rápidos. Você precisará de mais espaço em disco e, obviamente, de redundância (e se o disco de backup falhar - você não deseja perder todos os seus backups).

Como alternativa, conforme recomendado por Max Vernon, faça o Robocopy como uma etapa da tarefa de backup para garantir que a robocópia ocorra apenas se o backup for concluído com êxito e o mais rápido possível após a conclusão do backup. O backup corre o mesmo risco que os dados, desde que permaneça local.

Além disso, teste regularmente suas restaurações, pois se você não conseguir restaurar um backup - para que serve isso!

Além disso, consulte minha resposta ao SQL Backup, ajustando bancos de dados grandes

Existem maneiras de ajustar os backups mexendo com botões diferentes, como MAXTRANSFERSIZE ou BUFFERCOUNT , ou removendo o arquivo (o que você notou que já está fazendo).

O problema é que tocar nesses botões ainda pode atingir os limites da sua rede e / ou armazenamento e não ter nenhum impacto real no tempo de backup.

Seu primeiro trabalho deve ser comparar o armazenamento que você faz backup usando o Crystal Disk Mark ou o DiskSpd . Isso lhe dará uma idéia de quão rápido você pode esperar que as gravações sejam as melhores.

A próxima coisa que você precisa testar é ler as unidades das quais você está fazendo backup. Se você executar um backup no NUL , poderá determinar quanto tempo leva apenas a parte de leitura do seu backup, sem precisar gravá-lo no disco.

Com esses dois números em mente, você pode começar a mexer com outros botões para ver quais os aproximam deles, independentemente de seu destino de backup ser local ou em rede.

Algumas soluções em potencial:

1. Passar de backup completo somente para backup completo semanal e diferencial noturno pode ser uma solução fácil.

2. Há vários parâmetros relacionados ao desempenho que você pode ajustar nos scripts do Ola; talvez seja possível ajustá-los para obter o desempenho desejado:

   • Tamanho
     do bloco Especifique o tamanho do bloco físico em bytes.

     A opção BlockSize no DatabaseBackup usa a BLOCKSIZEopção no comando BACKUP do SQL Server.

   • BufferCount
     Especifique o número de buffers de E / S a serem utilizados para a operação de backup.

     A opção BufferCount no DatabaseBackup usa a BUFFERCOUNTopção no BACKUPcomando SQL Server .

   • MaxTransferSize Especifique a maior unidade de transferência, em bytes, a ser usada entre o SQL Server e a mídia de backup.

     A opção MaxTransferSize no DatabaseBackup usa a MAXTRANSFERSIZEopção no BACKUPcomando do SQL Server .

Existem muitas opções possíveis, mas à medida que os bancos de dados ficam maiores e os backups completos demoram mais, você provavelmente precisará incorporar backups diferenciais , se ainda não o tiver:

Criar um backup diferencial pode ser muito rápido em comparação com a criação de um backup completo. Um backup diferencial registra apenas os dados que foram alterados desde que o backup completo no backup diferencial se baseia. Isso facilita a realização de backups de dados frequentes, o que diminui o risco de perda de dados.

Meu entendimento é que os scripts do Ola podem até ser configurados para decidir entre um backup completo ou diferencial com base na quantidade de alterações no banco de dados usando o parâmetro ModificationLevel .

Usamos o EMC DD Boost e você é bem-vindo da sua opinião, mas descobrimos, devido aos métodos de deduplicação do lado do cliente que ele usa, que os backups completos de bancos de dados com várias TB podem ser muito rápidos, a tal ponto que não precisamos nos preocupar com backups diferenciais do SQL Server. Com efeito, usando o EMC DD, você está fazendo backups diferenciais, mas não no SQL Server. O uso de vários arquivos de destino também melhora bastante a velocidade, mesmo no DDBoost.