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

Рынок ориентированных на хранение резервных копий дисковых СХД измеряется миллиардами долларов. На этом рынке работает довольно много известных компаний, выпускающих продукты, которые уже стали хорошо известны во всем мире: EMC DataDomain, Symantec NetBackup, HP StoreOnce, IBM ProtectTier, ExaGrid и другие. C чего начинался этот рынок, и в каком технологическом направлении он развивается сейчас, как сравнивать разные программные продукты и устройства дедупликации между собой?

Первые СХД с дедупликацией появились в начале 2000-х. Они были созданы для решения проблемы резервного копирования экспоненциально растущих данных. Рост данных в продуктивных системах компаний приводил к тому, что продолжительность резервного копирования на ленты увеличивалась настолько сильно, что полные резервные копии уже не «помещались» в окно резервного копирования, а применение в качестве бэкап-хранилища существовавших в то время дисковых СХД было затруднено из-за их недостаточной емкости. В результате бэкапы могли «обрываться» либо из-за недостатка времени (для случая лент), либо из-за недостатка места (для случая дисков). Проблему места на диске можно было решить покупкой СХД большой емкости, однако в этом случае возникала проблема высокой стоимости хранения.

Любой цифровой фотограф неоднократно встречался с ситуацией, когда флэшка со свежими снимками уже вставлена в слот компьютера или ридера, а места на рабочем диске нет. Это неприятно. Ещё неприятнее, когда два-три часа убито на переписывание предыдущих снимков на оптические диски, а потом выясняется задним числом, что часть файлов на них безнадёжно испорчена. С точки зрения фотографа (и самого искусства фотографии), каждый снимок уникален; потеря его эквивалентна потере мгновения чьей-то жизни, причём для фотографа эти мгновения могут сложиться в весьма чувствительное время: ведь снимок надо сделать, сохранить, обработать, распечатать, показать… Я уже не говорю о чисто материальных потерях, от коллекционных до финансовых, которыми гибель любого снимка чревата для коммерческого фотографа.

Доброго времени суток, уважаемое Хабросообщество!

В моей коллекции раритетных штучек стало на одну штучку больше — недавно я обзавелся бесперебойным блоком питания Athen IPS Card. И, как повелось, я вновь пишу о новоприбывшей железке небольшой обзор.

Однако, чем может быть интересен старый бесперебойник?
Казалось бы, за 24 года (а именно столько лет исполнилось бесперебойнику Athen IPS Card в этом году) в устройстве типичного UPS практически практически ничего не поменялось. Безусловно, современные источники бесперебойного питания стали гораздо меньше по размерам, чем их прародители, да и время их автономной работы увеличилось, но назвать эти изменения кардинальными у меня не поворачивается язык.



Но кто бы мог подумать, что во времена древних IBM PC XT, двоек и троек (286 и 386, а не то что вы подумали), существовали бесперебойники, которые не занимали места под столом и были невидимы для простого пользователя. Нет, это не научная фантастика и не нанотехнологии инопланетян, это суровая реальность начала 90-х в лице Athen IPS Card, произведенной фирмой SHENZHEN WATT ELECTRONICS.

Как вы уже наверно догадались, речь идет о внутреннем UPS с интерфейсом ISA, который обеспечивает надежное автоматическое резервное копирование данных из оперативной памяти на жесткий диск в случае внезапных перебоев с электричеством.

Одна из наиболее важных “фичей” у Hyper-V 2012 — функция репликации. Она позволяет в течение нескольких минут сделать работоспособную копию виртуальной машины (реплику) на другом сервере. В отличие от “классических” сценариев восстановлений после сбоя, реплика может быть использована для миграции виртуальной машины (ВМ) на новую инфраструктуру или в другой домен.

Но что если старый сервер работает на Windows Server 2008 R2? Как в таком случае переместить ВМ на новый Hyper-V 2012 R2? Если не хочется платить, то можно воспользоваться стандартной процедурой “экспорт/импорт”, но такая операция может потребовать нескольких минут для каждой ВМ в зависимости от скорости дисков, куда экспортируются данные.

Другой способ — это использование Veeam Backup & Replication, который позволяет создать задание для репликации ВМ (Replica Job) даже если версии ОС исходного и удаленного хостов различны.

Уже было много постов о резервном копировании, особенно много для ОС Linux. Озаботился и я настройкой резервного копирования.
Требовалось создавать бэкапы системы, данных с примонтированного раздела и LVM томов (диски виртуальных машин). Были мысли использовать Bacula, т.к. знаком с ней, но поскольку дома только 1 компьютер клиент-серверная архитектура только создавала бы дополнительные сложности при восстановлении в случае повреждения системы. Значит систему и данные просто копируем, образ LVM раздела создаем с помощью dd. Хотелось делать резервную каждый день (хотя бы данных) и хранить минимум 14 дней. Но поиски готовых и простых решений, удовлетворяющих всем потребностям не увенчались успехом. А значит берем в руки bash и пишем свой велосипед. В этой статье я делюсь тем, что вышло.

Facebook сообщил о создании петабайтного хранилища данных исключительно из Blu-ray дисков. В прошлом году компания заявила, что исследуют возможности Blu-ray, для использования в своих ДЦ, а во вторник показала прототип системы на Open Compute Project саммите в Сан-Хосе.

Эта система служит для хранения данных, которые «не должны быть востребованы» или для так называемого «холодного хранения». На практике речь идёт о бэкапах пользовательских видео и фотографий.

В наш век общедоступных зеркальных и беззеркальных камер с разрешением матрицы от 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, домена и приложений).

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