Моя организация недавно купила систему хранения. Он имеет 1,5 Петабайта, с RAID6, и есть онлайн-синхронизированное зеркало в другом физическом месте.
Система позволяет откат / восстановление файлов, по умолчанию до 30 дней, но этот срок можно увеличить.
Обсуждается, нужна ли нам какая-то дополнительная резервная копия для данных, хранящихся только в хранилище.
Система имеет очень хороший уровень избыточности, она имеет географическую избыточность и допускает до некоторой степени откат, что означает, что мы можем восстанавливать старые или случайно удаленные данные в течение определенного времени (30 дней по умолчанию).
Имеет ли смысл иметь «традиционную» резервную копию при таком сценарии? Под традиционным я имею в виду выделенную систему резервного копирования со снимками, которые мы можем получить, если что-то пойдет не так.
Это действительно нужно? Я что-то упускаю? Я просто мыслю традиционным образом и чрезмерно усердствую?
То, что вы описываете, важно: географически распределенный RAID и RAID никогда не был резервным.
Онлайн-синхронизация обычно означает, что все, что вы делаете в основном хранилище, немедленно реплицируется в систему резервного копирования, включая такие операции, как удаление (всех) моментальных снимков и / или томов злоумышленником или просто ошибка администратора.
30-дневный откат - отличная возможность, но что, если «критически-важный-файл-xyz» окажется поврежденным / поврежденным, и это не будет обнаружено до 31+ дня спустя? В этой ситуации есть разница между расписаниями резервного копирования и архивирования, но в вашем описании последнее не упоминается. Архивные системы обычно хранятся на очень недорогой ленте. Также отсутствует информация о том, имеет ли компания нормативные или иные требования по хранению данных более 30 дней, что часто имеет место.
Если в вашей ситуации это не так, тогда все будет хорошо.
Хорошо иметь географически разделенные машины, у которых есть данные.
Что произойдет, если у вас будет несколько сбоев на обоих или всех ваших сайтах? Пожар на одном, кража серверов на другом? Или возникла проблема с линией между ними, затем сервер основного местоположения отключается, а контроллер HD сходит с ума и пишет барахло? Или какой-то инсайдер злонамеренно действует на обоих? Или ФБР конфискует ваши серверы в обоих местах из-за подозрений (вы никогда не сделаете этого, но, возможно, вы находитесь в центре обработки данных вместе с шмаками). Или .. Мне вспоминается несколько громких «облачных» отключений, где все было избыточно, проанализировано до энной степени, но, тем не менее, что-то может пойти не так. Я допускаю, что все это маловероятно, но вы признали, что маловероятные вещи могут случиться.
Итак, все сводится к тому, насколько важны / ценны эти данные? Что будет делать организация, если она исчезнет?
Вопрос здесь, по-видимому, заключается в том, насколько отключенной и географически отличной должна быть реплицированная копия ваших данных, прежде чем она станет резервной, а не инфраструктурой высокой доступности / избыточности. Мне кажется, что вы близки, но вам все еще нужна подстраховка.
Чтобы собрать воедино некоторые мысли в других ответах и комментариях, вы можете пойти очень далеко по пути «ну, технология X не покрывает сценарий катастрофы Y, так что это не резервная копия», и в какой-то момент вам нужно решить, что для вас разумно, и, похоже, именно поэтому вы спрашиваете. Мое мнение по этому поводу, и я думаю, что мнение многих комментаторов состоит в том, что ваша резервная копия должна существовать в отдельной технологической инфраструктуре от ваших используемых данных, чтобы сбои, аварии и вредоносные действия либо не могли распространяться, либо иметь гораздо более высокий барьер, который нужно преодолеть. В комментариях приведен пример, когда кто-то удаляет тома, что, на мой взгляд, является допустимым сценарием, а не сценарием «пирог в небе». Но, кроме того, реальный пример из моей работы. Университет, в котором я работаю (но, к счастью, не управляю этой инфраструктурой), имеет серьезную инфраструктуру виртуализации с высокой доступностью, которая поддерживает множество объектов кампуса. Он находится на нескольких сайтах, но все работает на платформе одного поставщика. Однажды возникла неясная ошибка, которая вызвала каскад сбоев, который сначала отключил один сервер, затем, когда нагрузка сместилась, он удалил остальную часть этого сайта, а затем, когда нагрузка снова сместилась, он отключил другие сайты, на которых размещались эта инфраструктура. (Я считаю, что с тех пор они решили эту проблему). В этом случае данные не были потеряны, но можно представить сценарий с вашими данными там, где они были.
Вы хотите, чтобы ваша резервная копия была невосприимчивой ко всему этому и даже была доступна, пока эта инфраструктура не работает. Если данные недоступны в течение недели, пока ваш RAID перестраивается, возможность восстановить важные бизнес-документы из резервной копии - это хорошо (хотя и не обязательно). Если ваш RAID исчезает, а затем реплицируется на другой сайт, вам действительно нужно, чтобы эта резервная копия была от отдельного поставщика или на каком-то изолированном носителе, таком как лента.
Все это говорит о том, что я еще раз повторю, что ваша резервная копия должна находиться в отдельной инфраструктуре от ваших данных. Здесь много уровней изоляции, но я думаю, что все, что связано с прямой репликацией, слишком близко, чтобы быть резервной копией. Вам понадобится еще кое-что.
Предположение: система хранения будет использоваться многими приложениями.
Я считаю, что вам будет намного лучше с отдельной системой резервного копирования.
RAID и зеркалирование не являются резервным копированием, но встроенная функция отката может заменить традиционную систему резервного копирования.
НО:
Я предпочитаю, чтобы политики восстановления основывались на приложениях / данных, а не на хранилище, потому что: