Снимки NetApp могут использоваться в качестве Резервных копий?
У меня было некоторое выполнение проблем aptitude safe-upgrade на живом (некритическом) сервере. Иногда, когда пакеты обновлены как postgesql или mysql или другие сервисы, они перезапущены. Если приложения, которые используют те сервисы, не реагируют хорошо на базу данных, исчезающую из-под них, у Вас могут быть проблемы.
Конкретно я нашел, что мои направляющие, которые подвешивают 3 приложения с помощью продолжения в качестве ORM и postgresql как DB, когда postgresql перезапущен, не останавливая направляющие сначала. Это - ошибка, но это происходит.
Резервное копирование выполняет две функции.
- Прежде всего, они нужны для того, чтобы вы могли восстановить данные, если они станут недоступны. В этом смысле моментальные снимки не являются резервными копиями. Если вы потеряете данные в фильтре (удаление тома, повреждение хранилища, ошибка прошивки и т. Д.), Все моментальные снимки для этих данных также будут удалены.
- Во-вторых, и гораздо чаще, резервные копии используются для исправления таких рутинных вещей, как случайные удаления. В этом случае снимки представляют собой резервные копии . Это, возможно, один из лучших способов обеспечить такое восстановление, поскольку они делают более ранние версии данных доступными непосредственно для пользователей или их ОС в виде скрытого каталога .snapshot, из которого они могут напрямую читать свои файлы.
Нет политики хранения
Тем не менее, хотя у нас есть снимки и мы их широко используем, мы по-прежнему выполняем ночные инкременты по Netbackup на ленту или в домен данных. Причина в том, что моментальные снимки не могут надежно поддерживать политику хранения. Если вы скажете пользователям, что они смогут выполнять резервное копирование с ежедневной гранулярностью в течение недели, а затем с еженедельной гранулярностью в течение месяца, вы не сможете сдержать это обещание с помощью снимков.
На томе Netapp со снимками удаленные данные содержались в моментальном снимке занимает «резервное» пространство. Если том не заполнен и вы настроили его таким образом, вы также можете протолкнуть этот резерв моментальных снимков и получить моментальные снимки, которые занимают часть неиспользуемого пространства данных. Однако, если том заполняется, все снимки, кроме тех, которые поддерживаются данными в зарезервированном пространстве, будут удалены. Удаление снимков определяется только доступным пространством для снимков, и если ему необходимо удалить моментальные снимки, необходимые для вашей политики хранения, он это сделает.
Рассмотрим эту ситуацию:
- Полный том с регулярными моментальными снимками и требованием к хранению в течение 2 недель.
- Предположим, что половина резерва находится в использовать для моментальных снимков на основе нормальной скорости изменения.
- Кто-то удаляет много данных (больше, чем резерв моментального снимка), резко увеличивая скорость изменения, временно.
На этом этапе ваш резерв моментального снимка полностью использован , как и столько свободного места для данных, которое вы позволили OnTap использовать для моментальных снимков, но вы еще не потеряли ни одного снимка. Однако как только кто-то заполнит том резервной копией данными, вы потеряете все моментальные снимки, содержащиеся в разделе данных, что вернет вашу точку восстановления к моменту сразу после большого удаления.
Резюме
Снимки NetApp не работают t защитит вас от реальной потери данных. Ошибочно удаленный том или потеря данных на фильтре потребует от вас восстановления данных.
Это очень простой и элегантный способ обеспечить простое рутинное восстановление, но они недостаточно надежны, чтобы заменить реальное решение для резервного копирования. В большинстве случаев они делают рутинное восстановление простым и безболезненным, но когда они недоступны, вы подвергаетесь опасности.
Это резервная копия , да. Раньше я лично использовал их вместо ежедневных инкрементов, но мы по-прежнему еженедельно заполняли ленту.
Они довольно хорошо защищают от любых ошибок или проблем пользователей или администраторов, не связанных с 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
Вам следует прочитать @Basil прямо сейчас отличный ответ, но вот мои два цента:
Снимки не зависят от приложений
То, что вы делаете снимок базового тома хранилища, не означает, что данные на этом томе можно восстановить . MS SQL - отличный пример этого - вам нужно убедиться, что ваша база данных согласована с транзакциями, прежде чем делать снимок хранилища, которое она использует, иначе, как @freiheit упомянул, что вам не лучше, чем восстановление после тяжелого спада неудача. Администраторы баз данных любят использовать разные LUN для разных частей SQL, чтобы лучше использовать систему хранения, временные базы данных в быстром хранилище, системные базы данных в более медленном хранилище, данные только для чтения или архивные данные в хранилище больших объемов и рабочие данные где-то посередине. Если вы просто делаете снимки этих томов, это очень маловероятно, что вы сможете восстановить свою базу данных.
NetApp предоставляет ряд инструментов Snap, чтобы сделать снимки доступными для приложений. SnapManager для SQL обеспечивает такую осведомленность. Я считаю, что в экосистеме Microsoft есть также инструменты SnapManager для Exchange и SharePoint. SnapDrive не поддерживает это приложение. Он просто предоставляет удобный метод управления хранилищем в гостевой системе.
Если вы храните все данные и конфигурацию IIS на LUN и делаете снимки этих LUN напрямую, вы не можете гарантировать, что данные можно будет восстановить. Спросите меня, откуда я знаю ...
Несколько типов хранилищ могут иметь разные расписания моментальных снимков
Если вы по-разному представляете хранилище на свои серверы, это может усложнить вашу картину моментального снимка и восстановления. NetApp ONTAP - это многопротокольное предложение, и вполне возможно, что вы используете более одного метода или типа хранилища для определенного сервера. В нашем магазине некоторые из наших серверов получают свои диски C: \ через хранилище данных на основе NFS, а их диски «хранилища» - через логические модули Raw Device Mapped. Мы делали снимки логических модулей RDM, но не хранилищ данных на основе NFS. Это затрудняло восстановление сервера .
Снимки не имеют гарантированной политики хранения
Опять же, @Basil действительно хорошо справляется с этим, но стоит повторить еще раз. Можно пополнить резерв снимков таким образом, чтобы Snpashot Autodelete удалял снимки, которые естественным образом не устарели для удаления. Еще раз. Это может быть очень плохо, если вы или ваши клиенты ожидаете, что будут доступны снимки за три недели.
Снимки встроены
Это недостаток интегрированного хранилища ... оно хорошо ... интегрировано. Ваши снимки хранятся на той же платформе, для которой выполняется резервное копирование. Если том или Filer, на котором он установлен, исчезают, ваша резервная копия исчезает. Вы можете несколько смягчить это, скопировав снимки в другой Filer с помощью SnapMirror, поскольку я ошибочно указал в своем вопросе, что копия SnapMirror не является полной копией.
Моментальные снимки позволяют продолжать плохие методы работы
Я заметил одну вещь: снимки позволяют менеджерам и клиентам продолжать ужасное поведение. В нашей среде у нас очень плохая документация и методы управления конфигурациями. Это означает, что большинство серверов начинаются с одной и той же базы (шаблона или изображения), но затем настраиваются вручную разными группами людей. По мере того как они продолжают свою жизнь, серверы все дальше и дальше расходятся с шаблоном способами, которые обычно не документируются или не реализуются с помощью управления конфигурацией.
А потом снимки! Мы не Нет необходимости отступить и обратиться к некоторым из наших основных методов работы, потому что мы можем просто сделать снимок всех наших серверов! И мы можем использовать SnapMirror для перемещения этих снимков за пределы объекта, чтобы мы могли использовать их в качестве резервных копий!
Я думаю, что это неправильный урок, который нужно усвоить здесь. Лучший урок, который следует усвоить, заключается в том, что для инфраструктуры управления конфигурацией, даже если она такая простая, как журнал изменений, следует создавать резервные копии для целей восстановления с нуля. Моментальные снимки - фантастический инструмент, но я могу предположить, что есть соблазн чрезмерно полагаться на них при определении важных основ.
Лучший урок, который следует усвоить, заключается в том, что для инфраструктуры управления конфигурацией, даже если она такая простая, как журнал изменений, следует создавать резервные копии для восстановления с нуля. Снимки - фантастический инструмент, но я могу сказать, что есть соблазн чрезмерно полагаться на них при определении важных фундаментальных показателей. Лучший урок, который следует усвоить, заключается в том, что для инфраструктуры управления конфигурацией, даже если она такая простая, как журнал изменений, следует создавать резервные копии для целей восстановления с нуля. Моментальные снимки - фантастический инструмент, но я могу предположить, что есть соблазн чрезмерно полагаться на них при определении важных основ.