Задний план: Мне нужно пересмотреть / улучшить автоматизированный процесс, который я создал пару лет назад на группе серверов. Процесс идет следующим образом:
Технически этот процесс работает, но размер и количество баз данных с годами выросли до 70–100 ГБ. Этот процесс выполняется ежедневно, и его следует переключить на использование дифференциальных резервных копий, чтобы уменьшить объем задействованных данных; пока он выполняет полное резервное копирование.
Проблема: Проблема, с которой я столкнулся, заключается в том, сколько времени требуется 7zip для сжатия такого огромного количества данных. 7zip требуется около 14 часов, чтобы сжать все эти базы данных в один файл .7z. Рассматриваемый сервер представляет собой двухъядерный 64-разрядный компьютер W2008R2 с оперативной памятью 16 ГБ, на котором также размещается SQL-сервер для веб-приложения примерно для 300-500 пользователей. Что касается конкретно 7zip, мы настроили его на максимальное сжатие (ultra / level 9).
Риск заключается в том, что 7zip потребляет слишком много мощности процессора в часы пик для наших пользователей, поэтому производительность SQL оказывается под угрозой.
Вопрос: Доступна ли утилита сжатия для Windows, которую можно использовать для сжатия резервных копий базы данных SQL, которая будет выполнять процесс быстрее (~ 80 ГБ менее чем за 14 часов) или потреблять меньше ресурсов ЦП, чем 7zip?
По большей части вы всегда будете жертвовать скоростью на сжатие. Простое уменьшение сжатия или выбор менее эффективного алгоритма ускорит этот процесс. Определенно не существует волшебной пули, которая обеспечивает одновременно отличное сжатие и большую скорость.
Вы можете использовать собственное сжатие резервных копий Sql Server, но это также увеличит загрузку ЦП.
Сделайте резервную копию непосредственно на общий диск с сервера B, а затем используйте сервер B для сжатия. В качестве альтернативы можно предоставить общий доступ к диску из A и использовать сервер B для сжатия перед копированием файла на B.
Или сделайте резервные копии из вторичной базы данных (которая имеет доставку журналов из первичной базы данных). Предположительно у вас еще нет вторичной базы данных, но если вы делаете ежедневные полные резервные копии, то это, вероятно, достаточно важно, чтобы это рассмотреть. Настройте доставку журналов от первичного к вторичному и делайте резервные копии с вторичного, в то время как все ваши пользователи продолжают использовать первичную базу данных и, таким образом, их производительность не снижается, пока вы делаете (сжатые) резервные копии.
В краткосрочной перспективе используйте сжатие более низкого уровня с помощью 7zip, но это не постоянное решение.
Я использую командную строку 7zip, 7za для сжатия файлов базы данных размером 55 ГБ с использованием алгоритма bzip2 и формата zip. Сжатый файл составляет 5,5 ГБ, сервер использует 2 процессора 4core E5520 2,27 ГГц, а время сжатия составляет менее 2 часов.
7za a -tzip -mm=BZip2 <destination file> <source dir>