Есть ли хороший способ сделать резервную копию петабайта данных и сохранить его?

Я начинаю видеть клиентов с сотнями терабайт данных (в установках SQL Server). Поскольку общий объем данных на некоторых предприятиях приближается к значимым долям петабайта, я бы хотел собрать общую базу знаний, чтобы посмотреть, что люди, имеющие дело с таким количеством данных, делают для ее защиты.

Очевидная проблема заключается в том, что хранение нескольких резервных копий такого большого количества данных непозволительно дорого, используя хранилище корпоративного класса, черт возьми, даже просто RAID-5.

Я вижу следующие варианты:

1. Создайте зеркальную копию данных в другом центре обработки данных и постоянно отправляйте в нее различия (используя любой доступный механизм для вашего источника данных - например, доставку журналов или зеркальное отображение базы данных с SQL Server)
2. Регулярно создавайте резервные копии с использованием мощного алгоритма сжатия (возможно, только в том случае, если данные хорошо поддаются сильному сжатию)
3. Делайте частичные резервные копии критических / изменяющихся частей данных.
4. Не делайте резервных копий данных и не доверяйте богам коррупции.

Я вижу вариант № 4 принятым по умолчанию, и как эксперт HA / DR это действительно страшно, но что я посоветую в качестве альтернативы? Я думаю, что # 1 - лучший подход, но «я так не думаю» - обычный ответ, когда предлагаются какие-либо альтернативы, кроме # 4 и, возможно, # 3.

Теперь, конечно, это зависит от скорости изменения и критичности данных. Не нужно отвечать на это, так как я отвечал за все функции высокой доступности SQL Server, когда работал в Microsoft, поэтому я хорошо разбираюсь в аргументах «все зависит» - это моя ключевая фраза :-)

Мне было бы очень интересно услышать о любых альтернативах, которые я пропустил, или услышать, что все остальные находятся в одной лодке, и нет никакой реальной альтернативы тратить много денег на большее хранение.

Заранее спасибо - должное будет уделено всем хорошо продуманным и выраженным ответам.

Идея вне стены - нужна ли вся хранимая информация или даже полезна?

Сколько на самом деле стоит информация? Очевидно, что смешно тратить на содержание и управление больше, чем стоит данных.

Подходят ли данные в базе данных для хранения в базе данных? Например, действительно ли хранение сжатых файлов размером в несколько гигабайт в базе данных организации поддержки дает реальную выгоду?

Много ли дублированных данных в базе данных? Например, хранят ли тысячи людей по десять экземпляров еженедельного информационного бюллетеня по 10 МБ?

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

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

Да, еще один вариант - виртуализация хранилища: устройство, которое находится между вашими серверами и сетью хранения данных, например IBM SVC. SVC управляет копиями SAN-SAN и может выполнять удаленную репликацию (хотя это очевидно довольно болезненно на уровне петабайта, если у вас не очень низкие скорости изменения данных и действительно высокая пропускная способность).

Отличная часть в том, что весь процесс невидим для задействованных серверов. Если вы используете SQL Server, вы проектируете свои файловые группы так, чтобы хранить вещи с низкой скоростью изменения (например, архивы продаж более 3 лет назад) и вещи с высокой скоростью изменения (например, текущие продажи) в отдельной файловой группе. Они даже не должны быть полностью доступны только для чтения - вы просто хотите спроектировать его так, чтобы вы могли использовать разные методы репликации для каждой файловой группы. Механизм SAN может синхронизировать LUN через сеть, ленту или через SAN - это означает, что вы можете отправлять части SAN туда и обратно. Это более эффективно с механизмом, подобным LeftHand, где SAN состоит из пула участвующих единиц.

Затем вы можете автоматически синхронизировать материал с низкой скоростью изменения по проводам и синхронизировать высокую скорость изменения с sneakernet. (Звучит так, будто я получил это задом наперед, но это правда - вы не можете синхронизировать материал с высокой скоростью изменения по проводам из-за громкости.) Даже некоторые из низкоуровневых передач теперь поддерживают это: LeftHand позволяет вам копировать на другие Блоки LeftHand в вашем центре обработки данных, а затем отправьте их в свой внешний центр обработки данных. Подключите их, присоедините их к удаленной стороне, изменив IP-адреса и группы, и теперь они являются частью вашей удаленной резервной сети SAN. Ситуация с продажами LeftHand просто великолепна: настройте два своих SAN бок о бок в первичном центре обработки данных, синхронизируйте их, затем вы можете отправить их части в удаленный центр обработки данных, в то время как некоторые из них остаются в вашем текущем ЦОД для синхронизации. Постепенно двигайся

Я не сделал этого на уровне петабайта, все же. Вы знаете, что они говорят - в теории, в теории и на практике это одно и то же. На практике...

Вариант 1 - зеркальное отображение, которое почти так же плохо, как и № 4: любая ошибка, которая повреждает данные и не обнаруживается немедленно, повредит обе копии.

Если данные имеют решающее значение, рассмотрите специальные решения; читать о продуктах IBM Shark, например, или конкурирующих продуктах от EMS и т. д. Они имеют такие функции, как Flash-копия, которые позволяют мгновенно создавать логическую копию файла без удвоения требований к диску; и затем вы можете сделать резервную копию этой копии (например) на ленте. Посмотрите на резервное копирование роботизированной ленты.

Укажите тем, кто хочет хранить петабайт данных, хранение которых не из дешевых.

Мне так надоело, что люди жалуются на то, что у них нет лишних терабайт в онлайн-хранилище, потому что диск дешевый - диск может быть, но управляемое хранилище наверняка нет.

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

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

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

Интересное видео, детализирующее архитектуру myspace.com (серверная часть SQL2005). Не уверен, что у них есть отдельные петабайтные БД, поскольку они масштабируются несколькими БД. Они используют резервные копии SAN Snap.

http://wtv.watchtechvideos.com/topic70.html

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

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

Другой способ заключается в использовании программного обеспечения Solaris Cluster, где (при условии достаточной пропускной способности сети) вы можете иметь прямое зеркалирование между двумя серверами, а если один из них выйдет из строя, второй может вступить во владение. Это больше для использования там, где важна высокая доступность (HA), но я думаю, что большинство мест с таким большим количеством данных хотят HA.

И вы говорите, что ZFS не поддерживается в Windows, обычное место, где вы можете найти sqlserver, возможно, вы запускаете Sun / ZFS на бэкэнде и подключаетесь через iSCSI. Может быть, это и ужасная идея, но, по крайней мере, стоит подумать, чтобы вы знали, чего не следует делать.

Вы смотрели на Amazon Glacier как вариант?

IMO, если у вас нет какого-то оборудования уровня Годзиллы, если у вас есть столько данных, вам следует использовать технологию сжатия резервных копий. Я больше всего знаком с LiteSpeed, но есть аналогичные продукты других производителей и (конечно) похожая функция встроена в SQL2008. Вы можете не получить сжатие 10 к 1, но оно снижает требования к хранилищу для резервной копии, а также может уменьшить требования к окну резервного копирования. Если ваша цель состоит в том, чтобы сохранить несколько наборов резервных копий (вчера плюс предыдущий день, плюс один с прошлой недели и один с прошлого месяца, или ряд различий плюс полные данные, которые могут стать достаточно большими, если вы измените много данных в база данных), это просто вопрос места для хранения.

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

Если требуется отказоустойчивый сайт, в дополнение к размышлениям о Database Mirror) вы можете обратиться к поставщику хранилища данных ваших клиентов, чтобы узнать, предлагают ли они что-то вроде SRDF, который представляет собой аппаратную технологию репликации данных. Естественно, репликация (любого рода, но особенно репликация в реальном времени или почти в реальном времени) не заменяет резервные копии.

Я не думаю, что у вас есть большой выбор здесь на ленте против диска. Лента вряд ли обрежет его в обычном окне резервного копирования, если вы не удалите его, и я не уверен в надежности.

Итак, вы приступили к резервному копированию дисков. Вы версии? Значит, вы беспокоитесь о том, чтобы вернуться к резервной копии 2 (текущая дБ минус 2 резервных копии)? Или бэкап 3? В этом случае у вас могут возникнуть проблемы, но, скорее всего, вам придется обрабатывать резервные копии журналов, а не столько резервных копий данных.

Если вы можете разделить некоторые данные как доступные только для чтения / без изменений, то, возможно, у вас есть управляемые размеры резервных копий / окна. Или, по крайней мере, вы надеетесь, что технология резервного копирования и пропускная способность не отстают от роста объема данных.

Я не думаю, что вы копируете столько же, сколько храните 2-ую копию, чтобы устранить проблемы с основной записью. Это означает аппаратное обеспечение, повреждение и т. Д., И вы ежедневно молитесь, чтобы ошибки не отправлялись во вторую копию. Скорее всего, копии делаются SAN-SAN с использованием технологии моментальных снимков. хотя оригинальная копия может быть через Fed-Ex, а не через провод. Пропускная способность для перемещения 100 ТБ не легко найти никому.

Я думаю, что вам нужна комбинация 1, 2 и 3 (не 4), с отличным управлением резервного копирования журнала.

На самом деле я думаю, что в любой момент вы действительно просматриваете 3 копии своих данных. Запуск CHECKDB на 1 из копий, в то время как 2-я копия используется для фактического получения изменений. Затем вы снимаете эту 2-ю копию на первую и продолжаете. С таким большим количеством данных, я полагаю, что вам нужно немного усердия здесь. Пол, как checkdb работает на многопользовательском, 100 ТБ, который находится в сети?

Как уже упоминалось, не важны ли резервные копии журналов и, возможно, программа чтения журналов? Вам не нужно восстанавливать удаленные таблицы / пользовательские ошибки из журналов, а не из резервной копии? Вы можете сократить это, отправив копии SAN с некоторой задержкой, но я не видел эту технологию. SAN доставки журналов, который может задержать изменения на 4 часа (или некоторый интервал), чтобы вы могли устранить неполадки перед перезаписью данных. Или какой-нибудь инструмент чтения журнала SAN-block-changes? Без этого вам необходимо управлять этими журналами транзакций, что может быть совершенно другим уровнем отслеживания этих резервных копий в различных файловых системах в течение нескольких часов, чтобы вы могли потенциально восстанавливаться после нефатальных ошибок.

Технически, хранение является дешевым, но и на уровне петабайт, не так много. Это действительно зависит от приложения, но я бы сказал, что некоторая комбинация стратегий № 2 и № 3 будет ответом, с № 2 для данного и № 3 в зависимости от того, сколько инвестиций вы можете сделать в хранилище и типа хранение и ввод-вывод / вычислительные мощности, которые позволят вам избежать минимального приращения и максимально осторожного полного резервного копирования.

В качестве альтернативы может появиться что-то вроде Amazon S3, в зависимости от вашей пропускной способности и количества изменений в данных - на этом томе, по крайней мере, некоторые из них будут размещаться на чужих серверах и позволять им беспокоиться об избыточности. экономически эффективным.

Поговорите с вашим поставщиком хранилища, у него будет продукт дедупликации, который он использовал ранее, в сочетании с регулярным сжатием, вы часто можете уменьшить объем данных на 70%. Конечно, любой, у кого есть деньги на петабайтное хранилище, также может иметь бюджет, чтобы купить достойное решение для резервного копирования - если этого не произойдет, вам просто нужно спросить его, что потеря этого петабайта будет стоить их бизнесу.

В крупном корпоративном хранилище данных большая часть данных поступает из источников, для которых уже созданы резервные копии. Я работал над установками Teradata и ODW, где они выбрали вариант № 4, но я знал, что они могут восстановить один-два дня транзакционных данных и преобразовать их из исходных систем.

У одного розничного клиента (в то время у него был один из 5 крупнейших DW в мире, около 200 ТБ ... дает представление о том, как давно это было), они выбрали вариант № 1 после покупки нового петабайта. сервер Teradata. Старые узлы будут использоваться для снимка системы предыдущего дня, в то время как новые поддерживали существующую. Это было также хорошо с точки зрения аварийного переключения - время от времени они сводили все это на техническое обслуживание, и мы просто переключались на использование старого медленного сервера с однодневными данными.

Хотя, честно говоря, казалось, что это требует больших затрат на обработку / хранение / и т. Д., Особенно когда самым большим преимуществом было то, что их администраторам и специалистам NCR приходилось работать меньше вечеров, чтобы выполнять нерегулярное обслуживание.