LUN на NetApp это НЕ “просто файл”!
Я уже рассказывал в этом блоге отчего, несмотря на то, что на хранилище NetApp вы видите LUN, то есть объект SAN-сети, как “файл”, лежащий на пространстве тома, LUN в NetApp делаются совсем НЕ через “эмуляцию поверх файловой системы”. Однако такая любопытная “оптическая иллюзия” с видимостью LUN-а как файла, часто приводит к определенным (к сожалению распространенным) ошибкам понимания, в частности к соблазну “сбэкапить” такой LUN как файл.
Так вот, обратите внимание, что из того факта, что на “зашаренном” volume вы видите LUN-ы на нем созданные как файлы, не следует, что “LUN-ы это файлы”.
Если вы, допустим, бэкапите такие LUN-ы, то бэкапить их надо ТОЛЬКО как содержимое volume, то есть от “корня”, вместе с томом, либо с qtree, если последний используется. ??наче вы потеряете при таком копировании metadata (они хранятся внутри volume), определяющие внутри NetApp LUN именно как LUN, и не сможете восстановить его на прежнее место как LUN, то есть как устройство с блочным доступом.
То есть, для бэкапа содержимого LUN, например это LUN01, лежащий на томе vol1, недостаточно просто скопировать “файл”, лежащий по адресу //filer1/vol1/LUN01, нужно копировать целиком vol1!
Аналогична ситуация и с восстановлением. Восстанавливать надо том вместе со всеми LUN-ами на нем, а не просто отдельный “файл” LUN-а, так как, в противном случае, не будут востановлены специфические метаданные SAN-объекта.
То есть, если вы сбэкапили LUN, а затем восстановили, и не можете смонтировать его как LUN, а видите его как “просто большой файл”, то это вот тот самый случай.
Разумеется, все изложенное выше касается только “бэкапа со стороны стораджа” (например по NDMP), а не бэкапа “изнутри” OS, работающей с данным, смонтированным на нее LUN-ом, как своей файловой системой.
Еще читать: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb37566
Чё-то не то. LUN’ы спокойно копируются командой ndmpcopy с тома на том, равно как и восстанавливаются из бэкапа по NDMP туда, куда скажешь. Ресторить целиком том не требуется.
Не знаю, зачем в статье на NOW красным выделили в скриншоте “maintaining existing structure” - это стандартная опция нетбэкапа, безотносительно NDMP. Я не пробовал играться с qtree, но восстанавливал без проблем по 3-му варианту (restore individual directories and files to different locations) на другой сторедж и другой том. Том был создан заранее и на нём уже лежали другие LUN’ы.
Всё вышесказанное относится, разумеется, только к NDMP. Слить LUN, например, по CIFS или NFS и подцепить его потом как диск, AFAIK, невозможно в принципе.
При использовании NetBackup не обязательно восстанавливать целиком том. Главное (как и сказано в статье) восстановить его либо в корень либо в qtree, и тогда метаданные будут (не ясно правда откуда, все-таки похоже на то что они создаются стораджем при выполнении каких-то условий).
Плюс, возможно даже в случае неправильного восстановления вылечить такой LUN создав клон, тогда метаданные ЛУНа будут созданы: https://kb.netapp.com/support/index?page=content&id=2012496. Лицензия flex_clone не нужна.
> Плюс, возможно даже в случае неправильного восстановления вылечить такой LUN создав клон
О! Возможно, это может помочь даже при тупом копировании по CIFS. Надо будет потестить.
А вот вопрос, немного в сторону. Никто не знает, какаие ещё устройства, кроме самого Нетаппа, смогут с ним общаться по NDMP?
Пробовал SUN Unified Storage 7000 - Нетапп меня послал, говорит, “удалённая система - не нетапп”.
Тоже захотел проверить, по CIFS у меня не получилось скопировать даже отмапленный и заоффлайненный ЛУН, “Access Denied”.
> А вот вопрос, немного в сторону. Никто не знает, какаие ещё устройства, кроме самого Нетаппа, смогут с ним общаться по NDMP?
Если речь про ndmpcopy - то никто, ndmpcopy это нестандартная, “внутренняя” функция, расширение протокола, в стандартную версию его не вошедшая.