Почему нельзя просто скопировать файлы. О резервном копировании, а также об инкрементальном парадоксе::Журнал СА 7-8.2014
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

День сисадмина  

Учите матчасть! Или как стать системным администратором

Лето – время не только отпусков, но и хорошая возможность определиться с профессией

 Читать далее...

День сисадмина  

Живой айтишник – это всегда движение. Остановка смерти подобна

Наши авторы рассказывают о своем опыте и дают советы начинающим системным администраторам.

 Читать далее...

Виртуализация  

Рынок решений для виртуализации

По данным «Обзора российского рынка инфраструктурного ПО и перспектив его развития», сделанного

 Читать далее...

Книжная полка  

Как стать креативным и востребованным

Издательский дом «Питер» предлагает новинки компьютерной литературы, а также книги по бизнесу

 Читать далее...

Книжная полка  

От создания сайтов до разработки и реализации API

В издательстве «БХВ» недавно вышли книги, которые будут интересны системным администраторам, создателям

 Читать далее...

Разбор полетов  

Ошибок опыт трудный

Как часто мы легко повторяем, что не надо бояться совершать ошибки, мол,

 Читать далее...

Принципы проектирования  

Dependency Inversion Principle. Принцип инверсии зависимостей в разработке

Мы подошли к последнему принципу проектирования приложений из серии SOLID – Dependency

 Читать далее...

Рынок труда  

Вакансия: Администратор 1С

Администратор 1С – это специалист, который необходим любой организации, где установлены программы

 Читать далее...

Книжная полка  

Книги для профессионалов, студентов и пользователей

Книги издательства «БХВ» вышли книги для тех, кто хочет овладеть самыми востребованными

 Читать далее...

Принципы проектирования  

Interface Segregation Principle. Принцип разделения интерфейсов в проектировании приложений

Эта статья из серии «SOLID» посвящена четвертому принципу проектирования приложений – Interface

 Читать далее...

Книжная полка  

Секрет успешных людей

Книги издательства «БХВ» по ИТ рассчитаны на разные категории читателей: от новичков

 Читать далее...

Учебные центры  

Карьерные мечты нужно воплощать! А мы поможем

Школа Bell Integrator открывает свои двери для всех, кто хочет освоить перспективную

 Читать далее...

Гость номера  

Дмитрий Галов: «Нельзя сказать, что люди становятся доверчивее, скорее эволюционирует ландшафт киберугроз»

Использование мобильных устройств растет. А вместе с ними быстро растет количество мобильных

 Читать далее...

Прошу слова  

Твердая рука в бархатной перчатке: принципы soft skills

Лауреат Нобелевской премии, специалист по рынку труда, профессор Лондонской школы экономики Кристофер

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 11274
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 9530
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 9578
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5986
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 6695
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 3988
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 2907
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 3715
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 3719
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6209
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3064
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3363
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7180
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 10558
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12274
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 13908
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9039
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 7000
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5310
Комментарии: 3
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4543
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3350
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

Друзья сайта  

 Почему нельзя просто скопировать файлы. О резервном копировании, а также об инкрементальном парадоксе

Архив номеров / 2014 / Выпуск №7-8 (140-141) / Почему нельзя просто скопировать файлы. О резервном копировании, а также об инкрементальном парадоксе

Рубрика: Администрирование /  Бэкап

Алексей Бережной Алексей Бережной, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, alexey.berezhnoy@tech-center.com

Почему нельзя просто скопировать файлы
О резервном копировании, а также об инкрементальном парадоксе

Вряд ли можно найти профессионала в области ИТ, который бы стал отрицать необходимость всегда иметь надежную актуальную резервную копию. Но никто не спорит, что гораздо надежнее иметь две копии! Например, за вчера и за сегодня. А еще лучше иметь целый архив за требуемый период

Зачем все так усложнять, если нужно просто сохранить данные?

Если требования достаточно серьезные, то резервное копирование превращается в весьма недешевое удовольствие. И дело не только в стоимости носителей данных для хранения, специфического программного обеспечения для резервного копирования на профессиональном уровне.

Сам по себе процесс резервного копирования способен создавать весьма внушительную нагрузку на ИТ-инфраструктуру. (Об этом рассказывается в статье «Не теряя управления» [1].) Поэтому крайне важно максимально оптимизировать сам процесс выборки, передачи и хранения данных.

Это нужно, во-первых, для того, чтобы попадать в так называемое окно бэкапа (когда ИТ-инфраструктура испытывает минимальную нагрузку и можно выполнять массовое копирование без риска кому-то сильно помешать), и, во-вторых, чтобы не хранить колоссальные объемы не особо нужной информации, тратя на это деньги, человеческие ресурсы для обслуживания таких «хранилищ» и так далее.

Любая система резервного копирования – это уникальная экосистема, которая при неправильном подходе из ангела-хранителя превращается в прожорливого монстра, проедающего денежные и людские ресурсы и в итоге не приносящего ничего, кроме головной боли.

Планирование работы системы резервного копирования

Вот тут и начинается самое интригующее. Как оно обычно бывает: посидели на совещании, обозначили, какие данные нужно копировать, разошлись по кабинетам, подсчитали приблизительный объем и время на создание копии, и стало ясно, что при прямолинейном подходе «сохранять все нужное на неопределенный срок» не получится никогда. Прежде чем создавать систему сохранения данных, необходимо выяснить критерии ее эффективной работы и сопоставить их с возможными материальными и временными затратами.

