Резервное копирование *

Введение

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

1. Как запланировать место для хранения большого объема данных
2. Как сделать резервную копию этих данных

Действительно, рост объема данных на терабайты в год у какой-нибудь крупной организации – сегодня вполне реальный сценарий. Но как быть с эффективным хранением и резервным копированием? Ведь в сутках есть максимум 24 часа и окно резервного копирования не может расти бесконечно (в отличие от самих данных). Сегодня я хочу рассказать, как дедупликация может помочь уменьшить остроту этой проблемы.

1998 год, Студия Pixar. Полным ходом идет создание «Истории игрушек 2». В процессе участвует более 150 человек. Размер исходных материалов анимации составляет 10 ГБ (по тем временам это очень много). Каждый день строится полный бэкап на ленту. Кассета имеет размер… 4ГБ (данные при записи на ленту сжимаются, но, конечно, не до такой степени). Каждый раз выдается ошибка, но этого никто не замечает, потому что лог-файл располагается на этой же кассете и пишется в самом конце бэкап-задания, а, поскольку места на кассете уже нет, он имеет размер 0 байт. Каждую неделю проводится тестовое восстановление данных, в ходе которого проверяются первые 2000 кадров анимации. И, конечно, каждый раз тест проходит успешно.

… А потом вдруг наступил день, когда кто-то из сотрудников (ошибочно или намеренно) запустил на сервере команду "/bin/rm -r -f *" (или аналогичную), которая удалила 90% из 100,000 файлов исходников анимации. Один из сотрудников компании, Ларри Катлер, как раз просматривал файлы папки с исходниками анимации, собираясь откорректировать что-то в модели шляпы персонажа Вуди, как вдруг он заметил, что файлов в папке осталось всего 40… потом 4… а еще через секунду их там не осталось вовсе. Ларри позвонил в ИТ службу и сообщил, что "произошла масштабная потеря данных", и что "восстановление потребует полную резервную копию..." Которой, как выяснилось чуть позже, у них не было, несмотря на ежедневный бэкап.

Если мантра Google звучит как “поиск всей информации в мире одним кликом”, то мантра молодого российского проекта Pandorama идет дальше: “найдем без клика всю интересную вам информацию”.

Приложение Pandorama предлагает своим пользователям “бесконечную” персонализированную ленту новостей, составленную на основе их личных информационных предпочтений, не требуя при этом от читателя работы с “тегами”, “категориями” или “лайками” друзей. Сначала нужно ответить на пару вопросов про несколько забавных панд, а потом нужно просто… читать предлагаемую ленту. Те новости, которые вы прочитали, будут автоматически анализироваться и обрабатываться системой, с тем, чтобы в дальнейшем такого рода новостей в ленте становилось все больше, а тех новостей, которые не вызвали у вас интереса – все меньше.

Pandorama уже объединяет более 40 тыс. пользователей по всему миру, и это число постоянно растет. В данной статье рассматривается BigData-инфраструктура этого проекта, функционирующая в режиме 24x7, механизмы обеспечения ее отказоустойчивости, и защита ее данных от сбоев, построенная с использованием Veeam Backup & Replication Cloud Edition.

Год назад мы делали обзор бесплатного инструмента для резервного копирования виртуальных машин (ВМ) и их управления в VMware и Hyper-V – Veeam Backup Free Edition. Недавно состоялся выпуск версии 7.0 с новыми фичами и улучшениями. В этом посте я хочу рассмотреть те функции, которые показались мне наиболее интересными.

Для начала я хочу отметить три главные функции:

• VeeamZIP – позволяет создать резервную копию работающей ВМ без ее отключения, например, для того, чтобы перенести ВМ и файлы на другой хост.
• Восстановление из резервных копий – покрывает большое кол-во сценариев восстановления, включая ВМ целиком, файлы гостевой ОС или отдельные объекты приложений.
• Quick Migration для VMware – позволяет мигрировать работающую ВМ между хостами и/или хранилищами с минимальным временем простоя без использования кластеров и общих хранилищ даже при отсутствии VMware vMotion и vStorage Motion.

