Альтернативы сетевому резервному копированию

В нашей среде у нас есть несколько серверов, которые находятся в группе Always On Availability, а некоторые - автономные.

Обычно мы выполняем резервное копирование на общий сетевой ресурс, но недавно мы заметили, что по мере увеличения баз данных увеличивается время, которое затрачивается, что замедляет работу всей сети.

Скрипт Олы Халленгрена используется со сжатием, а также для разделения файлов резервных копий. Я выполняю только ежедневные «полные» резервные копии. Резервные копии отправляются на общий сетевой диск EMC isilon.

Я никогда не чувствую себя комфортно с EMC DD Boost. Единственная альтернатива - сделать локальное резервное копирование, а затем скопировать в тот же сетевой ресурс.

Есть ли эффективный способ, кроме вышеперечисленного?

Упомянутая вами альтернатива кажется лучшим выбором.

Что вы можете сделать, это двухэтапный процесс:

• Создавайте собственные резервные копии сервера SQL со сжатием, используя локальное решение для резервного копирования Ola.
• Используйте Robocopy для передачи в общий сетевой ресурс. Это разделено и может выполняться как запланированная задача Windows.

Таким образом, ваши резервные копии будут локальными, и они будут быстрыми. Вам потребуется больше места на диске и, очевидно, избыточность (что, если диск резервного копирования выйдет из строя - вы не хотите терять все свои резервные копии).

В качестве альтернативы, в соответствии с рекомендацией Макса Вернона, выполните Robocopy в качестве шага в задании резервного копирования, чтобы гарантировать, что роботоскопия происходит только в случае успешного завершения резервного копирования и как можно скорее после завершения резервного копирования. Резервное копирование находится на том же риске, что и данные, если оно остается локальным.

Кроме того, регулярно проверяйте ваши восстановления, так как, если вы не можете восстановить резервную копию - какой цели она служит!

Также, обратитесь к моему ответу на SQL Backup о настройке больших баз данных

Есть способы настроить резервное копирование, связавшись с различными регуляторами, такими как MAXTRANSFERSIZE или BUFFERCOUNT , или чередуя файл (который, как вы заметили, вы уже делаете).

Проблема в том, что прикосновение к этим ручкам может по-прежнему приводить к превышению ограничений вашей сети и / или хранилища, и это не оказывает реального влияния на время резервного копирования.

Ваша первая работа должна состоять в сравнении производительности хранилища, для которого вы выполняете резервное копирование, с помощью Crystal Disk Mark или DiskSpd . Это даст вам некоторое представление о том, как быстро вы можете ожидать, что записи будут в лучшем виде.

Следующее, что вам нужно проверить - это чтение с дисков, с которых вы выполняете резервное копирование. Если вы запустите резервное копирование в NUL , вы сможете определить , сколько времени займет только чтение части вашей резервной копии, без необходимости записи ее на диск.

Имея в виду оба этих числа, вы можете начать связываться с другими регуляторами, чтобы увидеть, какие из них вам ближе всего, независимо от того, является ли ваша цель резервного копирования локальной или сетевой.

Пара потенциальных решений:

1. Переход от полного только к еженедельному полному резервному копированию и ночной разнице может быть простым решением.

2. Существует ряд параметров, связанных с производительностью, которые вы можете настроить в скриптах Ola, вы можете настроить их, чтобы получить желаемую производительность:

   • BlockSize
     Укажите физический размер блока в байтах.

     Параметр BlockSize в DatabaseBackup использует BLOCKSIZEпараметр в команде SQL Server BACKUP.

   • BufferCount
     Укажите количество буферов ввода / вывода, которые будут использоваться для операции резервного копирования.

     Параметр BufferCount в DatabaseBackup использует BUFFERCOUNTпараметр в команде SQL Server BACKUP.

   • MaxTransferSize Укажите наибольшую единицу передачи в байтах для использования между SQL Server и носителем резервного копирования.

     Параметр MaxTransferSize в DatabaseBackup использует MAXTRANSFERSIZEпараметр в команде SQL Server BACKUP.

Существует много возможных вариантов, но поскольку базы данных становятся больше, а полное резервное копирование занимает больше времени, вам, вероятно, придется включить разностные резервные копии , если вы этого еще не сделали:

Создание разностных резервных копий может быть очень быстрым по сравнению с созданием полной резервной копии. Дифференциальная резервная копия записывает только данные, которые изменились с момента создания полной резервной копии при дифференциальной резервной копии. Это облегчает частое резервное копирование данных, что снижает риск потери данных.

Насколько я понимаю, сценарии Олы могут даже быть настроены на выбор между полной или дифференциальной резервной копией в зависимости от объема изменений в базе данных с использованием параметра ModificationLevel .

Мы используем EMC DD Boost, и вы можете прислушиваться к своему собственному мнению об этом, но мы выяснили, что благодаря используемым на стороне клиента методам дедупликации полное резервное копирование даже многотабайтных баз данных может быть очень быстрым, до такой степени, что нам не нужно беспокоиться о разностных резервных копиях SQL Server. В действительности с помощью EMC DD вы будете делать дифференциальное резервное копирование, но только не в SQL Server. Использование нескольких файлов назначения также значительно повышает скорость даже на DDBoost.