Мой опыт работы с ZFS в целом показал, чтоэто просто работает, поэтому я ожидаю, что ответ будет таким: это не проблема, но у меня есть пул данных, который испортит мой январь, если он выйдет из строя, поэтому я хочу перепроверить.
Это вопрос, который может возникнуть в двух разных ситуациях, связанных с отдельным пулом данных. Прямо сейчас я имею дело с первым, но я также задавался вопросом о втором:
- Хранилище системного диска (то есть того, на котором находится
rpool) выходит из строя, но хранилище пула данных в порядке, поэтому вы хотите восстановить системный диск из резервных копий, но при этом просто продолжать использовать активное хранилище пула данных. - У вас запущен Solaris на виртуальной машине, и вы хотите выполнить откат к снимку, сделанному гипервизором (нетснимок ZFS
rpool), но пул данных хранится на дисках, которые находятся в «независимом» режиме, RDM и т. д., поэтому откат невозможен.
В обеих этих ситуациях при повторной загрузке Solaris он увидит пул данных, о котором знает, но который находится в состоянии, в которое он его никогда (насколько он помнит) не переводил.
Меня в первую очередь волнует только случай, когда система была аккуратно выключена перед тем, как системный диск был перемотан, и когда система была аккуратно выключена перед образом, на который она перематывается. Я бы ожидал, что переключение между запущенными состояниями может быть немного сложнее.
Обратите внимание, что в моем конкретном случае геометрия хранилища пула и пути к хранилищу не изменились. Опять же, я бы ожидал, что это будет сложнее, если бы они изменились.
Я бы даже не спрашивал об этом в случае с Windows и NTFS, потому что это сравнительно простая развязанная система, поэтому трудно понять, почему это так.не будетработа. Однако, похоже, что Solaris хранит какие-то метаданные пулаиз группы, о чем свидетельствует тот факт, что вы должны это делать, zpool exportкогда zpool importперемещаете пулы между системами (чего я никогда не делал таким образом благодаря VMware). Мои знания об этих метаданных и их назначении ограничены, поэтому мне сложно рассуждать о влиянии в этой ситуации. (Было бы здорово получить объяснение!)
На самом деле у меня все еще есть доступ к системе pre-rollback. Она находится в хранилище данных VMFS, поддерживаемом HP SmartArray, который выдал предупреждение POST 1716 после неудачной замены диска для профилактического обслуживания (которая привела к потере данных, поскольку SmartArray глупее ZFS). Все важные виртуальные машины по-прежнему выглядят нормально, и сканирование их файловых систем не обнаружило ошибок, но я в любом случае планирую восстановить массив из очень недавней резервной копии, поскольку у меня есть основания подозревать, что ESXiмолча обнуляет плохие сектора вместо передачи ошибок гостям, поэтому я не хочу рисковать тем, что где-то затаится какой-нибудь обнуленный сектор, который позже укусит меня за задницу.
Для Solaris VM мне не нужно беспокоиться о зануленных секторах, потому что ZFS это отловит, но большинство других VM используют тупые файловые системы. Резервная копия — это образ всего хранилища данных VMware, поэтому их исправление также откатит Solaris VM. На самом деле, я провел очистку этой rpoolVM, и она не нашла никаких ошибок, так что, черт возьми, если бы я хотел, я мог бы просто спрятать ее VMDK где-нибудь в другом месте и скопировать его обратно после отката, и тогда весь этот вопрос был бы спорным. Думаю, так я и сделаю, если никто не ответит, лол. Но это то, о чем я задавался некоторое время, так что я все равно спрошу.
Итак, вопрос в том,Могу ли я просто откатить хранилище системного диска и покончить с этим? Или мне придется экспортировать пул из системы до отката, откатиться, удалить пул перед присоединением его хранилища, затем присоединить хранилище и импортировать пул? Мне не нравится последний вариант, отчасти потому, что из этого пула обслуживаются и CIFS, и iSCSI, и я не помню наизусть, как я их настраивал или даже как это сделать, так что если они сломаются, я буду зол. (Вы можете сказать, что у нас нет штатного системного администратора? lol)
На виртуальной машине установлена старая версия Solaris 11.0.
(Кстати, он устарел отчасти из-за того же вопроса. Я хотел сделать снимок виртуальной машины перед попыткой обновления на случай, если я его сломаю, но потом я забеспокоился о том, как откатенная система может отреагировать на независимый пул, поэтому просто оставил его в покое. И да, я понимаю, что я также мог бы сделать снимок rpool, но это не даст того же уровня комфорта для того, кто не работает с Solaris ежедневно.)
решение1
Это один из тех ответов типа «zfs просто работает»...
Метаданные пула фактически хранятся в пуле, а не в локальной ОС. Так, например, если система выходит из строя и не завершает работу чисто, метаданные в пуле знают, что пул не был «экспортирован» чисто. Если бы вы попытались импортировать этот пул в новую систему, вы бы получили жалобы на то, что он не экспортирован и принадлежит другой системе. В этот момент вы бы просто выполнили zpool import -f (force), и он войдет чистым.
Итак, конкретно для вашего пула данных, данные на нем будут в безопасности, независимо от того, когда/где вы попытаетесь импортировать пул снова. Если вы загрузитесь в «восстановленный» rpool, ОС на этом rpool будет знать о пулах, которые она должна импортировать, и просто импортирует пул данных. Она не отслеживает, был ли экспортирован пул или нет, за исключением того факта, что после экспорта пула ОС вообще перестает за ним следить.
Теперь, что касается вопроса rpool. Восстановление из снимка виртуальной машины, резервной копии ленты, что угодно не изменит способ обработки пула данных, если только резервная копия не была сделана до того, как пул данных был создан или изначально импортирован. Если бы это было так, вы бы просто импортировали пул после восстановления ОС. Данные в пуле данных будут в безопасности, независимо от состояния rpool.
Надеюсь, это поможет.
Кстати, вы упомянули о своем нежелании обновлять solaris, потому что не были уверены, как он отреагирует на пул данных. Не беспокойтесь об этом. Обновление сохранит известные пулы и импортирует их по мере необходимости.
Также обратите внимание, что обновления ОС Solaris являются автономными в отдельных «загрузочных средах (BE)». Таким образом, когда вы делаете обновление ОС, оно фактически создает полностью независимую установку ОС, содержащую новую версию... все это время ваша ОС все еще работает. Затем, когда вы перезагрузитесь, она появится в новой ОС. Если возникнут проблемы с новой ОС — например, изменения в библиотеках и т. д., которых вы не ожидали — вы можете просто перезагрузиться снова и перейти в исходную версию 11.0, и она будет в том же состоянии, что и до обновления. Это потрясающий способ обновления ОС!