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

В наш век общедоступных зеркальных и беззеркальных камер с разрешением матрицы от 16 мегапикселей и выше домашний фотоархив запросто может стать тем местом, где, как говорится, сам чёрт ногу сломит. В силу одних только размеров хранящихся в нём файлов, фотоархив запросто может забить не только диск ноутбука, но и средних размеров NAS или многодисковый внешний накопитель. Между тем, для фотографа, если он только не «бомбила», едва ли не всякий сделанный снимок имеет ценность; покажется сейчас, что вот эта вот нерезкая штуковина годится только для корзины, ан нет — через пару лет выяснится, что из этого снимка может выйти неплохой коллаж! О ностальгических воспоминаниях, привезённых в цифровом формате из Франции, Египта, с последнего звонка, со свадьбы троюродного брата первой тёщи в деревне Малые Дозы и так далее — я вообще не упоминаю. Это проходит по категории «хранить вечно».

Компания Backblaze опубликовала в своём блоге статистику использования дисковых накопителей в своих серверах. Backblaze предоставляет услугу дешёвого облачного бэкапа. В основе их инфраструктуры — жёсткие диски потребительского класса. За четыре года работы компания собрала порядочную статистику по отказоустойчивости разных типов дисков, использовавшихся в их хранилище. Парк накопителей Backblaze состоит в основном из дисков Seagate и Hitachi — почти по 13 тысяч. Ещё 2838 дисков — производства Western Digital, и по несколько десятков накопителей Samsung и Toshiba. Таким образом, данные Backblaze позволяют сравнить работу дисков потребительского уровня трёх производителей — Seagate, WD и Hitachi — в условиях датацентра.

Недавно я столкнулся с такой задачей: нужно было выполнить миграцию “на лету” виртуальной машины (ВМ), при том, что функция vMotion в имеющейся версии VMware vSphere отсутствовала. Мне успешно удалось решить эту проблему, и под катом я хочу поделиться моим решением, так как, думаю, это может пригодиться еще кому-то.

Как правильно спроектировать архитектуру хранилища резервного копирования виртуальной инфраструктуры? Прежде всего, нужно ответить на ключевой вопрос: “Что является главным приоритетом: минимизация использования дискового пространства, производительность или стоимость?” Ответ на этот вопрос определяет всю дальнейшую стратегию инвестирования в бэкап-инфраструктуру.



На рисунке изображен один из оптимальных вариантов архитектуры инфраструктуры резервного копирования. СХД «первой линии» (на рисунке — это Backup Storage, изображенный слева от линии передачи данных), расположенное в непосредственной близости от оригинальных данных продуктивной сети, должно быть максимально быстрым (например, оно может быть построено на SSD дисках), но оставаясь при этом разумным по цене. Чтобы достичь такой цели, это хранилище должно иметь размер, достаточный для хранения только тех данных, которые с наибольшей вероятностью могут быть истребованы для восстановления при системном сбое или по запросу пользователей продуктивной сети. Например, если по вашей статистике до 80% запросов на восстановление приходятся на данные, созданные, модифицированные или удаленные за последние 30 дней, то только эти данные и нужно хранить на СХД «первой линии». При выборе этого СХД нужно учитывать следующие рекомендуемые свойства:

Недавно вышла новая версия Veeam Explorer for Microsoft SharePoint с поддержкой Microsoft SharePoint 2013. Под катом можно узнать про функциональность новой версии, а также что такое гранулярное восстановление данных, в чем его отличие от полного восстановления, и в каких случаях разумно применять каждый из этих методов.

Введение

В области обеспечения непрерывности бизнеса существует много различных проблем, связанных с быстрым ростом данных в современных 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. Об этом и хотелось рассказать подробнее.