Можно ли использовать снимки NetApp в качестве резервных копий?

Резервные копии выполняют две функции.

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

Нет политики хранения

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

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

Рассмотрим эту ситуацию:

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

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

Резюме

Снимки NetApp не защищают вас от реальной потери данных. Ошибочно удаленный том или потеря данных на фильтре потребует от вас восстановления данных.

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

Они есть а резервное копирование, да. Я лично раньше использовал их вместо ежедневных инкрементов, но мы по-прежнему делали еженедельные полные записи на ленту.

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

Они не защищают от катастрофических аппаратных сбоев самого netapp. Насколько я понимаю, SnapMirror действительно копирует все данные (в моментальном снимке) в другой фильтр [1], поэтому SnapMirroring в другой фильтр должен защитить этот набор данных от катастрофического отказа одного фильтра.

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

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

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

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

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

Ты должен пойти читать @Бэзилотличный ответ прямо сейчас, но вот мои два цента:

Снимки не поддерживаются приложением

Тот факт, что вы делаете снимок базового тома хранилища, не означает, что данные на этом томе можно восстановить. MS SQL - отличный пример этого - вам необходимо убедиться, что ваша база данных согласована с транзакциями, прежде чем делать снимок хранилища, которое она использует, иначе как @freiheit упомянул, что вам не лучше, чем восстанавливаться после тяжелой неудачи. Администраторы баз данных любят использовать разные LUN ​​для разных частей SQL, чтобы лучше использовать систему хранения, временные базы данных в быстром хранилище, системные базы данных в более медленном хранилище, данные только для чтения или архивированные данные в хранилище больших объемов и рабочие данные где-то посередине. Если вы просто делаете снимки этих томов, это очень вряд ли вы сможете восстановить свою базу данных.

NetApp предоставляет ряд инструментов Snap, которые позволяют делать снимки приложениям. SnapManager для SQL обеспечивает такую ​​осведомленность. Я считаю, что в экосистеме Microsoft есть также инструменты SnapManager для Exchange и SharePoint. SnapDrive не поддерживает это приложение. Он просто предоставляет удобный способ управления хранилищем в гостевой системе.

Если вы храните все данные и конфигурацию IIS на LUN и делаете снимки этих LUN напрямую, вы не можете гарантировать, что данные можно будет восстановить. Спроси меня, откуда я знаю ...

Несколько типов хранилищ могут иметь разные расписания моментальных снимков

Если вы по-разному представляете хранилище на своих серверах, это может усложнить ваш снимок и картину восстановления. NetApp ONTAP - это многопротокольное предложение, и вполне возможно, что вы используете более одного метода или типа хранилища для конкретного сервера. В нашем магазине некоторые из наших серверов получают свои диски C: \ через хранилище данных на основе NFS, а их диски «хранилища» - через логические модули с необработанными устройствами. Мы делали снимки логических модулей RDM, но не хранилищ данных на основе NFS. Это сделало восстановление сервера, трудно.

Снимки не имеют гарантированной политики хранения

Очередной раз, @Бэзил действительно хорошо покрывает это, но стоит повторить. Можно пополнить ваш Snap Reserve таким образом, чтобы Snpashot Autodelete удалял снимки, которые не устарели естественным образом для удаления. Очередной раз. Это может быть очень плохо, если вы или ваши клиенты ожидаете, что будут доступны снимки за три недели.

Снимки встроены

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

Снимки позволяют продолжать неправильные методы работы

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

А потом снимки! Нам не нужно отступать и рассматривать некоторые из наших основных методов работы, потому что мы можем просто сделать снимок всех наших серверов! И мы можем использовать SnapMirror для перемещения этих снимков за пределы площадки, чтобы использовать их в качестве резервных копий!

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