В первой части данной статьи мы рассказали про правило резервного копирования «3-2-1». Теперь мы приглашаем посмотреть вторую часть статьи, содержащую запись нашего полуторачасового вебинара, подготовленного в формате whiteboarding сессии (то есть никаких PowerPoint слайдов — будет только наш эксперт и презентационная доска), на которой он шаг за шагом показывает какие проблемы встречаются у компаний в области резервного копирования, и как правило «3-2-1» можно реализовать на практике на примере продукта Veeam Backup & Replication. Помимо записи вебинара в статье приводятся ответы на наиболее актуальные вопросы, заданные участниками в ходе его онлайн-трансляции.

Считается, что бэкап-правило «3-2-1» впервые описал Peter Krogh в своей книге «Управление цифровыми активами для фотографов». И это, наверное, неудивительно, так как потеря личного архива означает для профессионального фотографа полную катастрофу, и он просто обязан придерживаться такой стратегии резервного копирования, которая гарантировано защитит его от потери данных.



Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:

1. ТРИ резервные копии,
2. которые должны быть сохранены в ДВУХ различных физических форматах хранения,
3. причем ОДНА из копий, должна быть передана на внеофисное хранение

Все три составляющих правила базируются на принципе обеспечения отказоустойчивости через избыточность хранения данных.

В прошлой статье я рассказал про преимущества/недостатки и способы улучшения работы по резервному копированию через технологию прямого доступа к SAN – Direct SAN Access. Сегодня продолжим наш рассказ.

В новой версии Veeam Backup & Replication v7, которая будет выпущена уже через пару месяцев, будет встроен WAN акселератор, специально оптимизированный под передачу резервных копий через WAN. Когда вы делаете копирование бэкап файлов за пределы офиса, вы значительно увеличиваете надежность системы хранения данных, однако одновременно сильно увеличиваете нагрузку на свой WAN канал, что выражается, прежде всего, в значительном увеличении времени резервного копирования. WAN акселератор позволяет эффективнее передавать данные даже через медленные соединения за счет применения следующих алгоритмов работы:

1. передача только измененных данных (все данные разделяются на блоки, и через WAN передаются только измененные блоки)
2. глобальный кеш блоков данных (то есть кеш, охватывающий все имеющиеся виртуальные машины), позволяет передавать хеши ранее переданных блоков, вместо данных самих блоков
3. сжатие сетевого трафика и дедубликация данных с переменной длиной блока
4. мультипоточные параллельные TCP/IP соединения для увеличения скорости передачи данных и другие TCP/IP оптимизации под соединения с большим временем отклика, характерным для WAN сетей
5. автоматическое возобновление прерванных соединений

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

При этом, восстанавливать машины в сеть компании нужно продуманно и осторожно — скорее всего возникнут конфликты между оригинальной и восстановленной (тестовой) машинами, если они будут функционировать в рамках одного сетевого пространства (могут быть конфликты на уровне IP, DNS, домена и приложений).

Какие же технологии могут помочь администратору в этом вопросе, применительно к резервному копированию и восстановлению виртуальных машин?

17 мая в Москве прошел очередной VMware Users Community Group. Компания Veeam, как обычно, не прошла это мероприятие стороной. Я собирался рассказать презентацию о том, как учесть все аспекты для правильного построения системы резервного копирования на базе ПО Veeam Backup & Replication – по мотивам прошлогодней презентации на VMworld.

Но уже после подготовки всех слайдов, я понял, что тема достаточно обширна, чтобы вместиться в рамки короткой презентации. Да и сам формат презентационных слайдов не очень подходит для нее. Плюс не хотелось загружать людей текстом. В-общем, в самый последний момент перед началом выступления, получив несколько вопросов по новшествам версии 7, я поменял тему презентации на «История Veeam Backup & Replication», где рассказал о том что было, что у нас есть сейчас, и что планируем сделать в ближайшей версии.

Тема, как настроить Veeam Backup осталась актуальна. К тому же во время выступления, и намного больше – после него, я получал технические вопросы, которые и собираюсь осветить в серии статей. А самое главное – задавайте вопросы здесь, в комментариях, и мы на них обязательно ответим.

Прежде чем перейти к сегодняшней теме, отмечу один вопрос, заданный мне на форуме VMUG. Когда Veeam Backup будет бэкапить данные не через снапшоты VMware, а «железные» снапшоты СХД? На тот момент я не мог озвучить, но сейчас в полной мере отвечаю: c версии 7 Veeam Backup будет уметь копировать данные из SAN снапшотов. На начальном этапе будет осуществляться поддержка оборудования HP: LeftHand (включая VSA) и 3PAR.
Принцип прост: уже сейчас есть Veeam Explorer for SAN Snapshots, позволяющий вытаскивать данные из снапшотов. С помощью этой технологии и VMware Changed Block Tracking (CBT), Veeam Backup будет инкрементально доставать данные уже для резервных копий.

А теперь перейдем к первой части советов:

Сегодня я хочу затронуть вопрос о некоторых важных принципах процедуры резервного копирования и восстановления после сбоев. В частности будут рассмотрены такие вопросы как:

1. Взаимосвязь процедур обновлений продуктивной системы и процесса ее резервного копирования
2. Тестирование восстановления из резервных копий
3. Взаимодействие бэкап-процесса с элементами сетевой инфраструктуры продуктивной сети
4. Документирование процедуры восстановления после сбоев

В последние несколько ночей у меня нашлось немного свободного времени, и я решил разнообразить свои будни изучением в своей лаборатории нового продукта от Veeam. Veeam Backup Cloud Edition — это продукт, который дает возможность перемещать локальные резервные копии за пределы офиса, — в любое из 15 популярных облачных хранилищ, или в произвольное облачное хранилище, поддерживающее OpenStack, или даже просто на любые файловые сервера, расположенные внутри или вне офиса. Что это дает с практической точки зрения? --Экономически оптимальное решение для внеофисного хранения резервных копий виртуальных сред на базе VMware или Hyper-V, и, при этом, не требующее пересмотра существующих процессов локального внутриофисного резервного копирования.

В соответствии с законодательными требованиями, отраслевыми нормативами и корпоративными политиками от компании могут требоваться длительные сроки хранения корпоративной информации (5, 10 и даже 30 лет). На что нужно обратить особое внимание в таком случае?

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

Вышел Veeam Backup Cloud Edition — продукт для резервного копирования виртуальных сред VMware vSphere и Microsoft Hyper-V, который позволяет выполнять резервное копирование в любую из лидирующих в настоящий момент облачных платформ, поддерживающих OpenStack, таких как Windows Azure, Amazon S3, Amazon Glacier, Google, Rackspace, HP Cloud и ряда других (всего 15 платформ). В таком сценарии облако может выступать в роли альтернативы лентам и внеофисному хранению резервных копий, так как среднегодовая отказоустойчивость такого облачного хранилища, как, например, Amazon Glacier составляет 99.999999999%.

Последнее время в практике часто возникает вопрос почему продукты резервного копирования (в том числе их бесплатные версии), специально созданные для работы в виртуальной среде (то есть не использующие программных агентов внутри виртуальных машин), не поддерживают бесплатный VMware vSphere Hypervisor (Free ESXi). Причина кроется вовсе не в технических ограничениях или нежелании производителей поддерживать бесплатный гипервизор, а в лицензионных ограничениях VMware. Об этом и хотелось рассказать подробнее.

По законодательным требованиям США публичные компании обязаны высылать свои квартальные отчеты членам Совета Директоров в определенные сроки. Но бывают и эксцессы. Например, в одной публичной компании в последний день предоставления отчетности за 3 квартал 2004 года, внезапно упал почтовый сервер. То есть отчет был готов, но CEO не мог его отправить через доверенный почтовый сервер. Падение произошло утром в пятницу, а сервер удалось восстановить и сделать доступным для работы пользователей только к утру понедельника. Требования закона были нарушены. Поэтому важнейшим параметром любого продукта резервного копирования является время восстановления – RTO (Recovery Time Objective). Именно этот параметр кардинально улучшает технология vPower.

Технология vPower интегрирована в Veeam Backup & Replication, начиная с версии 5.0. В 2010 году Veeam подал заявку на получение патента; сейчас vPower поддерживает два самых распространенных на рынке гипервизора – VMware vSphere и Windows Server Hyper-V.

В День Конца Света уместно вспомнить какой должна быть политика резервного копирования и восстановления данных после сбоев и катастроф.

Когда происходят значительные катаклизмы, подобные урагану Sandy и наводнению в Нью-Йорке, компании вспоминают про свою «страховку»: была ли резервная копия, не утеряна ли она вместе с оригинальными данными, можно ли из нее восстановить приложения и данные, была ли покрыта процессом резервного копирования вся продуктивная система или только ее часть, и сколько времени займет восстановление?

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

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

Проверка резервных копий бывает двух видов:

• Проверка целостности резервной копии – сверяются контрольные суммы блоков данных резервной копии.
• Проверка восстановления из резервной копии – в специальной изолированной среде (“песочнице”) моделируется процесс восстановления системы из резервной копии, и проверяется, будет ли она работать корректно после восстановления.

Тестирование – проблемный вопрос

Жизненный опыт показывает, что часто компании “экономят” на тестировании резервных копий. Это может быть связано как с недостаточной осведомленностью в отношении возможных проблем на фазе восстановления, так и с экономическими факторами, так как полноценный процесс тестирования восстановления системы из резервной копии, если проводить его вручную, — очень трудоемкая операция. Такая ситуация чревата последствиями, ведь в случае сбоя критические данные могут не быть восстановленными в заданное время или, что еще хуже, могут быть частично или полностью потеряны.

Чтобы пользователи могли быть уверенными в восстановлении критических данных в случае сбоев, разработчики Veeam Backup & Replication реализовали технологию SureBackup, позволяющую автоматически проверять возможность восстановления данных из резервной копии. Несмотря на то, что SureBackup существует уже более 2 лет, об этой возможности знают не все. Мы попробуем внести ясность в коротком посте ниже.

25 октября вышла новая версия нашего флагманского продукта – Veeam Backup & Replication 6.5. Новая версия включила в себя ряд интересных усовершенствований, одна из которых – восстановление виртуальных машин (ВМ) из “снэпшотов” SAN (аппаратных снимков). Ниже я коротко расскажу про эту технологию подробнее.

Кратко об СХД HP LeftHand Storage

После появления виртуальных сред в компаниях появилась возможность запуска на одном сервере нескольких ВМ. Со временем количество серверов, ВМ и приложений в компании растет, а емкости и производительности систем хранения данных (СХД) становится недостаточно. Эта проблема решается добавлением дополнительных дисковых полок до того момента, пока контроллерная пара СХД не станет узким местом в развитии инфраструктуры. При наступлении такой крайней ситуации обычно компании решают либо заменить контроллерную пару (upgrade), либо поставить новую СХД.

С точки зрения архитектуры HP SAN Left Hand Storage (HP SAN) принципиально отличается от стандартных СХД тем, что масштабируются не только по емкости, но и про производительности. HP SAN не имеет отдельных контролеров и отдельных дисковых полок, а каждый массив обладает своими ресурсами (процессор, диски, кэш, порты ввода / вывода), поэтому наращивая массив компания не только увеличивает дисковые ресурсы, но и процессорную емкость, кэш, т.д.

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

Подробнее можно посмотреть хорошее поясняющее видео (на английском).

Состоялся выпуск новой версии Veeam Backup & Replication 6.5 для VMware и Hyper-V. Версия содержит более 50 усовершенствований, большая часть которых вошла и в бесплатную версию продукта. Наиболее интересные и важные среди них:

• E-Discovery и гранулярное восстановление объектов Exchange сервера
• Восстановление из снимков дисков HP SAN
• Поддержка vSphere 5.1 и Windows Server 2012 Hyper-V
• Обеспечение корректности IP пакетов соединений при передаче резервных копий через WAN

Рассмотрим их подробнее: