Резервное копирование сервера sql очень медленное

Чтобы добавить немного и обобщить другие ответы:

• Использование сжатия ускорит резервное копирование (которое сначала считывается, а затем записывается - уменьшите «напишите», и вы ускорите процесс), но за счет некоторого дополнительного процессора. Вы можете объединить сжатие резервных копий с регулятором ресурсов в 2008 году, чтобы ограничить это. Использование сжатия также ускоряет восстановление (прочтите что-то, а затем напишите еще раз), что может быть фантастическим для сокращения времени простоя в ситуации аварийного восстановления.
• Не использовать один и тот же диск для файлов базы данных и резервных копий. Помимо проблем с конкуренцией (которые будут различаться в зависимости от подсистемы ввода-вывода), это катастрофа в процессе создания. Худший случай потери данных, который я когда-либо видел, был, когда сторонний техник случайно отформатировал диск, на котором была база данных И единственные резервные копии на нем.
• Использование чередующегося резервного набора. Если вы можете выполнить резервное копирование базы данных в несколько файлов резервных копий, то операции ввода-вывода будут циклически перемещаться по файлам резервных копий. Если у вас есть файлы резервных копий в отдельном хранилище, вы можете массивный прирост производительности.
• Настройте некоторые из более сложных параметров, таких как BLOCKSIZE, MAXTRANSFERSIZE, BUFFERCOUNT

Самые быстрые резервные копии, которые я когда-либо видел, есть у нашего клиента, Bwin, в Вене. Они могут сделать резервную копию 2 ТБ за 36 минут. См. Мое сообщение в блоге об этом на Высококачественные показатели сжатия резервных копий.

Посмотри на этот SQLCAT PDF, в частности:

• Раздел 4, Страница 71: Настройка производительности сжатия резервных копий в SQL Server 2008
• Раздел 1, Страница 15: Настройка сжатия резервных копий, часть 2

Надеюсь это поможет!

Вы очищали MSDB в последнее время? Хорошая статья Брента Озара о том, какие разветвления это имеет для вашей базы данных и резервных копий

http://www.brentozar.com/archive/2009/05/brents-backup-bottleneck-msdb/

Какая версия SQL-сервера у вас установлена? 2008 может выполнять резервное копирование со сжатием, что может значительно увеличить скорость резервного копирования. Резервное копирование одного из моих клиентов длилось от часа до 10 минут после того, как мы включили сжатие в задании резервного копирования.

Находится ли физический файл вашей базы данных (.MDF / .NDF) на том же диске, что и резервная копия? Если это так, диск пытается одновременно прочитать базу данных и записать резервную копию. Резервное копирование на отдельный независимый диск должно помочь.

Также возможно, что есть проблема с нижележащим диском (дисками) - попросите инженера по хранению проверить целостность диска (ов).

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

Как быстро происходит восстановление?

Лучший способ улучшить это - использовать стороннюю утилиту резервного копирования, например LiteSpeed ​​от Quest или SQLBackup от Red Gate.

Тем не менее, как часто вы выполняете полные резервные копии? Вы реализовали дифференциальное резервное копирование и резервное копирование журналов транзакций?

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

Не то чтобы я рекомендовал это, если вы отключите опцию проверки, это значительно сократит время. Я бы сделал это только с резервными копиями, которые копируются на резервные машины и восстанавливаются, чтобы вы знали, что у вас плохая резервная копия.

Я бы определенно выбрал решение Пола Рэндала. Однако я бы проверил, велика ли история резервного копирования msdb, как сказал SQLChicken. И если бы вы работали с SQL 2008, я бы использовал сжатие резервных копий, так как это круто. Не знаю, поможет ли в этом Instant File Initialization. Но тоже попробовал бы. (тестирование делает совершенство)

Используйте флаг трассировки (3605,3213), чтобы сохранить подробную информацию в журнале ошибок.

DBCC TRACEOFF(3605, –1)
DBCC TRACEOFF(3213, –1)

Чтобы оценить и проверить, насколько быстро вы можете читать данные из базы данных или файловой группы, есть специальная опция, которую вы можете использовать для резервного копирования в: DISK = 'NUL'

При использовании 1222,1204 тупик будет записываться в журнал ошибок.