5 показателей эффективности корпоративного бэкапа
Выяснить, хорошо ли работают системы резервного копирования и восстановления, гораздо сложнее, чем просто знать, сколько времени занимает сам процесс бэкапа. Соответствие требованиям основных показателей является обязательным условием для правильной оценки вашей системы, чтобы определить, успешно ли она работает или нуждается в перепроектировании.
Вот пять показателей, которые каждая компания должна оценивать, чтобы гарантировать нормальную работу систем резервного копирования, отвечающих потребностям бизнеса.
1. Емкость хранилища
Давайте начнем с простого: имеет ли ваша система резервного копирования достаточно свободного места для удовлетворения ваших текущих и будущих потребностей в резервном копировании? Независимо от того, идет ли речь о ленточной библиотеке или массиве хранения данных, ваша СХД имеет конечную емкость, и вам нужно отслеживать, что это за емкость и какой процент ее вы используете с течением времени. Неспособность контролировать его может привести к тому, что вы будете вынуждены принимать решения, которые могут идти вразрез с политикой вашей компании, например, единственный способ создать дополнительную емкость, не покупая больше, - это удалить старые резервные копии. Было бы обидно, если бы неспособность контролировать емкость вашей системы хранения привела к невозможности выполнить требования по хранению, установленные вашей компанией.
Решением здесь может быть облачное хранение данных, поскольку некоторые службы предлагают практически неограниченную ёмкость для хранения архивных данных.
2. Пропускная способность
Каждая система хранения данных имеет возможность принимать определенный объем резервных копий в день, обычно измеряемый в мегабайтах в секунду или терабайтах в час. Вы должны знать об этой характеристике и следить за тем, как пропускная способность задействуется вашей системой резервного копирования. Невыполнение этого требования может привести к тому, что резервное копирование будет занимать все больше времени и растянется на весь рабочий день.
Особенно важен контроль пропускной способности при использования ленты. Очень важно, чтобы пропускная способность ваших резервных копий соответствовала возможностям вашего ленточного накопителя, в частности, пропускная способность, подаваемая на ленточный накопитель, не должна превышать его минимальную скорость. В документации к приводу, как правило указана максимальная и минимальная скорости, но всегда можно загуглить по запросу "minimal streaming speed". Маловероятно, что вы приблизитесь к максимальной скорости ленточного накопителя, но вы также должны следить за этим.
Диапазоны скорости ленточных накопителей (мегабайт в секунду):
- LTO 8: 360 -750
- LTO 7: 120 - 300
- LTO 6: 54 - 160
- LTO 5: 47 - 140
Маловероятно, что вы приблизитесь к максимальной скорости ленточного накопителя, но вы также должны следить за этим.
Резервные системы копирования на жёстких дисках не имеют порога минимальной производительности, а скорость резервного копирования зачастую ограничена интерфейсами и возможностями используемого ПО.
3. Вычислительная мощность
Возможности вашей системы резервного копирования также зависят от возможностей вычислительной системы, стоящей за ней. Если возможности обработки серверов резервного копирования или базы данных, лежащей в основе системы резервного копирования, не справляются, это также может замедлить работу резервных копий и привести к их утечке в рабочий день. Вы также должны следить за производительностью вашей системы резервного копирования, чтобы увидеть, в какой степени это происходит.
Особенно указанное имеет смысл, если задействуются такие ресурсоёмкие операции, как дедупликация данных на уровне ПО, отвечающего за резервное копирование. Вообще, дедупликация может дать огромную экономию, но лишь в том случае, когда анализу подвергаются исходные данные до того, как они были помещены в хранилище в виде архивов. В наших обзорах NAS-ов, ZFS (QNAP ES1640 и QSAN XN8012R) мы рассматривали возможности дедупликации на лету, реализуемой за счёт средств файловой системы и выяснили, что для подобных устройств лучше передавать на NAS данные в несжатом, оригинальном виде используя RSync.
Совершенно другая ситуация в случае, когда бэкапом централизованно управляет NAS за счёт собственного программного обеспечения, как например подробно рассмотренный нами Synology Active Backup for Business. Здесь такие ресурсоёмкие операции, как дедупликация, выполняются лишь для файлов резервных копий и пересчитываются при каждом копировании, а сжатие обеспечивает файловая система. Образно говоря, если вас беспокоит вычислительная мощность системы резервного копирования, то лучший способ - использовать современный NAS.
4. Временные рамки резервирования
Предыдущие две метрики очень важны, потому что они влияют на то, что мы называем окном резервного копирования: период времени, в течение которого разрешается выполнять резервное копирование. Если вы используете традиционную систему резервного копирования, где существует значительное влияние на производительность ваших основных сервисов во время бэкапа, вы должны заранее определиться с тем, что называется "окно резервного копирования". Если вы приближаетесь к заполнению всего окна, пришло время либо пересмотреть его, либо перепроектировать систему резервного копирования.
Проще говоря, окно резервного копирования - это тот промежуток времени, в течение которого одновременно допустимы:
- Снижение производительности или полная остановка сервисов
- Возросшая нагрузка на сеть
- Возросшая нагрузка на СХД
- Копируемые данные представляют собой наибольшую актуальность
Компаниям, использующим методы резервного копирования, которые относятся к категории продолжительно инкрементных, таких как CDP (Continous Data Protection) или непрерывная защита данных, "почти CDP", как правило, не нужно беспокоиться об окне резервного копирования. Это происходит потому, что резервные копии выполняются в течение очень коротких периодов времени и передают небольшой объем данных-процесс, который обычно оказывает очень низкое влияние на производительность основных систем. Именно поэтому клиенты, использующие такие системы, обычно выполняют резервное копирование в течение всего дня, а также один раз в час или даже каждые пять минут. Истинная система CDP фактически работает непрерывно, передавая каждый новый байт в резервное хранилище по мере его записи.
5.1 Время восстановления
Никто на самом деле не заботится о том, сколько времени вам потребуется для резервного копирования; все заботятся о том, сколько времени потребуется для восстановления. Время восстановления (RTO, Recovery Time Objective) - это количество времени, согласованное всеми сторонами, которое должно занять восстановление после какого-либо инцидента, требующего его. Длина приемлемого RTO для любой данной компании обычно определяется суммой денег, которую она потеряет в период, когда сервис не работают. Например, если компания будет терять миллионы долларов в час во время простоя, она, как правило, хочет максимально снизить RTO. Например, финансовые торговые компании стремятся свести RTO как можно ближе к нулю. Другие компании, для которых простой рабочего места или сервиса не критичен, могут измерять свой RTO в неделях. Важно то, что RTO соответствует бизнес-потребностям компании, а не то, у кого этот параметр меньше или больше.
Нет никакой необходимости иметь один общий RTO во всей компании: совершенно нормально и разумно иметь более жесткий RTO для более критичных приложений и RTO с большими допусками для остальной части центра обработки данных.
5.2 Точка Восстановления
Цель точки восстановления (RPO, Recovery Point Objective) - это величина допустимой потери данных после большого инцидента, измеряемая во времени. Например, если мы согласны с тем, что можем потерять один час данных, мы согласились на одночасовой RPO. Большинство компаний, однако, останавливаются на значениях, которые намного выше, например, 24 часа или более. Это происходит в первую очередь потому, что чем меньше ваш RPO, тем чаще вы должны запускать свою систему резервного копирования. Многие компании, возможно, и хотели бы иметь минимальный RPO, но с их имеющейся системой резервного копирования это просто невозможно. Как и в случае с RTO, совершенно нормально иметь несколько RPO по всей компании в зависимости от критичности различных наборов данных.
Параметры точки восстановления и времени восстановления измеряются только в том случае, когда происходит восстановление – будь то реальный инцидент или тестовый. RTO и RPO - это цели, но есть ещё параметры RPR и RTR, измеряющие степень, в которой вы достигли этих целей после восстановления. Важно измерить их и сравнить с заданными значениями RTO и RPO, чтобы понять, нужно ли вам рассмотреть возможность перепроектирования вашей системы резервного копирования и восстановления.
Реальность такова, что RPR и RTR большинства компаний далеко не совпадают с согласованными RTO и RPO, и что важно, так это пролить свет на эту реальность и признать ее. Либо мы скорректируем RTO и RPO, либо переработаем систему резервного копирования. Нет никакого смысла иметь жесткий RTO или RPO, если RTR и RPR от них отличаются.
Что делать с указанными параметрами
Одним из способов повышения доверия к системе резервного копирования является документирование и публикация всех упомянутых здесь показателей. Пусть ваше руководство знает, в какой степени ваша система резервного копирования работает так, как она задумана. Дайте им знать, исходя из текущих темпов роста, сколько времени пройдет, прежде чем им понадобится проводить модернизацию. И прежде всего убедитесь, что они знают о способности вашей системы резервного копирования и восстановления соответствовать вашим согласованным RTO и RPO. Сокрытие этого факта никому не принесет пользы, если произойдет сбой.
Рон Амадео
03/04.2020
