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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НО:

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

1. приложения имеют различные требования, связанные с восстановлением и допустимой потерей данных (некоторые из них налагаются различными правилами: носители только для чтения, шифрование, сохранение последних X лет и т. д.),
2. некоторые приложения имеют (очень) хорошие встроенные средства резервного копирования и восстановления (oracle, mssql) и представляют собой рекомендуемый способ выполнения резервного копирования / восстановления (в качестве администратора базы данных Oracle я предпочитаю и буду делать все свои резервные копии, связанные с Oracle с помощью rman).
3. рост, ваше использование пространства может расти гораздо быстрее, чем вы ожидаете, теперь эта система может обрабатывать данные отката за 30 дней, это не гарантируется в будущем
4. дешевле, после нескольких лет роста стоимость использования лент большего размера для размещения политик резервного копирования и восстановления будет меньше, чем стоимость покупки новых дисков большего размера, чтобы обеспечить то же окно отката, что и сейчас.