Восстановление данных *

В первой части данной статьи мы рассказали про правило резервного копирования «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%.

Глеб основатель нескольких удачных стартапов. Его история и опыт будут интересны тем, кто ввязался в стартап игру или только подумывает об этом.

Задался я однажды целью портировать данную игру на более современные платформы. Но понятное дело игра является далеко не open source и когда-то в далеком 1994 году разработчики брали за нее ни много ни мало 25 баксов, а посему все игровые ресурсы нужно было либо перерисовывать, либо потрошить единственный игровой архив. Чем я и занялся.

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

Доброго дня уважаемые Хабрчане!

В давно, в свое время я думал что наличие бэкапа на дополнительном жестком диске или на сетевой папке или еще где-то (учитывая то там raid) на 100% обеспечит возможность восстановления утерянных данных. Как я был неправ…… Тому виной была самоуверенность, думал что переписав часть на болванки и положив в темный-темный шкаф все будет хорошо.

Прошло несколько лет и налоговой потребовалась бухгалтерская информация 3-4 летней давности (при том, что срок хранения финансовой информации составляет 5 лет, а персональных данных 75 ЛЕТ!!!). Рассказывать про то, что в самый последний момент выяснилось, что raid сломался, диски переписаны, болванки не читаются я не буду – будет слишком много звуков “3.14159….” которые я выслушал от руководства.

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

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

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

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

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

Я хочу рассказать об особенностях работы с компонентом Intelligent Disaster Recovery, входящем в состав Symantec Backup Exec Этот компонент обеспечивает быстрое восстановление после сбоев и позволяет при своевременно сделанном бэкапе быстро поднять машину из состояния «чистое рабочее железо» в состояние «все работает».
Эта статья – о работе с IDR, встречающихся проблемах и способах их решения и известных мне подводных камнях.
Картинка для привлечения внимания

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

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

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

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

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

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

Знакомство с бекапами в моей жизни началось почти сразу после знакомства с компьютерами в 2001 году. И тут уместна поговорка админы делятся на два типа, первый тип это те которые еще не делали Backup и второй те кто уже делает. Почти сразу же был подхвачен вирус, которые испортил все файлы jpeg на компе, просто записав в них какой то мусор, слава богу было время ещё аналоговой фотографии и их можно было просто отсканить ещё раз. Но уже тогда в моем мозгу крепла мысль иметь всегда копию.

Сперва она лежала на соседнем компе в кабинете информатики. Потом появилось чудо пишущий cdrom со скоростью 1-2x для записи, я стал покупать болванки стоили они тогда по моему рублей 50 и со временем подешевели рублей до 5 для безбоксовых вариантов. С того времени у меня осталось две больших коробки с записанными дисками. Время шло болванки дешевели и неожиданно мой хороший друг потратив какие то бешеные деньги купил пишущий dvdrom со скорость 2-4x записи, dvd болванки стоили тогда больше 100 рублей и покупать их было бедному студенту очень накладно.

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

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

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

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

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

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