Вот несколько характеристик, которые влияют на эффективность резервного копирования:

  • глубина хранения данных;
  • ограничение времени;
  • ограничение объема;
  • ограничение времени восстановления.

Остановимся по порядку на каждом пункте.

Глубина хранения данных – это период, за который хранятся резервные копии. В предыдущих своих работах я писал о необходимости четко разграничивать резервное копирование, выполняемое в целях создания архива, и резервное копирование для последующего быстрого восстановления системы (Disaster recovery). Но любой архив имеет замечательное свойство увеличиваться в размерах: чем дольше срок, за который собирались и поступали на хранение данные, тем больше размер архива. Если хранить абсолютно все копии начиная со дня основания компании, то тут никакого бюджета не хватит – все уйдет на покупку средств хранения и на оплату услуг по обслуживанию такого «монстра». Поэтому разумное решение в данном случае – ограничить срок хранения некими рамками, что и называется глубиной хранения.

Ограничение времени создания резервной копии. Создание резервной копии – процесс достаточно ресурсоемкий. Нельзя просто взять и запустить копирование большого объема данных, не согласовав свои действия с другими участниками бизнес-процесса. Мало того, довольно часто возникает ситуация, когда также нельзя запросто прервать процесс резервного копирования. Поэтому временные ограничения на создание резервной копии являются одним из решающих факторов при проектировании системы резервного копирования.

Ограничение объема, наверное, не нуждается в детальном описании. Рано или поздно любой ИТ-специалист сталкивается с дефицитом дискового пространства или нехваткой съемных носителей для хранения большого объема данных. При этом проблема часто заключается даже не в отсутствии денежных средств на приобретение нового оборудования, а в необходимости кардинальной реконструкции всей инфраструктуры или хотя бы одного из ее фрагментов. При этом имеющееся оборудование может быть уже не востребовано. Хороший пример: переход на новую версию LTO для системы ленточных библиотек, при которой может потребоваться замена аппаратного обеспечения, картриджей LTO и установка дисковой подсистемы для кэширования большего объема данных. Поэтому ситуация «надо сохранить, да некуда» встречается довольно часто и не несет с собой ничего хорошего.

Ограничение времени восстановления. Этой немаловажной характеристике работы системы резервного копирования, как правило, уделяется меньше всего внимания. Обычная практика при проектировании систем сохранения данных: «Главное, чтобы проверенная актуальная копия имелась в наличии (!), а сколько времени потребуется на ее восстановление – это уже не так важно».

К сожалению, имеются грустные основания для подобного подхода – во многих российских компаниях резервное копирование до сих пор рассматривается как нечто не слишком обязательное, и ИТ-специалисты не склонны уделять вопросам сохранения данных слишком пристальное внимание. Там, где традиционно надеются на «русский авось», гораздо больше времени уделяют настройке какой-нибудь необязательной функции, например, красивому отображению списка абонентов в адресной книге, нежели созданию основы для сохранения всей информационной структуры предприятия.

Зато в аварийной ситуации за такое пренебрежительное отношение платить приходится сполна: и временем при простоях, и потерей данных, и потерей денег, репутационными издержками и так далее. Поэтому, если вы не знаете, сколько времени вам потребуется на восстановление данных из резервной копии, можно с уверенностью сказать, что у вас на самом деле нет уверенности, что данные вообще будут восстановлены.

После того как мы определились с характеристиками, позволяющими оценить эффективность системы резервного копирования, можно более предметно рассмотреть вопросы ее оптимизации. Для такой оптимизации есть два основных направления: архивировать хранимые данные, постоянно совершенствуя алгоритмы сжатия, и… собирать и хранить далеко не всю информацию. Второй способ с самого начала представляется гораздо более предпочтительным. Нет смысла без конца клонировать неизменяемые файлы, например, ядра операционной системы или справочные файлы, которые крайне редко изменяются и играют вспомогательную роль в работе информационных систем.

Примечание. Иногда для множества однотипных серверов (например, для терминальной фермы) вообще нет смысла хранить множество резервных копий. Достаточно иметь автоматизированную систему для развертывания заранее настроенных и быстро разворачиваемых образов. В этом случае достаточно сразу же развернуть систему из образа заново и компьютер готов к работе. Таких решений существует достаточно много: от старенького Citrix Provisioning Services [2] до современных облачных структур. К сожалению, этот материал выходит за рамки данной статьи.

Но можно пойти дальше – время от времени копировать важную информацию целиком, а в промежуточные временные участки только регистрировать изменения. Для того чтобы такое рискованное дело производило желаемый эффект и сохранялись именно нужные данные, были разработаны специальные виды неполного резервного копирования, к обсуждению которых мы и переходим.

Виды резервного копирования

  • полное резервное копирование (Full Backup);
  • различные виды неполного резервного копирования:
    • инкрементальное резервное копирование (Incremental Backup);
    • дифференциальное резервное копирование (Differential Backup);
    • обратное инкрементальное резервное копирование (Reverse Incremental Backup).

Статью целиком читайте в журнале «Системный администратор», №7-8 за 2014 г. на страницах 36-41.

PDF-версию данного номера можно приобрести в нашем магазине.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru