 |
|
|
|
Почему нельзя просто скопировать файлы. О резервном копировании, а также об инкрементальном парадоксе
Почему нельзя просто скопировать файлы Вряд ли можно найти профессионала в области ИТ, который бы стал отрицать необходимость всегда иметь надежную актуальную резервную копию. Но никто не спорит, что гораздо надежнее иметь две копии! Например, за вчера и за сегодня. А еще лучше иметь целый архив за требуемый период Зачем все так усложнять, если нужно просто сохранить данные? Если требования достаточно серьезные, то резервное копирование превращается в весьма недешевое удовольствие. И дело не только в стоимости носителей данных для хранения, специфического программного обеспечения для резервного копирования на профессиональном уровне. Сам по себе процесс резервного копирования способен создавать весьма внушительную нагрузку на ИТ-инфраструктуру. (Об этом рассказывается в статье «Не теряя управления» [1].) Поэтому крайне важно максимально оптимизировать сам процесс выборки, передачи и хранения данных. Это нужно, во-первых, для того, чтобы попадать в так называемое окно бэкапа (когда ИТ-инфраструктура испытывает минимальную нагрузку и можно выполнять массовое копирование без риска кому-то сильно помешать), и, во-вторых, чтобы не хранить колоссальные объемы не особо нужной информации, тратя на это деньги, человеческие ресурсы для обслуживания таких «хранилищ» и так далее. Любая система резервного копирования – это уникальная экосистема, которая при неправильном подходе из ангела-хранителя превращается в прожорливого монстра, проедающего денежные и людские ресурсы и в итоге не приносящего ничего, кроме головной боли. Планирование работы системы резервного копирования Вот тут и начинается самое интригующее. Как оно обычно бывает: посидели на совещании, обозначили, какие данные нужно копировать, разошлись по кабинетам, подсчитали приблизительный объем и время на создание копии, и стало ясно, что при прямолинейном подходе «сохранять все нужное на неопределенный срок» не получится никогда. Прежде чем создавать систему сохранения данных, необходимо выяснить критерии ее эффективной работы и сопоставить их с возможными материальными и временными затратами. Вот несколько характеристик, которые влияют на эффективность резервного копирования:
Остановимся по порядку на каждом пункте. Глубина хранения данных – это период, за который хранятся резервные копии. В предыдущих своих работах я писал о необходимости четко разграничивать резервное копирование, выполняемое в целях создания архива, и резервное копирование для последующего быстрого восстановления системы (Disaster recovery). Но любой архив имеет замечательное свойство увеличиваться в размерах: чем дольше срок, за который собирались и поступали на хранение данные, тем больше размер архива. Если хранить абсолютно все копии начиная со дня основания компании, то тут никакого бюджета не хватит – все уйдет на покупку средств хранения и на оплату услуг по обслуживанию такого «монстра». Поэтому разумное решение в данном случае – ограничить срок хранения некими рамками, что и называется глубиной хранения. Ограничение времени создания резервной копии. Создание резервной копии – процесс достаточно ресурсоемкий. Нельзя просто взять и запустить копирование большого объема данных, не согласовав свои действия с другими участниками бизнес-процесса. Мало того, довольно часто возникает ситуация, когда также нельзя запросто прервать процесс резервного копирования. Поэтому временные ограничения на создание резервной копии являются одним из решающих факторов при проектировании системы резервного копирования. Ограничение объема, наверное, не нуждается в детальном описании. Рано или поздно любой ИТ-специалист сталкивается с дефицитом дискового пространства или нехваткой съемных носителей для хранения большого объема данных. При этом проблема часто заключается даже не в отсутствии денежных средств на приобретение нового оборудования, а в необходимости кардинальной реконструкции всей инфраструктуры или хотя бы одного из ее фрагментов. При этом имеющееся оборудование может быть уже не востребовано. Хороший пример: переход на новую версию LTO для системы ленточных библиотек, при которой может потребоваться замена аппаратного обеспечения, картриджей LTO и установка дисковой подсистемы для кэширования большего объема данных. Поэтому ситуация «надо сохранить, да некуда» встречается довольно часто и не несет с собой ничего хорошего. Ограничение времени восстановления. Этой немаловажной характеристике работы системы резервного копирования, как правило, уделяется меньше всего внимания. Обычная практика при проектировании систем сохранения данных: «Главное, чтобы проверенная актуальная копия имелась в наличии (!), а сколько времени потребуется на ее восстановление – это уже не так важно». К сожалению, имеются грустные основания для подобного подхода – во многих российских компаниях резервное копирование до сих пор рассматривается как нечто не слишком обязательное, и ИТ-специалисты не склонны уделять вопросам сохранения данных слишком пристальное внимание. Там, где традиционно надеются на «русский авось», гораздо больше времени уделяют настройке какой-нибудь необязательной функции, например, красивому отображению списка абонентов в адресной книге, нежели созданию основы для сохранения всей информационной структуры предприятия. Зато в аварийной ситуации за такое пренебрежительное отношение платить приходится сполна: и временем при простоях, и потерей данных, и потерей денег, репутационными издержками и так далее. Поэтому, если вы не знаете, сколько времени вам потребуется на восстановление данных из резервной копии, можно с уверенностью сказать, что у вас на самом деле нет уверенности, что данные вообще будут восстановлены. После того как мы определились с характеристиками, позволяющими оценить эффективность системы резервного копирования, можно более предметно рассмотреть вопросы ее оптимизации. Для такой оптимизации есть два основных направления: архивировать хранимые данные, постоянно совершенствуя алгоритмы сжатия, и… собирать и хранить далеко не всю информацию. Второй способ с самого начала представляется гораздо более предпочтительным. Нет смысла без конца клонировать неизменяемые файлы, например, ядра операционной системы или справочные файлы, которые крайне редко изменяются и играют вспомогательную роль в работе информационных систем. Примечание. Иногда для множества однотипных серверов (например, для терминальной фермы) вообще нет смысла хранить множество резервных копий. Достаточно иметь автоматизированную систему для развертывания заранее настроенных и быстро разворачиваемых образов. В этом случае достаточно сразу же развернуть систему из образа заново и компьютер готов к работе. Таких решений существует достаточно много: от старенького Citrix Provisioning Services [2] до современных облачных структур. К сожалению, этот материал выходит за рамки данной статьи. Но можно пойти дальше – время от времени копировать важную информацию целиком, а в промежуточные временные участки только регистрировать изменения. Для того чтобы такое рискованное дело производило желаемый эффект и сохранялись именно нужные данные, были разработаны специальные виды неполного резервного копирования, к обсуждению которых мы и переходим. Виды резервного копирования
Статью целиком читайте в журнале «Системный администратор», №7-8 за 2014 г. на страницах 36-41. PDF-версию данного номера можно приобрести в нашем магазине. |
Алексей Бережной, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
