Можно ли использовать снимки NetApp в качестве резервных копий?
Наш магазин очень сильно зависит от объемных снимков NetApp для резервного копирования. Мы используем традиционные агентные резервные копии на магнитной ленте для некоторых наших данных, но в целом мы полагаемся на моментальные снимки для большинства наших систем. Кроме того, у нас нет строгой политики управления изменениями или какого-либо централизованного управления конфигурацией, поэтому все наши серверы, независимо от того, будут ли созданы резервные копии данных, предоставляемых их службами, необходимо будет восстановить с нуля (и без какой-либо реальной документации). Естественно, это делает снимки очень привлекательным предложением для управления, потому что мы можем просто восстановить весь сервер, пользовательские данные и конфигурацию. Мы используем консоль виртуального хранилища NetApp для создания снимков наших хранилищ данных VMware на основе NFS и SnapDrive NetApp для физических (LUN) сопоставленных устройств, которые предоставляются непосредственно гостям. Мы снимаем критические моментальные снимки SnapMirror вне сайта другого Filer. Естественно, мы регулярно проверяем наш процесс восстановления.
Я не могу не чувствовать себя неудобно с нашей зависимостью от снимков на резервных копиях. Для меня, чтобы технология считалась достаточной в качестве стратегии резервного копирования, она должна соответствовать следующим критериям:
- Резервная копия должна быть атомарной. То есть резервная копия не может полагаться ни на что другое для восстановления.
- Резервная копия должна быть отделена от системы, из которой она создана (вне диапазона).
- Резервная копия должна быть скопирована или перенесена на удаленный сайт (вне сайта)
Насколько я понимаю, моментальные снимки NetApp работают по методологии Redirect-On-Write (RoW). В макете файла WAFL используется набор указателей (метаданных?), Которые фактически ссылаются на каждый блок хранилища, где бы он ни находился. Чтобы сделать снимок, система просто берет копию метаданных тома и сохраняет ее в зарезервированном пространстве этого тома. Любые записи (создания / изменения / удаления) перенаправляются в новые блоки. Предполагается, что это особый соус, который делает WAFL NetApp таким замечательным, потому что вам не нужно читать, а затем записывать старые данные в зарезервированное пространство, а затем записывать новые данные поверх старых, таких как снимки типа "Копировать при записи".
Я полностью признаю, что, возможно, не совсем понимаю, как работают моментальные снимки NetApp Volume, но если мое понимание более или менее верно, моментальные снимки NetApp не соответствуют моим критериям для резервного копирования.
- Они не атомные. "Снимок" - это просто набор указателей на исходные данные. Если исходных данных больше нет, метаданные бесполезны.
- Снимок не отделен от системы. Если кто-то удаляет неправильный том, я теряю снимок. Если NetApp Filer взорвется на маленьких маленьких котят, я потеряю резервную копию. Я могу использовать SnapMirror, чтобы переместить мои снимки в другой Filer, но опять же, это просто перемещение метаданных, а не фактических блоков. Если я потеряю исходный том, я не могу понять, как снимок, скопированный на другой файлер, поможет.
Может кто-нибудь объяснить, как снимки NetApp можно считать резервными копиями? Я ищу хорошие субъективные ответы, поэтому, пожалуйста, подкрепите вашу позицию фактами, ссылками и опытом. Если мое понимание лежащей в основе технологии неверно, пожалуйста, объясните, где и почему это меняет мой вывод. Если ваш магазин использует снимки NetApp в качестве резервных копий, пожалуйста, включите достаточное количество контекстной информации, чтобы люди могли понять, какую политику восстановления вы должны выполнить.
3 ответа
Резервные копии выполняют две функции.
- Прежде всего, они позволяют вам восстановить ваши данные, если они становятся недоступными. В этом смысле снимки не являются резервными копиями. Если вы потеряете данные в файлере (удаление тома, повреждение хранилища, ошибка прошивки и т. Д.), Все снимки для этих данных также исчезнут.
- Во-вторых, и гораздо чаще, резервные копии используются для исправления таких рутинных вещей, как случайное удаление. В этом случае снимки являются резервными копиями. Возможно, они являются одним из лучших способов обеспечить такое восстановление, поскольку они делают более ранние версии данных доступными непосредственно для пользователей или их ОС в виде скрытого каталога.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
Вы должны прочитать отличный ответ Basil прямо сейчас, но вот мои два цента:
Снимки не распознаются приложением
Тот факт, что вы делаете снимок базового тома хранения, не означает, что данные на томе подлежат восстановлению. MS SQL является отличным примером этого - вам нужно убедиться, что ваша база данных согласована с транзакциями, прежде чем freiheit хранилище, которое она использует, в противном случае, поскольку freiheit упомянул, что вы не лучше, чем восстанавливаться после сбоя жесткого сбоя. Администраторы баз данных любят использовать разные LUN для разных частей SQL, чтобы лучше использовать систему хранения, временные базы данных в быстром хранилище, системные базы данных в более медленном хранилище, данные только для чтения или архивные данные в массовом хранилище, а также рабочие данные где-то посередине. Если вы просто снимаете эти тома, то вряд ли вы сможете восстановить свою базу данных.
NetApp предоставляет ряд инструментов Snap для информирования о приложении моментальных снимков. SnapManager for SQL обеспечивает эту осведомленность. Я полагаю, что в экосистеме Microsoft есть инструменты SnapManager для Exchange и SharePoint. SnapDrive не имеет этой осведомленности о приложении. Это просто удобный способ управления хранилищем в гостевой системе.
Если вы храните все свои данные и конфигурацию IIS на логических устройствах и снимаете их непосредственно, вы не можете гарантировать, что данные будут восстановлены. Спроси меня, откуда я знаю...
Несколько типов хранилищ могут иметь разные графики снимков
Если вы представляете хранилище на свои серверы различными способами, это может усложнить ваш снимок и картину восстановления.NETApp's ONTAP is a multi-protocol offering and it is very possible you are using more than one method or storage type for a particular server. In our shop some of our server's get their C:\ drive over an NFS-based datastore and their "storage" drives over Raw Device Mapped LUNs. We were taking snapshots of the RDM LUNs but not the NFS-based datastores. This made recovering the server, difficult.
Snapshots do not have a guaranteed retention policy
Again, Basil really covers this well but it's worth reiterating. It is possible to fill up your Snap Reserve in such a way where Snpashot Autodelete removes snapshots that have not naturally aged to deletion. Снова. This can be really bad if you or your customers are expecting three weeks of snapshots to be available.
Snapshots are inline
This is the drawback of integrated storage... it's well... integrated. Your snapshots reside on the same platform you are backing up. If the volume or the Filer it is on disappears so does your backup. You can mitigate this somewhat by copying the snapshots to another Filer using SnapMirror as I erroneously stated in my question that the SnapMirror copy is not a full copy.
Snapshots enable bad operational practices to continue
One thing that I have noticed is that snapshots enable managers and customers to continue terrible operations behavior. In our environment we have very poor documentation and configuration management practices. This means that most servers start with the same base (a template or an image) but are then configured manually by different groups of people. As they continue their life, the servers diverge further and further from the template in ways that are generally not documented or implemented with configuration management.
And then come snapshots! We don't need to step back and address some of our fundamental operational practices because we can just snapshot all our servers! And we can use SnapMirror to move those snapshots off-site so we can use them as backups!
I think this is the wrong lesson to learn here. A better lesson to learn is that the configuration management framework, even if it is as simple as a changelog, should be backed up for the purposes of bare-metal restore. Snapshots are a fantastic tool but I can there is a temptation to be overly reliant on them to the determent of important fundamentals.