Практические шаги создания системы резервного копирования
•Download as PPTX, PDF•
2 likes•552 views
Презентация об актуальности внедрения системы резервного копирования в условиях кризиса, трудностях при выборе решения, оценке сценариев решения и стоимости решения в целом. Сделан акцент на практической последовательности шагов при проектировании СРК, которые помогут выполнить оценку проекта СРК и принять решение о выборе того или иного вендора.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Практические шаги создания системы резервного копирования
Similar to Практические шаги создания системы резервного копирования (20)
Практические шаги создания системы резервного копирования
- 1. Практические шаги создания системы резервного копирования Анализ сценариев Выбор решения Оценка стоимости Чекмасов Сергей Форум "Мир ЦОД - 2015"
- 2. НАДЕЖНОСТЬ СРК на заднем плане ЭКСПЛУАТАЦИЯ ВНЕДРЕНИЕ СРКСРК 2
- 5. У меня уже есть СРК Автоматизирована. Проверяется. Надёжно хранит. 5
- 6. ОтказоустойчивостьBackup Дублируем ошибки с образа 6
- 7. Хранение ретро данных Локальные и законодательные требования 7
- 9. Сделаем как у него! 9
- 13. Обследование и выбор вендора СРК сделать самостоятельно! 13
- 17. Классификация сервисов компании Категория сервиса Список сервисов в категории (для примера) Важность данных Не допускает перерыва в работе Расчетная система Продуктивная система Критические данные Допускает короткий перерыв в работе Электронная почта Документооборот Высокая важность данных Допускает длительный перерыв в работе Внутренний портал Расчет зарплаты Средняя важность данных Не требует резервирования Инсталляции ПО Файловый сервер Ценности не представляют 17
- 18. Восстановление и архивное хранение Категория сервиса Важность данных Архивное хранение Disaster Recovery Не допускает перерыва в работе Критические данные Короткое хранение Да Допускает короткий перерыв в работе Высокая важность данных Стандартное хранение Нет Допускает длительный перерыв в работе Средняя важность данных Длительное хранение Нет Не требует резервирования Ценности не представляют Не требуется Нет 18
- 19. Глубина хранения копий Наименование сервиса Длительность хранения Периодичность копирования Расчетная система 10 дней Каждый день Продуктивная система 10 дней Каждый день Электронная почта 1 год Последняя неделя – каждый рабочий день, последний месяц – раз в неделю, за последний год – раз в месяц Документооборот 1 год То же Внутренний портал 1 год То же Расчет зарплаты 1 год То же Инсталляции ПО нет нет Файловый сервер нет нет 19
- 20. График резервного копирования Категория сервиса Длительность хранения Периодичность копирования Без перерыва в работе 10 дней Каждый день Короткий перерыв в работе 1 год Последняя неделя – каждый рабочий день, последний месяц – раз в неделю, за последний год – раз в месяц Длительный перерыв в работе 1 год То же Не требует резервирования нет нет 20
- 21. Время на восстановление данных Категория сервиса Время на восстановление данных Без перерыва в работе 15 минут Короткий перерыв в работе 2 часа Длительный перерыв в работе 48 часов Не требует резервирования нет 21
- 22. Брекетинг сценария Усиление требований Основной сценарий Ослабление требований Всесервисы Требования к доступности сервисов Без перерыва в работе Короткий перерыв в работе Длительный перерыв в работе Не требует резервирования 22
- 23. Предотвратить риски Наименование сервиса Влияние на бизнес Длительность простоя Стоимость риска Расчетная система Сильное 15 мин От 1 до 2 млн. руб. Продуктивная система Сильное 15 мин 500 000 руб. Электронная почта Сильное 2 часа 100 000 руб. Документооборот Среднее 2 часа 200 000 руб. Внутренний портал Слабое 48 часов 50 000 руб. Расчет зарплаты Слабое 48 часов 200 000 руб. Инсталляции ПО Слабое Длительное 0 Файловый сервер Отсутствует Длительное 0 23
- 24. Объём защищаемых данных Наименование сервиса Копия данных приложения? Копия системных данных? Объём Расчетная система Да Да 30+10 Gb Продуктивная система Да Да 200+10 Gb Электронная почта Да Да 50+5 Gb Документооборот Да Нет 80 Gb Внутренний портал Да Нет 10 Gb Расчет зарплаты Да Нет 20 Gb Инсталляции ПО Нет Нет 0 Файловый сервер Нет Нет 0 24
- 25. Источник защищаемых данных Наименование сервиса Объём Источник данных Скорость канала, утилизация Доступность Расчетная система 40 Gb SQL 2012+VM 10 Gb/s, 40% 02:00-05:00 Продуктивная система 210 Gb SQL 2008+VM 1 Gb/s 02:00-05:00 Электронная почта 55 Gb Exchange+WS 1 Gb/s 20:00-08:00 Документооборот 80 Gb SQL 2008 1 Gb/s 20:00-08:00 Внутренний портал 10 Gb Sharepoint 1 Gb/s 20:00-08:00 Расчет зарплаты 20 Gb SQL 2008 1 Gb/s 20:00-08:00 Инсталляции ПО 0 FS 100 Mb/s 20:00-08:00 Файловый сервер 0 FS 100 Mb/s 20:00-08:00 25
- 26. Архитектура СРК • От каких сервисов можно отказаться в критической ситуации? • Какие сервисы нужно обеспечить приоритетно? • Как реализовать безопасность хранения резервных данных? 26
- 27. Архитектура СРК Основной ЦОД Резервный ЦОД «Холодный» резерв Резерв в облаке 27
- 28. Филиалы компании Центр Филиал 1 Филиал 1 Филиал 2 Филиал 3 Филиал 4 Филиал 5 Центр 2 Mb/sec 2 Mb/sec 2 Mb/sec 0,5 Mb/sec 0,5 Mb/sec Филиал 1 1 Mb/sec 1 Mb/sec 0,5 Mb/sec 0,5 Mb/sec Филиал 2 1 Mb/sec 0,5 Mb/sec 0,5 Mb/sec Филиал 3 0,5 Mb/sec 0,5 Mb/sec Филиал 4 0,5 Mb/sec Филиал 2 Филиал 3 Филиал 4 Филиал 5 28
- 29. Окно резервного копирования Наименование сервиса Место хранения Окно резервного копирования Канал передачи данных Расчетная система Резервный ЦОД 02:00-05:00 1 Gb/s Продуктивная система Резервный ЦОД 02:00-05:00 1 Gb/s Электронная почта Филиал 1 05:00-07:00 2 Mb/sec Документооборот Филиал 1 05:00-07:00 2 Mb/sec Внутренний портал Филиал 2 22:00-07:00 2 Mb/sec Расчет зарплаты Филиал 2 22:00-07:00 2 Mb/sec 29
- 30. Методика копирования данных • Полный или инкрементный бэкап? • Требуется ли отчуждение копий, запись на носители информации и перенос данных на другую территорию? • Физический перенос данных или копирование по сети? 30
- 31. Полная копия и инкремент Наименование сервиса Объём полной копии Объём инкремента Шифрование Расчетная система 40 Gb 10% Нет Продуктивная система 210 Gb 5% Нет Электронная почта 55 Gb 2% Да Документооборот 80 Gb 5% Да Внутренний портал 10 Gb 5% Нет Расчет зарплаты 20 Gb 1% Нет 31
- 32. Технические требования к СРК Категория сервиса RTO, час. RPO, час. Объём, Gb Срок хранения Окно копиро- вания Место хранения Основной сценарий Без перерыва в работе 0,4 24 250 10 дней 02:00 – 05:00 ЦОД Короткий перерыв в работе 2 24 135 1 год 05:00 – 07:00 Филиал 1 Длительный перерыв в работе 48 24 30 1 год 22:00 – 07:00 Филиал 2 Не требует резервирования нет нет 900 нет нет Нет 32
- 33. Существующая СРК Существующая СРК Основной сценарий Всесервисы Требования к доступности сервисов Без перерыва в работе Короткий перерыв в работе Длительный перерыв в работе Не требует резервирования 33
- 34. Квадрант Gartner для СРК 34
- 35. План восстановления Категория сервиса Цепочка действий Расчетное время восстановления Инцидент 1: Полный отказ серверной стойки 1 в ЦОД 1 Восстановление инфраструктуры Запуск маршрутизатора 1 Запуск резервного сервера Проверка доступности узла 10 мин. Восстановление Расчетной системы Восстановление Расчетной системы из копии на резервный сервер 10 мин. И т.д. Инцидент 2: Пропадание электропитания ЦОД 1 Восстановление сетевой инфраструктуры Запуск маршрутизаторов 1, 2 и 3 Проверка доступности ЦОД 2 15 мин. Восстановление Расчетной системы Запуск Расчетной системы в ЦОД 2 5 мин. 35
- 36. Выбор сценария и решения Сценарий реализации СРК Время восстано вления Потеря данных Стоимость рисков Топология решения Стоимость решения, Вендор1 Стоимость решения, Вендор2 Усиление требований От 0,4 до 24 часов От 12 час до 24 час От 1 до 2 млн. руб. Резервный ЦОД, архив в Филиалах 10 млн. 9 млн. Основной сценарий От 0,4 до 48 часов За 24 часа макс От 2 до 3 млн. руб. Резервный ЦОД, архив в Филиалах 8 млн. 9 млн. Ослабление требований От 0,4 до 48 часов За 48 часа макс От 3 до 5 млн. руб. Основной ЦОД, архив в резервном ЦОД 7 млн. 8 млн. Существую щая СРК 2 часа 24 часа От 4 до 6 млн. руб. Резервный ЦОД Обслуживание 2 млн./год 36
- 37. Послесловие • Связь СРК с другими системами • Прогноз рост объемов • Потребность в масштабируемости • Меры безопасности • Организация эксплуатации • Аудит копируемых данных на соответствие требованиям бизнеса 37
- 38. Практические шаги создания системы резервного копирования Спасибо за внимание Чекмасов Сергей ОАО «СО ЕЭС» www.linkedin.com/in/chekmasoff
- 39. Практические шаги создания системы резервного копирования Спасибо за внимание! Чекмасов Сергей ОАО «СО ЕЭС» www.linkedin.com/in/chekmasoff
Editor's Notes
- Выступление будет состоять из двух частей, в первой части покажу несколько комиксов, во второй – таблицы, диаграммы и инфографика проектирования СРК
- Резервное копирование данных не стоит первоочередной задачей, и это вполне объяснимо, т.к. сначала мы планируем внедрение, организуем эксплуатацию и только потом решаем вопросы надежности
- Бизнес всегда старается сокращать издержки, особенно по тем статьям, которые не приносят прямой прибыли, а в большинстве компаний службы информационных технологий являются «расходными» подразделениями. В условиях кризиса, который мы наблюдаем в настоящее время, необходимость инвестиций доказать особенно сложно. Но чтобы удержаться на плаву требуется действовать более динамично, активизировать направления, которыми раньше можно было пренебречь, расширяться на новые рынки и технологии. И как следствие, если компания хочет пережить трудные времена, она должна разворачивать новые информационные системы и вводить в эксплуатацию новое программное обеспечение.
- Приходится уплотнять вычислительные ресурсы, что сразу повышает риски потери данных и заставляет снова задуматься о надежности систем и защите данных.
- Вероятнее всего Ваши системные администраторы понимают, что жить без бэкапа, это всё равно что ездить без «запаски», у Вас уже есть какое-то резервное копирование. Но если администратор делает несколько действий резервного копирования по регулярной напоминалке в Outlook, считайте, что у вас нет СРК, т.к. СРК должна иметь, как минимум, полную автоматизацию создания резервных копий, проверку консистентности и обеспечивать надежность хранения копий.
- Кто-то строит надежные решения и наивно полагает, что данные в безопасности, но имейте ввиду, что отказоустойчивость не заменяет резервирование данных и если логическая ошибка произошла на одном сервере, то эта же логическая ошибка появится и на дублирующем сервере. Так что отказоустойчивый кластер и RAID массив надо тоже бэкапить.
- Более того, в мире для многих компаний установлено обязательное хранение ретроспективных данных, и если в результате аудиторской проверки не будут предоставлены исторические данные, то последствия могут быть разные, от штрафных санкций до ликвидации. К примеру, для российских банков хранение некоторых видов данных обязательно и составляет 7 лет.
- Вспоминая поговорку, что все люди делятся на тех, кто не делает бекапы, и на тех, кто уже делает, Вы соглашаетесь, что решение по резервному копированию необходимо для компании и смотрите на красивые коробки вендоров СРК пытаясь выбрать наиболее удовлетворяющего Ваши потребности. Но каждый производитель по своему хорош, использует свои собственные передовые разработки и систему метрик, которые трудно поддаются сравнению с другим конкурентом. Как же выбрать подходящую систему?
- Пользуясь мнением коллег по цеху, которые уже используют некоторую СРК, Вы производите примерную оценку стоимости решения, покупаете такую же СРК и передаёте в ИТ подразделение для ввода в эксплуатацию. Но вдруг оказывается, что лицензий не хватает, в СХД вмещаются только архивы за последнюю неделю или передача данных не укладывается в окно резервного копирования. Ошибка понятна, нужно было заказать обследование и обучиться
- Пусть Вы заказали обследование инфраструктуры у интегратора, ввели в эксплуатацию решение по СРК, но затем обнаруживается, что можно было бы неплохо сэкономить, выполнив аналогичное решение, используя другого вендора и не покупая нескольких новых серверов управления.
- Получается, что решение о выборе вендора СРК, которое посоветовал знакомый CIO, коллега из Вашей отрасли или которое предложил интегратор, проведя обследование, не оптимально? Даже объективные и продуманные чужие решения к Вам могут не подойти, т.к. скорее всего у Вас отличается инфраструктура и разная потребность в защите данных. И что бы ни говорил интегратор, что у него объективное решение, не зависящее от конкретного вендора, подготовку проекта по СРК выполняет конкретный специалист, который при проектировании использует того вендора, в котором у него наиболее сильные компетенции. Или сам интегратор предложит решение того вендора, с которым у него наиболее тёплые отношения.
- Не будем рассматривать вариант заказа проектирования двум или трем независимым интеграторам и получения несколько решений в разных вендорах, так как после таких обследований денег на внедрение уже не останется
- Выходит, что желательно обследование и выбор вендора СРК сделать самостоятельно
- Кстати, как быть с существующей СРК, если она у Вас уже есть? Посчитайте стоимость сопровождения, обслуживания и занятость персонала при использовании существующей СРК. Возможно, в результате стоимость внедрения новой СРК, которую мы получим в конце рассказа, будет сопоставима со стоимостью владения существующей СРК, предположим, за три года
- Теперь давайте попробуем дать ответ на наиболее важный вопрос для владельца компании, – о стоимости решения. Потребность в бэкапе вроде как есть и все это понимают, но сколько денег нужно выложить за СРК? Почему именно столько? И какой эффект будет? Когда вернутся инвестиции?
- Дать ответы на все эти вопросы и получить оценку стоимости СРК не так уж и тяжело. Далее переходим от комиксов к инфографике – часть вторая
- Для начала требуется составить реестр всех сервисов и обсудить с бизнесом требования к их непрерывности. Далее, выполнить классификацию сервисов по этим требованиям и классификацию обрабатываемых данных по важности для компании, принимая во внимание локальные требования компании, требования аудиторов, контролирующих органов и законодательства. Необходимо выделить несколько категорий сервисов, например, не допускающих перерыва в работе, допускающих короткий перерыв в работе, допускающих длительный перерыв в работе, и не требующих резервирования.
- Выполняя классификацию, нужно определиться, какую цель Вы преследуете, создавая СРК: восстановление сервисов после сбоя (Disaster Recovery) или архивное хранение данных. В первом случае, как правило, достаточно иметь недельный бэкап и воскресный за месяц, во втором – необходим более длительный период хранения, который может быть установлен внутренними требованиями компании или законом. Практика показывает, что частота обращения к архивам экспоненциально убывает с течением времени, т.е. вероятность того, что данные потребуются более чем через месяц, очень мала
- Если у Вас нет регламентированных требований к длительности хранения архивных данных, проведите оценку, за какими данными обращались с потребностью в восстановлении и с какой глубиной архива? Может вполне оказаться, что данные со сроком хранения полгода никогда не требовались. Кстати, считается, что практически любой человек хватится потерянных данных в течение сорока дней. Почему именно сорока дней? Потому что вынужденное отсутствие на работе, такое как отпуск или болезнь, как правило, короче.
- В результате проведенного анализа Вы получаете график резервного копирования, в котором по каждой категории сервисов указано, как часто они бэкапятся и сколько времени будет существовать копия
- Теперь, давайте оценим требуемое время на восстановление данных и добавим в реестр. Для сервисов, допускающих минимальные перерывы, нужно меньшее время восстановления данных, а для сервисов, требующих архивного хранения, восстановление данных возможно с некоторой задержкой
- Как всегда, в данном случае возникает борьба двух противоречивых состояний, с одной стороны, бизнесу хотелось бы, чтобы все сервисы работали безостановочно и восстанавливались «по щелчку», с другой стороны, ИТ-шникам хотелось бы, чтобы как можно больше сервисов не требовали резервного копирования и, чтобы забот было меньше. Решение о том, какое компромиссное состояние наиболее подходит для Вашего бизнеса и удовлетворяет бюджету, будет принято позже. Сейчас же достаточно сделать брекетинг на два-три сценария, в которых сдвинуть требования к доступности сервисов в сторону усиления требований и в сторону ослабления требований
- Давайте оценим, какие риски возникают и какие убытки влечет за собой отсутствие того или иного сервиса. Если точную оценку дать сложно, используйте формулировку «от и до», применяйте обороты компании в долевом отношении к влиянию риска на обороты. В результате этого анализа в реестр добавится стоимость потери того или иного сервиса
- Далее, считаем объем защищаемых данных. Для высококритичных сервисов, чтобы была возможность их быстрого восстановления, скорее всего, потребуется делать копию не только данных самих приложений, но и системные данные. Кстати, если отказ активного сетевого оборудования приведет к потере критически важных сервисов, то и конфигурации этого оборудования нужно хранить. Для сервисов, предназначенных для архивного хранения, достаточно сделать акцент на хранении пользовательских данных. Однако надо понимать, что если Вы делаете резервную копию только пользовательских данных, то время восстановления сервиса увеличивается, т.к. в случае отказа сначала будет установлен и сконфигурирован сервер, и только потом будут восстановлены пользовательские данные.
- Таким образом, в реестр добавляем информацию об объеме и характере защищаемых данных (виртуальные машины, серверы Windows, базы данных SQL, почтовый сервер и т.д.), скорости сетевых подключений и их доступности.
- Теперь самое время подумать об архитектуре СРК. Для этого нужно ответить на несколько вопросов, касающихся необходимости обеспечить работающую инфраструктуру. Насколько может деградировать сервис Вашей компании, чтобы риски были минимальными? От каких сервисов можно отказаться в критической ситуации. Какие сервисы нужно обеспечить приоритетно? Как реализовать безопасность хранения резервных данных?
- Если потеря расчетного центра равносильна остановке компании, то кроме резервного ЦОДа нужно иметь географически выделенную резервную копию данных. Сделайте оценку, нужно ли Вам проектировать отказоустойчивый кластер, или достаточно иметь выключенное оборудование в другом ЦОДе или подготовленные и отключенные сервисы в облаке. А если расчетный центр оперирует постоянно изменяющимися данными, хранение которых не представляет ценности и нужен только итоговый расчет для ретроспективы, необходимо исключить серверы обработки данных из расписания бэкапа.
- Если у Вашей компании есть филиалы, то целесообразно ли передавать на хранение копии в другой филиал, организовывать централизованное управление системой и хранение данных. Оцените объем защищаемых данных в филиалах, каналы передачи данных между филиалами, наличие компетенций у ИТ специалистов в этих филиалах.
- Если филиалы разнесены географически по разным часовым поясам, оцените возможные окна резервного копирования, посчитайте нагрузку на каналы, если целевая архитектура СРК предполагает удаленное хранение резервных копий. Процесс резервного копирования создает нагрузку на продуктивную систему и, в некоторых случаях, требует определенных действий с данными, чтобы сохранить их консистентность, поэтому планируйте окно резервного копирования за пределами продуктивного использования сервисов или в период минимальной нагрузки, вмещающее все необходимые операции резервного копирования с запасом.
- Давайте определимся со следующими вопросами: Требуется ли отчуждение копий, запись на носители информации и перенос данных на другую территорию? Физический перенос данных или копирование по сети? Полный или инкрементный бэкап?
- По своей сути, полный бэкап всех данных нужен дважды: первый раз с вероятностью в 100%, когда Вы запускаете систему резервного копирования в эксплуатацию, и второй раз с очень малой вероятностью, когда у Вас случилась полная потеря данных в ЦОД. Учитывайте это, и относитесь спокойно к перевозке нескольких десятков накопителей информации физическим транспортом, ведь прокачать большой объем по сети сегодня не всегда представляется возможным. Если необходимо, рассмотрите вопрос шифрования данных при перемещении данных. После запуска СРК достаточно оперировать только инкрементными копиями, т.к. многие современные системы имеют возможности создания полных копий из инкрементов и достаточно инструментов сокращения нагрузки на канал, сжатия и дедупликации трафика.
- На данном этапе у Вас есть реестр всех сервисов компании, они классифицированы по требованиям со стороны бизнеса и есть представление о целевой архитектуре системы. Этот реестр можно считать техническими требованиями к СРК, причем, если Вы еще не догадались, в требованиях уже есть RPO и RTO, объем и характеристика защищаемых данных, окно СРК и топология СРК. И фактически, если Вы сделали брекетинг о котором говорилось выше, имеем несколько сценариев реализации проекта СРК, не зависящих от аппаратного и программного обеспечения.
- Если у Вас уже есть СРК, посмотрите, насколько она соответствует сформированным техническим требованиям, и можно ли привести текущее состояние существующей СРК к целевой модели? Если можно, то, что нужно для этого сделать?
- Если Вы считаете, что прошли достаточно много и уже устали, то берите Ваши требования и отправляйте на оценку в presale различных вендоров или интеграторов. Многие компании готовы бороться за потенциального покупателя и выделяют хороший бюджет для офисов предпродаж, особенно в условиях кризиса. Тем более, если Вы попадаете в сегмент Enterprise, то смело берите лидеров из квадранта Gartner и запрашивайте предварительную оценку стоимости сценариев СРК. Для небольших компаний вполне подойдет свободно-распространяемое программное обеспечение, имеющее достаточно долгую историю и позитивные отклики.
- Если желаете двигаться дальше, то придется пойти обратным путем и разработать план восстановления. Здесь уместно будет воспользоваться знанием о технологии работы сервиса и для каждого вида технологии разработать свой локальный план. Далее, эти локальные планы последовательно выстраивают в цепочки, так, чтобы для каждого следующего сервиса была готова инфраструктура, среда, другие сервисы. Эти цепочки и будут составлять план восстановления, и зависеть от масштабов инцидента.
- В итоге, Вы получили предложения по проектированию СРК на решениях нескольких вендоров и по нескольким сценариям. Учитываете имеющиеся ограничения и принимаете решение о выборе целевой модели в рамках бюджета. Сгруппируйте по классификации сервисов и просуммируйте строки реестра, а затем продемонстрируйте CEO варианты реализации СРК. Покажите наглядно, за какие деньги он получит восстановление сервисов компании, и с какой скоростью. Укажите, какие риски предотвращаются, и какова предполагаемая цена этих рисков.
- В качестве послесловия добавлю, что при обследовании нужно уделить внимание вопросам связи СРК с другими системами, например, такими как системы мониторинга, а также спрогнозировать рост объемов резервного копирования, потребность в масштабируемости системы и меры безопасности при организации хранения данных. Не забудьте раз в год выполнить аудит копируемых данных на соответствие требованиям бизнеса
- Cтатья ожидается в августе в журнале "Журнал сетевых решений/LAN"
- Cтатья ожидается в августе в журнале "Журнал сетевых решений/LAN"