Как заметно увеличить скорость резервного копирования
Функция резервного копирования Time Machine и ее «сетевой брат» — Time Capsule, один из лучших продуктов, которые покидали стены офиса Apple в Купертино. С ее помощью процедура бэкапа превращается в невидимый и легкий процесс, но… медленный. Да, правда медленный. Резервное копирование Mac с занятыми 300 ГБ может занять день, а то и два. Но есть способ это исправить.
Откройте приложение «Терминал» на своем компьютере Mac, а затем введите команду ниже (после ввода пароля администратора, если он у вас установлен):
sudo sysctl debug.lowpri_throttle_enabled=0
Данная команда позволяет заметно ускорить процесс резервного копирования за счет регулирования отдельных параметров. К сожалению, работает она только до перезагрузки компьютера — потом все необходимо повторить заново.
Если хотите сохранить эту скорость, необходимо проделать процедуру ниже.
Откройте терминал и введите следующую команду:
sudo nano /Library/LaunchDaemons/nothrottle.plist
Откроется текстовый редактор, куда необходимо вставить следующее (текст здесь):
sudo chown root /Library/LaunchDaemons/nothrottle.plist;sudo launchctl load /Library/LaunchDaemons/nothrottle.plist
Готово! Даже после перезагрузки вы сможете наслаждаться высокой скоростью резервного копирования.
По материалам mackingfu
Новости, статьи и анонсы публикаций
Свободное общение и обсуждение материалов
Лонгриды для вас
Пользователи Apple Watch используют этот гаджет для разных целей: одни главным приемуществом видят уведомления из разных приложений, другие с помощью этого гаджета занимаются спортом. Всех их объединяет одно: кольца активности.
Циферблаты от Apple не отличаются большим количеством решений, но некоторые из них все же достойны нашего внимания. В статье расскажем о том, какие из них предпочитаем сами и поделимся способом загрузки новых вотчфэйсов на устройства от Apple.
Когда в AirPods попадает вода, пользователи в панике совершают множество опасных ошибок. Попадание влаги — проблема, с которой может столкнуться каждый владелец AirPods. Следуя инструкциям, указанным в статье, вы сможете повысить шанс на жизнь вашего устройства.
Как нам удалось увеличить скорость восстановления резервной копии в 20 раз
Как и всегда, сохраняя обратную совместимость мы увеличили скорость восстановления в 20 раз! Благодаря этому мы сделали внешнее восстановление очень надежным и быстрым процессом, на который вы можете рассчитывать. О том, как этого удалось добиться, рассказывает Product Owner & Solution Advisor Zextras Luca Arcara.
Процесс восстановления был разработан так, чтобы использовать как можно меньше ресурсов, чтобы сделать данный процесс фоновой операцией, которая не влияет на производительность службы. Однако со временем объем электронной почты изменился (размер почтовых ящиков пользователей растет, и пользователи хотят хранить в них всю электронную почту) в соответствии с общими спецификациями сервера (более мощный процессор и более быстрый диск).
Согласно отзывам наших клиентов, системным администраторам хотелось бы ускорить процесс, чтобы он мог использовать все доступные ресурсы.
Позвольте мне более подробно объяснить, как работает процесс восстановления и как мы достигли этой цели.
Как известно, резервная копия состоит из двух типов объектов:
Метаданные, которые описывают, как изменяются элементы (их статус, папки, в которых они находятся, их атрибуты)
БЛОБы, которые физически содержат двоичные данные объекта, другими словами, base64 EML.
Для больших двоичных объектов требуется большая часть хранилища, но зачастую именно метаданные больше всего влияют на производительность резервного копирования. Это связано с тем, что резервным копиям необходимо считывать состояния каждого элемента, декодировать метаданные, строить зависимости метаданных (например, ограничение папок), читать большой двоичный объект, добавлять элемент в хранилище почты пользователя и обновлять файл с маппингом.
Такой была настройка нашей тестовой среды:
6.7.0 Update 3 (Build 14320388)
Dell PowerEdge R440
Intel(R) Xeon(R) Silver 4208 CPU @ 2.10GHz
Параметры виртуальной машины:
140 gb – /dev/sda – EXT
100 gb – /dev/sdb – XFS
100 gb – /dev/sdc – XFS
100 gb – /dev/sdd – XFS
Linux Ubuntu 18.04.5 LTS
8.8.15.GA FOSS edition Patch 8.8.15_P19
Также для тестирования использовалось 2 бакета S3.
Один бакет S3 для централизованного хранения
Один бакет S3 для резервного копирования на внешнем хранилище
На виртуальной машине установлен агент Prometheus, отправляющий собранные данные на портал Grafana.
Сначала мы сделали упор на управление метаданными, заполнив сервер 15 000 000 небольших писем размером в несколько килобайт: в основном только текстовые сообщения. Этот сценарий был предназначен для создания огромного количества строк базы данных и файлов в резервной копии без превышения общей квоты.
После того, как сервер был заполнен, было выполнено глубокое сканирование, и все учетные записи и домен были удалены с исходного хоста. Состав резервной копии для тестового примера был следующим:
Число учетных записей
Затем созданная резервная копия была смонтирована под точкой монтирования /backup-to-restore.
Для ускорения восстановления были остановлены следующие службы: AntiVirus, AntiSpam, OpenDKIM.
Чтобы реализовать тестовую среду, аналогичную реальному варианту использования, все тома были ограничены 200 операциями ввода-вывода.
Для этого теста мы решили импортировать одну учетную запись с 270 000 писем: это в среднем соответствует пользователю с пятилетним стажем, который отправлял и получал более 100 писем каждый день.
Этот тест дает чёткое представление о том, как мы поменяли процесс.
Версия 3.1.10 меньше использовала ЦП, а также меньше операций ввода-вывода и пыталась добавить небольшое количество элементов для каждой одновременно восстанавливаемой учетной записи.
Версия 3.1.11 максимально быстро считывает данные резервных копий, добавляя кластеры сообщений так быстро, как это позволяет сервер, используя всю доступную память.
Как мы видим, узким местом является количество операций ввода-вывода в секунду для точки монтирования восстанавливаемой резервной копии.
Набор тестов был завершен за 2 часа 1 минуту 47 секунд по сравнению с 41 часом 6 минут 26 секунд в предыдущей версии.
Это примерно в 20 раз быстрее, даже если 3.1.10 немного замедлился из-за параллельного выполнения ночного смарт-сканирования и других запланированных задач.
В этом тесте мы снимаем все ограничения, чтобы обеспечить максимальную производительность хранилища.
Версия 3.1.10 не смогла пройти тест в течение 48 часов, что является ограничением по времени тестового примера. Все учетные записи были настроены, но через 48 часов после начала восстановления учетные записи из групп A и B все еще действуют.
Версия 3.1.11 завершила полное восстановление менее чем за 12 часов, в среднем 1200 операций ввода-вывода в секунду при чтении из исходной резервной копии и 600 операций ввода-вывода в секунду при записи в активный путь резервной копии.
Если убрать ограничения для дисков, статистика подскочила с 37 до 356 единиц в секунду (x10), в зависимости от увеличения IOPS (с 200 до 1800).
Также, глядя на статистику, вы можете увидеть, что последние 15 минут были интенсивными для ЦП, потому что на этом этапе резервное копирование заново выстраивает все общие ресурсы для восстановленных учетных записей.
Чтобы лучше понять связь между производительностью диска и скоростью резервного копирования, мы попытались восстановить по отдельности одну учетную запись из группы B и одну из группы A.
В отличие от предыдущего теста, скорость элементов упала до 213 элементов в секунду и 92 элементов в секунду. Частая сборка мусора и большая нагрузка на одну и ту же таблицу mysql вызвали интенсивную загрузку ЦП и замедлили весь процесс.
Мы можем заметить, что восстановление 1,5 млн элементов заняло менее 5 часов, в то время как для всего домена (около 15 млрд) потребовалось всего 12 часов.
Чтобы проверить нашу гипотезу, мы запускаем еще один импорт 85 учетных записей из групп B, C и D (7 миллиардов элементов), используя 50 одновременных операций, чтобы ограничить восстановление.
Очевидно, средняя нагрузка была выше, чем раньше, и SSD обеспечил в среднем 1800 операций ввода-вывода в секунду, но восстановление было завершено менее чем за 4 часа, в среднем 595 элементов в секунду. Это максимальная скорость, которую мы смогли достичь!
Дополнительные кейсы
В предыдущих тестах мы полностью сфокусировались на метаданных, потому что знаем, что они являются критическим фактором. Но на общую производительность также влияет скорость передачи или пропускная способность, доступная для БЛОБов
Чтобы завершить тесты, мы также дополнительно провели небольшой тестовый кейс, организованный следующим образом:
20 учетных записей
Более 1170 000 писем
Общий объем хранилища 60 ГБ
Мы настроили резервное копирование с использованием внешнего хранилища S3. Он использовал около 45 ГБ на S3 и 628 МБ на локальном диске метаданных (10% логического пространства).
Мы продолжили процесс восстановления по разным сценариям.
Полностью удаленный: после загрузки метаданных сервер считывает БЛОБы из удаленной резервной копии и использует удаленное централизованное хранилище в качестве основного тома.
Наполовину удаленный: после загрузки метаданных и БЛОБов сервер считывает данные локально и использует удаленное централизованное хранилище в качестве основного тома.
Локальный: после загрузки метаданных и БЛОБов сервер считывает данные локально и использует локальное хранилище в качестве основного тома.
1. Полностью удаленный:
Восстановление было выполнено с чтением метаданных с локального диска, а БЛОБ-объекты считывались непосредственно с S3. Также mariaDB находилась на локальном SSD, в то время как БЛОБы были записаны в централизованном хранилище S3.
В этой конфигурации все операции с метаданными выполнялись локально, а БЛОБ-объекты записывались и извлекались с использованием подключения к Интернету.
3.1.11 был в 1,2 раза быстрее предыдущей версии в управлении метаданными, но скорость передачи данных оказала огромное влияние на общую продолжительность.
2. Наполовину удаленный:
Восстановление было выполнено с чтением БЛОБ-объектов и метаданных с локального диска. В частности, резервная копия была подключена локально. По-прежнему mariaDB была расположена локально на SSD, а БЛОБ-объекты были записаны в централизованное хранилище S3.
В этой конфигурации все операции с метаданными выполнялись локально, а записанные БЛОБ-объекты извлекались с использованием подключения к Интернету.
3.1.11 был в 1,3 раза быстрее по сравнению с предыдущей версией в управлении метаданными, но скорость передачи по-прежнему влияла на общую продолжительность.
3. Локальный
Восстановление было выполнено с использованием локального диска как для метаданных, так и для БЛОБ-объектов. Оба были на SSD, однако всегда должна быть возможность перемещать данные с основного тома на HSM.
3.1.11 по итогам проведения всего процесса оказалась в 4 раза быстрее, чем предыдущая версия.
Мы постоянно работаем над улучшением нашего решения для резервного копирования и улучшением его производительности. Однако из-за того, что оно работает в реальном времени, производительность всегда строго связана с производительностью ввода-вывода.
По этой причине при масштабировании инфраструктуры вам следует подумать о:
Оперативной памяти и количестве операций ввода-вывода для метаданных MariaDB и Zextras
Скорости передачи и пропускной способности при резервировании BLOB-объектов для последовательного доступа
Количестве элементов для каждой учетной записи
Чтобы уменьшить объем хранилища, необходимый для метаданных, рассмотрите вариант «внешнего хранилища», который может уменьшить объем локального хранилища на 80%. Это сделает процесс восстановления более быстрым и надежным для сценариев миграции и восстановления.
Как ускорить медленное резервное копирование iPhone или iCloud
Прошло 36 с половиной часов, а моя резервная копия завершилась только на 78%.
Процесс резервного копирования или восстановления iTunes или iCloud занимает так много времени, что иногда вы просто отменяете его? Конечно, это может расстраивать и раздражать. Вот несколько советов, которые могут помочь вам ускорить процесс резервного копирования, синхронизации или восстановления в iTunes.
Удалите старые неиспользуемые приложения, в которых много данных.
Это означает, что у вас будет меньше данных для передачи во время каждого процесса резервного копирования или восстановления. Это действительно ускорит процесс. Ваш телефон не будет выполнять резервное копирование или восстановление приложений напрямую, но он будет выполнять резервное копирование и восстановление их данных. (Когда ваш телефон восстанавливается, приложения загружаются снова прямо из App Store, а не из вашей резервной копии.)
Удалите неиспользуемые медиафайлы с iPhone, iPad или iPod
Перенесите фотографии на компьютер или в библиотеку фотографий iCloud.
Создавайте регулярные резервные копии iTunes или iCloud
Резервные копии Apple отличаются друг от друга: каждый раз, когда вы выполняете резервное копирование, нужно добавлять только новое. Таким образом, чем чаще вы выполняете резервное копирование, тем быстрее это будет каждый раз. Если вы собираетесь очистить свои файлы, чтобы ускорить процесс резервного копирования iPhone, убедитесь, что вы сначала создали резервную копию и сохраните ее в безопасном месте за пределами папки iTunes по умолчанию.
Избегайте отправки отчетов о сбоях в Apple при каждой синхронизации iTunes
Отчеты о сбоях, отправляемые iTunes в Apple, могут увеличить время резервного копирования, поскольку iTunes необходимо сначала скопировать их и отправить до создания резервной копии. Чтобы iTunes не отправляла отчеты о сбоях и экономила время, вам следует:
Убедитесь, что вы используете правильное соединение
Если вы выберете резервное копирование с помощью iTunes через USB, стоит убедиться, что вы используете быстрое соединение. Если у вас Mac, все ваши USB-порты, скорее всего, будут очень быстрыми. Если вы используете компьютер с Windows, вам нужно использовать порт USB3, если он есть на вашем компьютере. Обычно это те, которые синие и встроены непосредственно в ваш компьютер или ноутбук. Порты на вашем мониторе, клавиатуре или концентраторе USB, вероятно, медленнее.
iPhone Backup Extractor может создавать резервные копии для вас
Ускорение резервного копирования БД
| Попытка | Сеть | Продолжительность |
| Обычным способом | Одна 1Gbps сетевая плата, конфигурация по умолчанию | >24 часов |
| Многопоточное резервирование по сети | 8x1Gbps сетевых плат, гигантский фрейм | 2 часа 25 минут |
| Многопоточное резервирование по сети со сжатием | 8x1Gbps сетевых плат, гигантский фрейм | 36 минут |
Таблица 1: Продолжительность резервирования 2Tб на сервер в 10 милях по сети
Сокращение времени резервного копирования
Есть два способа повышения скорости выполнения резервирования: оптимизация и распараллеливание.
Сначала давайте рассмотрим внутреннее устройство резервного копирования. Число потоков, обслуживающих резервное копирование, зависит от числа логических дисков – томов, используемых для файлов базы данных, и от числа устройств резервирования. Это – очень важно знать, потому что этот факт позволяет управлять степенью параллелизма резервного копирования. До сих пор мы опирались на ту схему размещения файлов, которая показана на рисунке ниже. Одним из способов повышения производительности этой схемы является увеличение числа дисков и размещаемых на разных дисках файлов, как это будет описано в следующем разделе.
Параллельное использование нескольких дисков и файлов.
Одним из подходов к повышению производительности является увеличение числа дисков и размещаемых на них файлов. Давайте посмотрим что получится, если добавить логические диски (отдельные LUN) для каждого из серверов, и разместить файлы базы данных и резервной копии на этих дополнительных логических дисках.
Ниже показана команда, которая выполняет резервное копирование в два файла.
Такое использование команды резервного копирования приводит к некоторому выигрышу в производительности, но не к четырехкратному её увеличению, которое можно было бы ожидать (двойной выигрыш при чтении плюс двойной выигрыш на записи). Чтобы полностью представить себе возможный выигрыш, нужно учесть пропускную способность сети.
Использование нескольких сетевых плат
При резервном копировании по сети узким местом часто становится сеть. Увеличение пропускной способности сети больше чем 1 Gbps недешево, однако увеличение числа гигабитных сетевых плат в сервере относительно недорогая опция.
Если для резервного копирования добавить две сетевые платы на сервере базы данных и две на файловом сервере, где резервная копия будет храниться.
Многие производители сетевого оборудования предлагают сегодня решения, позволяющие объединять несколько сетевых плат в один логический сетевой интерфейс. Это решение хорошо работает на серверах, имеющих сотни клиентских подключений из сети, это решение позволяет использовать алгоритмы балансировки нагрузки, в зависимости от того, какие клиенты работают с сервером. В нашем случае нужно увеличить скорость между двумя узкоспециализированными серверами. Для этого мы использовали разделение сети на логические подсети. В таблице ниже показаны подсети для каждой сетевой платы двух серверов.
| Сетевая плата | Сервер SQL01 | Сервер BAK01 |
| Access | 192.168.1.1 МАСКА 255.255.255.0 | 192.168.1.2 МАСКА 255.255.255.0 |
| Backup 01 | 192.168.2.1 МАСКА 255.255.255.0 | 192.168.2.2 МАСКА 255.255.255.0 |
| Backup 02 | 192.168.3.1 МАСКА 255.255.255.0 | 192.168.3.2 МАСКА 255.255.255.0 |
Каждая сетевая плата находится в своей подсети (192.168.1.0/24, 192.168.3. 0/24). Теперь можно внести небольшие изменения в команду резервного копирования, указав там IP – адреса вместо имён серверов. Таким способом становится легко управлять тем, какая подсеть, а, следовательно, и какая сетевая плата будет использоваться для транспортировки данных. Тот факт, что все логические подсети будут находиться на одном и том же втором физическом уровне сети, не будет иметь никакого отрицательного влияния на это решение.
В случае восстановления, это работает по той же схеме.
Точно также всё будет работать и с большим числом сетевых плат. В описываемых в статье экспериментах проверялась параллельная работа 16 сетевых плат.
Увеличение производительности будет наблюдаться и от передачи по сети нескольких файлов одновременно с помощью одной сетевой платы.
Эмпирическим путём было показано, что в зависимости от производительности используемых ресурсов (главным образом серверов и сетевых плат), от двух до четырёх файлов через одну сетевую плату передаются довольно хорошо. Однако, только тесты в конкретных условиях заказчика могут помочь найти оптимальное число передаваемых через сетевую плату файлов.
Рекомендации по общему числу используемых файлов
На основании результатов множества экспериментов, были выработаны рекомендации по оптимизации резервного копирования. Подспудно было также выяснено, что резервное копирование работало лучше в тех случаях, когда все ресурсы загружались равномерно. Для получения оптимальных результатов, все представленные ниже равенства должны выдерживаться. Уравнения перечислены в порядке их значимости, с представлением рекомендованных значений для n, которые выделены жирным шрифтом.
Файлы базы данных должны быть равномерно распределены по логическим дискам, а файлы резервных копий должны равномерно распределяться между сетевыми платами.
В Таблице 3 показаны примеры сбалансированного размещения файлов и использования дисков, которые обеспечивают хорошую производительность резервного копирования. Эти значения оптимальны только для повышения производительности резервного копирования. Подобного увеличения производительности ввода-вывода обычной базы данных не произойдёт, если вместо четырёх файлов данных, на одних и тех же логических дисках будет размещено восемь файлов данных.
В контексте представленных выше формул, можно выделить несколько примеров хороших сочетаний процессорных ядер, файлов, логических дисков и сетевых плат.
| Процес- сорные ядра | Логические диски для файлов данных | Сетевые платы для резервного копирования | Файлы данных | Файлы резервных копий |
| 2 | 1 | 1 | 2 | 2 |
| 4 | 2 | 2 | 2 | 4 |
| 4 | 4 | 2 | 4 | 4 |
| 8 | 2 | 2 | 2 | 8 |
| 8 | 4 | 2 | 4 | 8 |
| 16 | 2 | 2 | 8 | 8 |
| 16 | 4 | 4 | 8 | 8 |
| 16 | 4 | 4 | 16 | 16 |
| 16 | 8 | 4 | 16 | 16 |
| 32 | 8 | 4 | 16 | 16 |
| 32 | 8 | 8 | 16 | 32 |
| 32 | 16 | 8 | 16 | 32 |
| 64 | 16 | 8 | 32 | 32 |
| 64 | 32 | 16 | 32 | 64 |
Таблица 3: Сбалансированное распределение файлов по дискам
Дополнительные способы оптимизации и рекомендации
Разделение сетей для резервного копирования и общего доступа
Всегда можно рассчитывать на хороший эффект от разделения сети общего доступа и сети для резервного копирования по физически независимым, разным сетям. Из-за разной природы трафика сетей общего доступа и сети резервного копирования, коммутаторы не всегда могут оптимально обслуживать одновременно два этих вида трафика. Кроме того, для достижения высокой пропускной способности трафика резервного копирования часто требуется большая часть ресурсов коммутатора.
Вообще, всегда было хорошей практикой не выпускать большой трафик за пределы одного коммутатора (если коммутатор имеет несколько модулей, не выпускайте трафик за пределы одного модуля, если это возможно).
Большие фреймы
Максимальный размер пакета сети Ethernet в нормальных условиях составляет 15000 байт (равен размеру фрейма). Это означает то, что для передачи по сети 1 Мегабайта, его придётся разбить на 700 пакетов, которые будут переданы один за другим.
Сегодня можно приобрести такие сетевые платы и коммутаторы, которые поддерживают пакеты Ethernet с большими размерами фрейма. Для таких фреймов сетевых плат и коммутаторов даже существует специальное название – “jumbo frames“.
Чем больше размер фрейма, тем быстрее передача данных, потому что для обмена между серверами потребуется меньше итераций.
Наиболее распространёнными размерами больших фреймов являются величины около 4088 и 9016 Байт (включая заголовки Ethernet и большого фрейма). Например, если размер фрейма будет 9016 Байт, тогда для передачи 1 Мегабайта понадобится всего 117 пакетов.
Эмпирические исследования показали, что при увеличении размера фрейма до 9016 Байт, производительность сети практически удваивается.
BLOCKSIZE
Параметр, который задаёт используемый командой BACKUP размер блока, должен соответствовать размеру блока записи устройств долговременного хранения. Когда запись осуществляется на отдельный диск, будет работать достаточно хорошо даже используемое по умолчанию для размера блока значение равное 512. Если же запись направлена на RAID – массив или на SAN, стоит убедиться в том, что используемое по умолчанию значение не окажется меньше, чем, например, 65536.
При резервном копировании по сети нужно подобрать такое значение, которое бы позволило заполнять сетевые пакеты наиболее плотно. Имейте также в виду, что разбиение данных на пакеты работает в обоих направлениях. Выбор в качестве размера блока 512 Байт приведет к тому, что в сетевой пакет будет помещаться два блока (принимая во внимание то, что размер фрейма Ethernet равен 1500 Байт). Т.о. для передачи одной страницы базы данных понадобится 8 сетевых пакетов. С другой стороны, запись блоками по 4096 Байт будет помещаться в 3 сетевых пакета, а для передачи одной страницы базы данных понадобится 6 сетевых пакетов.
Можно привести ещё дополнительные примеры, полученные в результате проводимых при написании настоящей статьи тестов; при использовании больших фреймов размером 9016 Байт наилучшие результаты получались при размере блока 8192 Байт, а при использовании больших фреймов размером 4088 Байт, наилучшие результаты получались при размере блока 65536 Байт.
BUFFERCOUNT и MAXTRANSFERSIZE
Из параметров команды BACKUP можно выделить такие, которые также очень сильно влияют на производительность резервного копирования, это параметры BUFFERCOUNT и MAXTRANSFERSIZE. К сожалению, даже недели тестов не смогли помочь составить правило подбора оптимальных значений для этих параметров, поэтому Вам также необходимо будет выяснять оптимальные значения тестированием в Вашей среде. В качестве совета. для значения параметра MAXTRANSFERSIZE если у Вас система x64 или IA64 с достаточным объёмом оперативной памяти, можно начать тестирование со значения максимального размера буфера 4 Мб (4194304). Для получения более подробной информации о параметре BUFFERCOUNT и о других оптимизирующих параметрах, обратитесь к рекомендациям по настройке производительности сжатия резервных копий в технической статье: Tuning the Performance of Backup Compression in SQL Server 2008
В некоторых случаях, при проведении тестов для этой статьи, лучшие результаты получались при существенно меньших значениях параметров, но выбор значений был непредсказуем. Для промышленного применения стоит выполнить всестороннее тестирование разных вариантов, и убедиться, что лучшие результаты хорошо воспроизводятся. Если же нет возможности провести такую работу – лучше сохранить параметры по умолчанию.
Сжатие резервной копии
Сжатие резервных копий (новая функция, появившаяся в SQL Server 2008) предоставляет возможность увеличить производительность резервирования и в то же время существенно сократить потребляемое копией дисковое пространство, которое выделено для хранения резервных копий. Для включения сжатия резервной копии, в команде BACKUP нужно добавить опцию WITH COMPRESSION.
В представленном ниже примере запроса показано, как включить сжатие резервной копии.
Степень сжатия в действительности зависит от данных, которые хранятся в базе. Для большинства баз данных (цифровая информация, денежно-кредитные операции, дата и время, простой текст), коэффициент сжатия будет находиться между 1:4 и 1:6. Для баз данных содержащих некоторые другие типы данных, например, картинки, которые уже в сжатом формате, можно ожидать результаты похуже. Для получения более подробной информации об использовании сжатия с разными типами данных, смотрите статью в SQL Server Books Online: Сжатие резервных копий.
В проводимых для этой статьи тестах, наблюдалось сокращение времени резервного копирования с 125 до 36 минут, при сжатии файла на 20 процентов от первоначального размера.
У сжатия данных есть один недостаток- повышение утилизации процессорных ресурсов.
SQL Server производитт сжатие в одном потоке, который пишет данные в файл резервной копии, так что число файлов резервных копий определяется числом процессорных ядер, которые будут выполнять сжатие параллельно. Чтобы ограничить использование процессоров для резервного копирования, можно использовать Регулятор Ресурсов (Resource Governor), с помощью которого можно отдавать другим подключениям больше ресурсов.
Если используется прозрачное шифрование базы данных (TDE), не следует пытаться использовать для шифруемой базы ещё и сжатие, потому что зашифрованные данные сжиматься достаточно плохо. Если указание опции сжатия при формировании каждой команды резервного копирования неудобно, можно с помощью системной хранимой процедуры sp_configure установить автоматическое сжатие при создании всех резервных копий на сервере:
Тут следует быть осторожным, поскольку если сжатие включается на уровне всего сервера, оно будет применяться и для разностных копий и для копий журнала транзакций. И если повышенная утилизация процессоров из-за сжатия не будет проблемой для полных резервных копий (такие копии обычно не планируют на время пиковых нагрузок), использование сжатия копий журнала может вызвать проблемы во время активной работы пользователей.
Рекомендации по аппаратным средствам файловых серверов, предназначенных для хранения копий
Дисковые устройства
К дискам, используемым для хранения и проверки восстанавливаемости файлов резервных копий, не применяются такие же высокие требования, как к дискам промышленных серверов. Так происходит потому, что у них почти все операции ввода-вывода выполняются последовательно и не носят случайный характер. Поэтому SATA диски в большинстве случаев очень хорошо подходят для этих целей.
Настройка RAID-контроллера
Для создания массивов логических дисков, на которых решено хранить файлы резервных копий, стоит выбрать большой размер сегмента (64 Кб, 128 Кб, 256 Кб и выше). Также, стоит установить полное кэширование записи, а кэширование чтения можно полностью отключить. Можно ещё активизировать кэш записи отдельных шпинделей, так как если во время резервного копирования произойдёт сбой по питанию, резервная копия так и так станет непригодной, и в таком случае не имеет значения, были ли потеряны какие-либо байты в кэше записи или нет.
Для тех логических дисков, которые будут задействованы в пробном восстановлении базы из копии, размер сегмента устанавливается в 64 Кб, применяется политика 100-процентного кэширования записи, а кэширование чтения выставляется на 0 процентов.
Выбор уровня RAID (1, 10, 5, 6 …) зависит от возможностей используемого RAID-контроллера или используемой системы хранилища. Поскольку нагрузка на файловом сервере при резервном копировании/восстановлении является последовательной записью и чтением данных, контроллер будет кэшировать данные, пока он не закончит запись всего страйпа целиком, в этом случае можно использовать любой уровень RAID. Если контроллер ведёт себя по-другому, и производительность является критическим параметром, массивы RAID1 или RAID10 будут единственным возможным вариантом.
Настройка HBA
Сетевые платы
Следует очень разборчиво подходить к выбору сетевых плат, которые будут использоваться на серверах. Число портов ещё не гарантирует адекватную производительность ввода-вывода для всех этих портов в одно и то же время. Бывает так, что два четырехпортовых адаптера могут оказаться более производительными, чем один адаптер с четырьмя портами. Количество процессорного времени, используемого драйвером сетевого интерфейса, также очень важно. Бывают такие сетевые платы, которые используют до 50 процентов ресурсов одного процессора, и в то же время есть другие, которые используют всего 3 – 5 процентов.
Если для резервного копирования используется несколько сетевых плат, очень важно, чтобы они использовали разные процессоры, т.е. чтобы их прерывания были привязаны к разным процессорным ядрам.
Системы на основе NUMA
Если сервер использует архитектуру с неоднородным доступом к памяти (NUMA), необходимо убедится в том, что все адаптеры ввода-вывода (например, NIC, RAID и HBA) распределены между всеми NUMA – узлами системы.
Вычисление времени, необходимого для резервного копирования и восстановления базы данных
Одним из ключевых элементов SLA является тот интервал времени, который закладывается на задачи резервного копирования, т.е. нужно будет рассчитать и запланировать время, которое займёт весь этот процесс. Это поможет выполнить требования спецификации ко времени восстановления работоспособности, а также, это помогает сформировать другие важные моменты аварийного плана, такие как частота выполнения резервных копий и параметры сжатия. Определение времени, занимаемого процессами резервного копирования и восстановления, выполняется в несколько шагов. Вначале необходимо вычислить объём копируемых данных.
Далее, нужно определить максимальную продолжительность параллельного, последовательного чтения и записи используемых дисковых подсистем. Для того чтобы измерить эти значения при тестировании резервного копирования и восстановления, можно использовать системную утилиту Performance Monitor (известную ещё в некоторых версиях операционной системы Windows как System Monitor).
В результате, должно получиться 5 значений. Если имеется несколько логических дисков и сетевых плат, эти значения могут отличаться, и всегда нужно использовать самые худшие результаты вычислений.
После этого, опираясь на данные о числе логических дисков для параллельной работы с файлами базы данных, на число логических дисков, используемых для параллельной работы с файлами резервных копий и число используемых сетевых плат. Если сжатие не используется, это приведет к тому, что коэффициент сжатия станет таким: CompressionFactor = 1.
В большинстве случаев, без сжатия резервной копии производительность сети будет наименьшей по сравнению с производительностью дискового чтения и записи, но когда сжатие включено, основным ограничением может стать чтение из базы: DatabaseReadPerformance, или другие, не учтенные пока компоненты, такие как загруженные сжатием процессорные ядра.
Вычисления для расчета времени восстановления будут сложнее. Сначала нужно узнать, поддерживает ли используемая система мгновенную инициализацию файлов. Эта возможность позволяет SQL Server создавать файлы данных на томах NTFS без обнуления занимаемого файлами места во время создания или расширения файла. Поскольку у этого механизма существуют связанные с безопасностью риски, такой возможностью можно воспользоваться, только если учетной записи, под которой запущена служба SQL Server предоставить в локальных политиках право “Perform Volume Maintenance”. Если учетная запись пользователя входит в группу локальных администраторов, это право ей будет предоставлено по умолчанию (Примечание: время инициализации файла журнала транзакций может ограничивать производительность, так как занимаемое этим файлом место не может не заполняться нулями).
В случае если RestoreTime или BackupTime выше заданных SLA значений, можно воспользоваться изложенными ранее рекомендациями по уменьшению этих значений. Распараллеливание операций обычно ускоряет процесс больше чем попытка ускорить работу одного из компонент во всей цепочке. В сценариях с очень высокой производительностью стоит задуматься о применении обоих подходов.
Обратите внимание: на исполнение команды CHECKBD может потребоваться больше времени, чем время, которое необходимо для чтения с диска. Оно зависит от сложности схемы базы данных, и оно точно не будет меньше времени чтения.
Заключение
Microsoft и, непосредственно команда SQL Server постоянно совершенствуют технологии обеспечения живучести систем, которые призваны помочь клиентам и партнерам решать задачи резервного копирования и восстановления в масштабах предприятия. SQL Server 2008 обеспечен для этих задач всем необходимым функционалом, на который могут положиться специалисты и который помогает успешно справляться с присущими сегодняшнему дню требованиями по управлению и защите данных. За счёт усовершенствований в ключевых областях, SQL Server 2008 стал надёжной платформой для обслуживания очень больших баз данных.
Эта техническая статья предоставляет только краткий обзор возможностей резервного копирования и восстановления, а также некоторых функциональных возможностей SQL Server 2008.
