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