Увы, резервное копирование не всегда происходит быстро. На скорость создания копии влияют десятки факторов, и из-за этого часто страдают бизнес-процессы, снижается производительность, а главное — данные остаются незащищенными. Сегодня я расскажу о том, как можно ускорить резервное копирование, устранив одно или несколько “узких мест” в архитектуре. Если вы задаетесь вопросом, оптимально ли настроено резервное копирование, вас не устраивает скорость создания резервных копий, либо данные вовсе не успевают перемещаться в заданные хранилища, то добро пожаловать под кат! Обсудим, что с этим можно сделать.
Привет, Хабр! Меня зовут Дмитрий Ермолаев, и я руковожу технической поддержкой в компании “Киберпротект”. И хотя в большей степени опыт нашей команды относится к продукту Кибер Бэкап, практически все советы можно применить и к другим системам резервного копирования, ведь фактически скоростному созданию аварийной копии мешают одни и те же факторы. Возможно, какие-то из пунктов покажутся вам очевидными — и это значит, что вы уже не новичок в работе с резервным копированием. Но сотни обращений в нашу техподдержку по этим вопросам подтверждают, что многие просто устанавливают систему “из коробки” и не в курсе, как именно улучшить процессы резервного копирования.
1. Бэкапить блоки, даже если нужны файлы
Резервное копирование можно настроить на различных уровнях. Так, можно бэкапить один и тот же диск файлами или блоками. Но при работе с файлами агент резервного копирования обращается к диску через интерфейс файловой системы. И если у вас действительно много файлов, этот процесс может оказаться трудоемким и ресурсоемким. В итоге резервная копия создается долго.
Решить эту проблему можно сменив тип резервного копирования на блочный (работа на уровне диска или тома). В таком случае СРК забирает информацию непосредственно с диска, процесс идет быстрее. При этом в большинстве современных инструментов резервного копирования даже при блочном бэкапе можно задать исключения при создании копии, а также восстанавливать отдельные папки и файлы впоследствии. Так что мы практически ничего не теряем, сменив режим резервного копирования. А прирост скорости может быть весьма ощутимым. Например, в Кибер Бэкапе подобный выбор выглядит следующим образом.
2. Использовать инкрементное резервное копирование
Полная резервная копия — это хорошо. Но в некоторых случаях она делается очень долго. Часто смена настройки СРК с полной на инкрементную копию позволяет значительно увеличить скорость выполнения задач, потому что в резервную копию добавляются только новые данные. Особенно в тех случаях, когда изменения за рабочий день невелики, инкрементный бэкап позволяет ускорить резервное копирование, сохранив тот же уровень защиты.
Тут, конечно, можно возразить, что инкрементный бэкап сложнее и отнимает ресурсы ЦП для создания образов и их последующего восстановления. Но, как показывает практика, уровень дополнительной нагрузки на процессор обычно не превышает 1%. Так что инкрементный бэкап стоит свеч в 90% случаев и позволяет ускорить РК. Например, в Кибер Бэкапе можно просто включить опцию “всегда инкрементное” для уже настроенных или новых планов резервного копирования. Эта схема раскрывает потенциал работы специального формата резервных копий “Киберпротекта” и в результате дает одновременно эффективную дедупликацию и сжатие, а также высокие скорости восстановления даже при длине цепочки 100+ точек. Как она работает я подробнее расскажу в отдельном посте.
3. Оптимизировать файловую систему
Если вы уже выбрали том для размещения резервной копии, система резервного копирования будет вынуждена работать с тем, что есть. И если не задаться вопросом, какие характеристики файловой системы лучше подойдут для резервного копирования, можно потерять в производительности.
Дело в том, что файлы резервной копии — это крупные образы или архивы, они могут достигать тысяч гигабайт…ну или хотя бы десятков. И для их размещения лучше всего использовать файловую систему с максимальным размером кластера. Такой подход уменьшает фрагментацию данных в файловой системе и приводит к тому, что при работе с резервной копией дисковая подсистема может выполнить большее количество последовательных операций чтения или записи. К тому же со временем такие тома меньше деградируют в производительности, даже если фрагментация начинает расти по естественным причинам.
Кстати, если ваши резервные копии реально большие, а диск или том используется только для этой задачи, можно столкнуться с ограничением файловой системы на максимальное количество сегментов файла (~1,5 миллионов). Достаточно запустить параллельное резервное копирование 2-3 виртуальных машин с образами, скажем, по 500ГБ, и на томе NTFS с размером кластера 4 кб (по умолчанию) возникнут проблемы с дальнейшим расширением скопированных образов.
4. Использовать резервное копирование на уровне гипервизора
Самый простой и прозрачный способ защитить виртуальные машины — установить на них средства резервного копирования, как на физические ПК. Такой подход будет работать, но при резервном копировании агент будет использовать ресурсы операционной системы той виртуальной машины, внутри которой он работает. В этом случае мы сталкиваемся с проблемой разделения ресурсов между пользовательскими нагрузками и работой СРК. Наиболее ярко снижение скорости резервного копирования наблюдается на ВМ с минимальными ресурсами. Да и пользователям не очень нравится, когда рабочее место начинает тормозить.
Решить эту проблему можно за счет интеграции СРК и гипервизора. В этом случае на виртуальных машинах не устанавливаются отдельные агенты, а СРК производит резервное копирование извне, используя свободные ресурсы кластера. В результате никакого снижения производительности не происходит. А учитывая, что все больше СРК поддерживают широкий спектр гипервизоров, подобный подход оправдывает себя полностью. Мы тоже работаем с разными гипервизорами — от VMware и oVirt до российских разработок, таких как ECP VeiL или РЭД Виртуализация. Кстати, работа по тестированию и устранению багов в таких связках была проведена нешуточная, и мои коллеги обязательно расскажут об этом в блоге в ближайшее время.
5. Развести процессы резервного копирования ВМ по времени
Технически можно запустить резервное копирование нескольких виртуальных машин одновременно. Например, в Кибер Бэкап 15 их количество достигает 10 штук на одного агента. Это удобно, если у вас сотни мелких виртуальных машин. Но если под такую схему попадают крупные и тяжелые образы, могут возникнуть проблемы вплоть до деградации производительности всего кластера и гипервизора в целом.
Тут очень важно не намудрить и последить за метриками. Справляется ли ваша система (физическая или виртуальная) с текущей бэкап-нагрузкой. Для этого целесообразно использовать простой системный монитор. Например, вот такой.
Может оказаться так, что нормальный такой двухпроцессорный сервер с 500 Гбайт ОЗУ не тянет сразу несколько процессов резервных копий…потому что они попадают на медленные накопители, которые не справляются с потоком операций ввода/вывода. В этом случае можно настроить план резервного копирования и развести операции по времени — и волки сыты, и апгрейдить сервер по конским ценам не нужно.
6. Минимизируйте нагрузку на сеть
Впрочем, не всегда накопители оказываются лимитирующим фактором для резервного копирования. Если диски, на которые в конечном счете попадает копия, находятся на другой машине, передача данных происходит по сети. И сеть,естественно, может создавать свои препятствия для быстрой передачи данных, особенно если параллельно по ней передается немало бизнес-трафика, поддерживающего продуктивные процессы.
Для того, чтобы нагрузка на сеть стала меньше, можно использовать сжатие и дедупликацию данных. Практически все современные СРК это поддерживают, но не все пользователи знают, что сетевая папка для успешной работы алгоритмов оптимизации должна соответствовать определенным требованиям. Например, в Кибер Бэкапе необходимо использовать сетевую папку с версией протокола SMB 2.1 (а лучше 3.1+), чтобы сжатие и дедупликация работали автоматом и на лету. Тогда неуникальные фрагменты информации не будут даже попадать на сетевой адаптер.
7. Или вообще не используйте сеть
Когда речь идет о гиперконвергентных системах и программно-определяемых хранилищах, нередко для их работы используется отдельная сеть и адаптеры, потому что постоянное перемещение данных создает большую нагрузку и замедляет основную ЛВС. В высоконагруженных средах резервное копирование тоже является нежелательным в сети, и поэтому лучше всего избежать передачи данных с одного сервера на другой.
Сделать это очень просто — достаточно подключить дисковый массив или даже сервер резервного копирования непосредственно к тому серверу или кластеру, который вы защищаете. При этом никто не отменяет централизованный контроль и управление процессом резервного копирования. Например, сервер Кибер Бэкап может координировать работу агентов, которые при этом ведут копирование без использования сети.
В системах виртуализации работает та же логика. Например, если вы используете устройство SAN для хранения датасторов ВМ, достаточно выделить свободный сервер (можно не очень мощный, который не так важен в продуктиве) и подключить его к этому же SAN через FibreChannel. В результате получится резервное копирование виртуальных машин, без использования сети.
Работает такая схема надежно. Мы неоднократно тестировали ее в разных средах виртуализации, в том числе c VMware. На сервере просто устанавливается ОС Windows и агент бэкапа WMware. После этого на него отправляются LUN, на которых находятся датасторы хостов ESXi.
Подключенные LUN не инициализируются в ОС и не используются на запись. Но в момент резервного копирования, после создания снимка виртуальной машины, агент обращается к презентованным ему дискам SAN, забирает из них данные дисков виртуальных машин и сохраняет резервную копию на свои локальные диски.
8. Выделить больше ресурсов для Virtual Appliance агентов для VMware.
Раз уж мы заговорили о виртуализации и VMware, нельзя не упомянуть такой простой метод ускорения, как увеличение производительности виртуальных устройств, который актуален также для oVirt, ECP Veil, Кибер Инфраструктуры и некоторых других. По умолчанию агенты для резервного копирования в экосистеме VMware создаются как двухъядерные виртуальные машины с 4 Гигабайтами оперативной памяти. И, что интересно, увеличение количества памяти до 8-10 ГБ ведет к серьезному росту производительности бэкапа. А если нагрузка сложная и данные требуют тщательной дедупликации и сжатия, можно также накинуть и количества ядер.
Подобный ход оправдан в крупных инфраструктурах. А насколько именно увеличивать параметры, помогает определить системный монитор. Таким образом, проводя тонкую настройку мощности ВМ с агентом СРК можно и производительность увеличить, и лишних ресурсов практически не потратить.
9. Отключить многотомные снимки VSS
Многотомные моментальные снимки VSS — полезная штука. Они позволяют синхронизировать данные между всеми томам на компьютере, создавая теневую копию. Такой подход активно используется для работы с тяжелыми и ответственными инфраструктурами, например часто применяется для СУБД Oracle. Но проблема в том, что синхронизация приводит к тому, что работа с дисками происходит одновременно, а не последовательно.
Если вам не критична синхронизация состояния данных на томах, то эту опцию можно отключить. Это поможет снять нагрузку на операционную систему и диски. В этом случае теневые копии на томах будут создаваться последовательно, а общая производительность процесса резервного копирования вырастет, если узким местом была именно производительность дисков.
Заключение
Все разработчики (и мы в том числе) стремятся сделать резервное копирование простым коробочным продуктом. И это во многом получается. Например, сегодня можно просто взять и установить СРК не только на Windows или в экосистеме VMware, но и на операционные системы из реестра российского ПО или на отечественные системы виртуализации. И все будет работать без дополнительного обращения в техподдержку. Однако вопросы тонкой настройки остаются актуальными, и нередко одно из приведенных выше 9 правил позволяет ускорить резервное копирование.
Не буду спорить, эта задача вообще не всегда актуальна. Если объем защищаемых данных невелик, а ресурсов в системе достаточно, можно обойтись вообще без оптимизаций. Но если скорость стала снижаться, и это влияет на время создания копий (не удается перенести данные за нужный промежуток времени) или на работу пользователей (тормозят основные процессы), стоит попробовать и ускорить РК, какой бы системой вы ни пользовались.
