Нужно ли мне резервное копирование, если у меня есть резервная система хранения с возможностью отката?


32

Моя организация недавно купила систему хранения. Он имеет 1,5 петабайта, с RAID6, и есть физически синхронизированное зеркало в другом физическом месте.

Система позволяет выполнять откат / восстановление файлов, по умолчанию, до 30 дней, но это может быть увеличено.

Идет дискуссия, если нам понадобится какая-то дополнительная резервная копия для данных, хранящихся только в хранилище.

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

Учитывая этот сценарий, все еще имеет смысл иметь «традиционную» резервную копию? Традиционно я имею в виду выделенную систему резервного копирования со снимками, которые мы можем получить в случае, если что-то пойдет не так.

Нам это действительно нужно? Я что-то пропустил? Я просто думаю традиционным способом и слишком усердствую?


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

4
Определенно связанный, но, возможно, не прямой дубликат из-за географического разделения и возможности отката моментального снимка: почему RAID не резервная копия?
CVN

До тех пор, пока вы также удаляете клавишу «удалить» из каждой клавиатуры на месте, вы великолепны ;-)
Том Ньютон

1
Конечно, лучше, чем не иметь этого. Я все еще предпочел бы, чтобы резервные копии жили в среде от живых "ошибок людей". Тем не менее, вы знаете ответ на свой вопрос, но это требует установления цены на ваши данные. Удачи.
Том Ньютон

7
Ваша возможность «отката» также охватывает изменения в томах? Например, сможет ли он восстановиться, если кто-нибудь удалит все тома?
Ву

Ответы:


40

То, что вы описываете, является важным географически распределенным RAID, и RAID никогда не был резервной копией .

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


3
Или, поскольку оба хранилища, вероятно, используют одну и ту же ОС, программная ошибка может уничтожить данные. Не вероятно, ошибка администратора более вероятна, но возможна.
Сунци

8
Правда. Цель состоит в том, чтобы никто не смог управлять автоматическими снимками. Это должно дать уровень устойчивости к ошибкам. Конечно, можно также удалить резервную копию по ошибке.
nsn

2
@nsn Есть много других взаимосвязанных сбоев, таких как ошибки в программном обеспечении устройства или ошибки в ваших сценариях управления. Без резервной копии в другом месте вы доверяете свою работу продавцу ... Готовы ли вы сделать это? Также количественно определить ущерб в случае потери. Возможно, ответ зависит от того, насколько ценны данные. Компания ушла без этого?
USR

2
@ nsn > Конечно, можно также удалить резервную копию по ошибке. < - да, но это существенно усложняется, когда резервное копирование переводится в автономный режим и помещается, например, в безопасное внешнее хранилище.
Роб Мойр

7

30-дневный откат - это отличная возможность, но что, если «критически важный файл-xyz» был поврежден / поврежден, и это не было обнаружено до 31+ дней спустя? Эта ситуация - разница между резервным и архивным расписанием, но в вашем описании последнее не упоминается. Архивные системы обычно хранятся на очень дешевой ленте. Также нет информации о том, имеет ли компания нормативные или иные требования для хранения данных в течение более 30 дней, что часто имеет место.

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


3
Да, верно. 30 - это просто значение по умолчанию, мы можем установить другие значения. В любом случае, автономное хранилище также стоит денег и не вечно. Всегда будет день n + 1
nsn

2
Мне нравится кататься 30 дней, плюс ежемесячно за последний год, плюс годовой. У меня было несколько файлов (важных и старых), которые исчезли и не были обнаружены в течение скользящего периода времени. Ежегодные резервные копии могут быть спасителями.
Брайан Кноблаух

@BrianKnoblauch: Да, такая схема - хорошая идея для онлайн-снимков или автономных резервных копий.
Бен Фойгт

6

Хорошо иметь географически разделенные машины и данные.

Что происходит, когда у вас есть несколько сбоев, затрагивающих оба или все ваши сайты? Пожар на одном, кража серверов на другом? Или есть проблема с линией между ними, затем сервер основного местоположения выходит из строя, а контроллер HD выходит из строя и записывает ненужные файлы? Или какой-то инсайдер совершает злонамеренные действия на обоих? Или ФБР конфискует ваши серверы в обоих местах из-за подозрений (вы никогда этого не сделаете, но, возможно, вы совместно размещены в центре обработки данных с чмоками). Или .. Мне вспоминаются несколько громких «облачных» отключений, когда все было излишним, анализировалось в n-й степени, но, тем не менее, все может пойти не так. Я признаю, что все это маловероятно, но вы признали, что невероятные вещи могут произойти.

Итак, все сводится к тому, насколько важны / ценны эти данные? Что будет делать организация, если она в конечном итоге исчезнет?


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

2
Это идет навсегда. Каждый раз, когда вы добавляете уровень избыточности, вы всегда можете ожидать, что он выйдет из строя (географический или только дисковый). Если у вас есть n избыточных дисков, вы всегда можете спросить «что, если n + 1 сломается». Вы можете разжечь огонь в своей серверной комнате, а также в своей резервной комнате. Внутренние рабочие места могут также атаковать оба. Нет 100% отказоустойчивых систем. Суть в том, чтобы знать, может ли такая настройка быть эквивалентна «традиционному» серверу + резервное копирование
nsn

1
Я думаю, что @nsn имеет большое значение, но я также думаю, что урок многих из этих ответов заключается в том, что наличие вашей резервной копии в отдельной технологической инфраструктуре от носителя данных является хорошей идеей, поскольку она значительно усложняет технологический процесс. неспособность к распространению, и злому действующему субъекту сложнее заразить обоих (но просто сложнее). Мы регулярно видим ошибки в избыточных системах, которые вызывают каскады отказов. Помогает другое решение / поставщик. Это хеджирование еще продолжается, но я считаю, что уровень технологического разделения в большинстве случаев является разумной осторожностью.
Ник

@ Ник, я думаю, у тебя есть очень веский комментарий. Я бы сделал это ответом.
nsn

4

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

Чтобы объединить некоторые идеи и ответы в других ответах и ​​комментариях, вы можете пойти очень далеко по пути «ну, технология X не охватывает сценарий катастрофы Y, поэтому это не резервная копия», и в какой-то момент вам нужно решить, что для вас разумно, и именно поэтому вы спрашиваете. Я чувствую это и думаю, что многие комментаторы считают, что ваша резервная копия должна существовать в отдельной технологической инфраструктуре от используемых данных, чтобы сбои, аварии и вредоносные действия не могли распространяться или иметь намного более высокое препятствие, чтобы пересечь. Пример, приведенный в комментариях, - кто-то удаляет тома, что, по моему мнению, является действительным сценарием, а не сценарием в небе. Но кроме того, это реальный пример из моей работы. Университет, в котором я работаю (но, к счастью, не Управление этой инфраструктурой для) имеет серьезную инфраструктуру виртуализации с высокой доступностью, которая поддерживает множество объектов кампуса. Это на нескольких сайтах, но все работает на платформе одного поставщика. Однажды появилась неясная ошибка, которая привела к каскаду сбоев, который сначала приводил к отключению одного сервера, затем, когда нагрузка переместилась, он удалил остальную часть этого сайта, а затем, когда нагрузка снова сместилась, он удалил другие сайты, на которых размещался хост. эта инфраструктура. (Я считаю, что они решили эту проблему с тех пор). В этом случае данные не были потеряны, но можно представить сценарий, включающий ваши данные, где они были. Однажды появилась неясная ошибка, которая привела к каскаду сбоев, который сначала приводил к отключению одного сервера, затем, когда нагрузка переместилась, он удалил остальную часть этого сайта, а затем, когда нагрузка снова сместилась, он удалил другие сайты, на которых размещался хост. эта инфраструктура. (Я считаю, что они решили эту проблему с тех пор). В этом случае данные не были потеряны, но можно представить сценарий, включающий ваши данные, где они были. Однажды появилась неясная ошибка, которая привела к каскаду сбоев, который сначала приводил к отключению одного сервера, затем, когда нагрузка переместилась, он удалил остальную часть этого сайта, а затем, когда нагрузка снова сместилась, он удалил другие сайты, на которых размещался хост. эта инфраструктура. (Я считаю, что они решили эту проблему с тех пор). В этом случае данные не были потеряны, но можно представить сценарий, включающий ваши данные, где они были.

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

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


1

Предположение: система хранения будет использоваться многими приложениями.

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

RAID и зеркалирование не являются резервным копированием, но встроенная функция отката может заменить традиционную систему резервного копирования.

НО:

Я предпочитаю, чтобы политики восстановления были основаны на приложениях / данных, а не на хранилище, потому что:

  1. приложения имеют различные требования, связанные с восстановлением и допустимой потерей данных (некоторые из них налагаются различными правилами: носители только для чтения, шифрование, сохранение последних X лет и т. д.),
  2. некоторые приложения имеют (очень) хорошие встроенные средства резервного копирования и восстановления (oracle, mssql) и представляют собой рекомендуемый способ выполнения резервного копирования / восстановления (в качестве администратора базы данных Oracle я предпочитаю и буду делать все свои резервные копии, связанные с Oracle с помощью rman).
  3. рост, ваше использование пространства может расти гораздо быстрее, чем вы ожидаете, теперь эта система может обрабатывать данные отката за 30 дней, это не гарантируется в будущем
  4. дешевле, после нескольких лет роста стоимость использования лент большего размера для размещения политик резервного копирования и восстановления будет меньше, чем стоимость покупки новых дисков большего размера, чтобы обеспечить то же окно отката, что и сейчас.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.