У меня есть зеркальный пул ZFS с четырьмя дисками. Два диска предназначены для использования для ротации внешних резервных копий. Я ожидал, что после первоначального переноса я смогу detach и позже attach диск и сделать так, чтобы он выполнял только инкрементную перенастройку, однако при тестировании кажется, что он выполняет полную перенастройку независимо от того, содержит ли уже подключенный диск почти все содержимое пула.
Использовал бы offline / online Подход дал мне желаемый результат только обновления диска, а не полного его восстановления? Или, чтобы эта работа работала, как ожидалось, мне нужно будет сделать что-то совершенно другое - например, использовать каждый резервный диск в качестве 1-дискового пула и sendдобавлять к нему новейшие снимки всякий раз, когда его нужно обновить?
Не пытайтесь сломать массив ZFS, чтобы «повернуть» диски за пределами офиса. Как вы видели, время восстановления велико, и процесс перенастройки будет читать / проверять используемый размер набора данных.
Если у вас есть возможность, создание моментальных снимков и отправка данных в удаленную систему - это чистый, ненавязчивый подход. Я предполагаю, что вы могли бы пройти процесс создания выделенного однодискового пула, копирования в него и экспорта / импорта zpool ... но это не очень элегантно.
После дальнейших экспериментов я нашел справедливое решение, однако оно требует значительного компромисса. Диски, бывшие offline'd, но не отсоединенный, можно позже вернуть в оперативный режим только с помощью операции инкрементного переноса данных ("Когда устройство переводится в оперативный режим, любые данные, которые были записаны в пул, повторно синхронизируются с новым доступным устройством.В моих тестах это сокращает время перенастройки зеркала с 3 дисками с 28 часов до чуть более 30 минут, при этом дельта данных составляет около 40 ГБ.
Компромисс заключается в том, что любой пул с автономным диском будет помечен как деградированный. При условии, что есть как минимум два онлайн-диска (в зеркальном пуле), это фактически предупреждение - целостность и избыточность остаются неизменными.
Как отмечали другие, этот общий подход далек от идеала - отправка снимков в удаленный пул была бы гораздо более подходящей, но в моем случае это невозможно.
Подводя итог, если вам нужно удалить диск из пула, а затем добавить его обратно, не требуя полной перенастройки, то подход, который я бы рекомендовал:
zpool offline pool diskhdparm -Y /dev/thediskzpool online pool diskИ, поскольку это еще не проверено, существует риск того, что операция дельта-переноса актуальных данных будет неточной. «Живой» пул и / или автономные диски могут испытывать проблемы. Я обновлю, если это произойдет со мной, а пока поэкспериментирую с этим подходом.
Обновить 15 октября 2015 г .: Сегодня я обнаружил 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, но вы делаете это только во втором (копийном) пуле, а не в исходном пуле.