Можно ли отсоединить и снова подключить диск ZFS, не требуя полного восстановления?

У меня есть зеркальный пул ZFS с четырьмя суммарными дисками. Два привода предназначены для вращения внешних резервных копий. Я ожидал, что после первоначального повторного переноса я смогу, detachа затем и attachна диск, и сделать так, чтобы он делал только инкрементный перенос, однако при тестировании он, похоже, выполняет полное перенос, независимо от того, содержит ли подключаемый диск почти весь пул. содержание.

Будет ли использование offline/ onlineподхода дать мне желаемый результат только обновления диска, а не полной его перестройки? Или для того, чтобы эта работа соответствовала ожиданиям, мне нужно будет сделать что-то совершенно другое - например, использовать каждый диск для резервного копирования в качестве пула с 1 диском и sendвставлять в него новейшие моментальные снимки всякий раз, когда это необходимо обновить?

Не идите по пути разрушения массива ZFS, чтобы «вращать» диски вне сайта. Как вы уже видели, время восстановления велико, и процесс восстановления будет считывать / проверять используемый размер набора данных.

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

После дальнейших экспериментов я нашел справедливое решение, однако оно идет со значительным компромиссом. Диски, которые были offlineотсоединены, но не отсоединены, впоследствии могут быть возвращены в оперативный режим только с помощью пошаговой операции повторного преобразования (« Когда устройство переводится в оперативный режим , любые данные, которые были записаны в пул, повторно синхронизируются с новым доступным устройством». ) В моих тестах это сокращало время восстановления для трехдискового зеркала с 28 часов до чуть более 30 минут, с разницей данных в 40 ГБ.

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

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

Подводя итог, если вам нужно удалить диск из пула, а затем добавить его обратно, не требуя полного восстановления, то я рекомендую следующий подход:

• Автономный диск в пуле: zpool offline pool disk
• поверните диск вниз (если он должен быть физически вытянут): hdparm -Y /dev/thedisk
• оставить бассейн в ухудшенном состоянии с отключенным приводом
• чтобы добавить диск обратно в пул: zpool online pool disk

И, поскольку это еще не проверено, существует риск того, что операция пересчета дельты не является точной. «Живой» пул и / или автономные диски могут испытывать проблемы. Я буду обновлять, если это произойдет со мной, но сейчас буду экспериментировать с этим подходом.

Обновление от 2015 г. 15 октября. Сегодня я обнаружил zpool splitкоманду, которая разделяет новый пул (с новым именем) на существующий пул. splitнамного чище, чем offlineи detach, поскольку оба пула могут существовать (и очищаться отдельно) в одной и той же системе. Новый пул также можно чистить (и правильно) export[ed]до отключения от системы.

(Мой оригинальный пост следует ниже.)

Предупреждение! Различные комментарии на этой странице подразумевают, что это возможно (или может быть) возможно для zpool detachдиска, а затем каким-либо образом подключить диск и получить доступ к данным, которые он содержит.

Тем не менее, в соответствии с этим потоком (и мои собственные эксперименты) zpool detachудаляет «информацию о пуле» с отключенного диска. Другими словами, это detachкак быстрое переформатирование диска . После того, как detachбольшое количество данных все еще будет на диске, но будет практически невозможно перемонтировать диск и просмотреть данные в качестве используемой файловой системы.

Следовательно, мне кажется, что detachэто более разрушительно, чем destroy, как я считаю, zpool importможет восстановить разрушенные пулы!

detachЭто неumount , ниzpool export , ниzpool offline .

В моих экспериментах, если я сначала zpool offlineустройство, а затем zpool detachто же устройство, остальная часть пула забывает, что устройство когда-либо существовало. Однако, поскольку само устройство было offline[d]до этого detach[ed], само устройство никогда не уведомлялось о detach. Следовательно, само устройство все еще имеет информацию о пуле и может быть перемещено в другую систему и затем import[ed](в ухудшенном состоянии).

Для дополнительной защиты от detachвас можно даже физически отключить устройство после выполнения offlineкоманды, но до ее выдачи detach.

Я надеюсь offlineзатем использовать это , а detachзатем importобработать резервную копию моего пула. Как и в оригинальном постере, я планирую использовать четыре накопителя, два в постоянном зеркале и два для ежемесячного, чередующегося, автономного (и автономного) резервного копирования. Я проверю каждую резервную копию, импортировав и очистив ее в отдельной системе, до ее переноса за пределы сайта. В отличие от оригинального постера, я не против переписывать весь резервный диск каждый месяц. На самом деле, я предпочитаю полное переписывание, чтобы иметь свежие кусочки.

На той же машине вы пытались создать новый пул с двумя дисками в зеркале? Затем создайте снимок в вашем рабочем пуле, затем отправьте этот снимок в новый пул, повторите, затем следующая отправка снимка будет инкрементной. Это не то же самое с «отправкой данных в удаленную систему», так как это пул в той же системе / сервере / машине. При такой настройке вы все равно можете применить zpool split / offline / detach / attach, но вы делаете это только во втором (копируемом) пуле, а не в исходном пуле.