Можно ли отсоединить и повторно подключить диск ZFS без необходимости полностью восстанавливать данные?

Вопрос или проблема

У меня есть зеркальный пул ZFS с четырьмя дисками. Два из дисков предназначены для ротации резервных копий вне сайта. Я ожидал, что после начального ресилверинга я смогу отсоединить диск и позже прикрепить его, и он выполнит только инкрементальный ресилверинг. Однако в процессе тестирования, похоже, что происходит полный ресилверинг независимо от того, содержит ли присоединяемый диск почти все содержимое пула.

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

Не следует идти по пути разрушения массива ZFS, чтобы “ротация” дисков вне сайта. Как вы видели, время восстановления велико, а процесс ресилверинга будет читать и проверять использованный размер набора данных.

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

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

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

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

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

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

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

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

(Мое оригинальное сообщение ниже.)

Внимание! Различные комментарии на этой странице подразумевают, что возможно отсоединить диск zpool, а затем как-то снова присоединить его и получить доступ к данным, содержащимся на нем.

Однако, согласно этой теме (и моим собственным экспериментам), zpool detach удаляет “информацию о пуле” с отсоединенного диска. Иными словами, отсоединение похоже на быстрое форматирование диска. После отсоединения много данных может оставаться на диске, но практически невозможно будет перемонтировать диск и просмотреть данные как используемую файловую систему.

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

Отсоединение — это не umount, не zpool export и не zpool offline.

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

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

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

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

Несколько запоздалый ответ, но на мой взгляд правильный подход здесь — это репликация одного пула в другой идентично размерный пул. Репликация ZFS осуществляется на основе снимков, и после первой репликации последующие будут полностью инкрементальными, поскольку ZFS понимает, какие блоки изменились между снимками. Итак, если у вас есть 3 пары резервного копирования и есть полосатый пул данных, я бы создал 3 пула backup1, backup2 и backup3. Чтобы сделать резервное копирование, например, на набор дисков в backup1, вы физически вставляете эти диски, импортируете backup1, выполняете репликацию (zfs send), экспортируете пул и удаляете диски. В первый раз, когда вы делаете резервное копирование в каждый из 3 пулов резервного копирования/наборов резервных дисков, это будет полная копия. Но каждое последующее резервное копирование будет инкрементальным, основываясь только на блоках, которые изменились.

Ответ или решение

Тема: Резервное копирование данных в ZFS: возможности отсоединения и повторного подключения дисков без полной реиннициализации

Введение

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

Проблема

При тестировании системы ZFS с зеркальным пулом, состоящим из четырех дисков, вы столкнулись с тем, что после отсоединения диска и его повторного подключения происходит не инкрементальный, а полный ресилверинг данных. Это требует значительных затрат времени и ресурсов, что затрудняет процесс резервного копирования.

Альтернативные подходы

1. Использование команды offline/online:
   Предложенный вариант заключается в использовании команды zpool offline для вывода диска из эксплуатации перед его физическим отключением. После этого диск может быть легко повторно подключен с помощью команды zpool online, что позволяет ZFS выполнить инкрементальный ресилверинг. Этот подход действительно дает возможность значительно сократить время на ресилверинг — например, с 28 часов до 30 минут при уменьшении объема измененных данных до 40 ГБ.

   Однако важно учитывать, что такая операция сделает пул с недоступным диском "испорченным". При этом, если в зеркальном пуле останется хотя бы два работающих диска, целостность и избыточность данных будут сохранены.

2. Использование команды split:
   Ваша недавняя находка, связанная с командой zpool split, также представляет собой более элегантное решение. Эта команда позволяет создать новый пул из существующего, тем самым упрощая процесс управления резервными копиями. Это дает возможность существовать двум пулам параллельно и очищать данные отдельно перед отключением.

3. Репликация данных:
   Можно рассмотреть также создание отдельного пула для резервных копий и использование функции zfs send для репликации данных. Первичное создание резервной копии будет полным, но последующие операции будут инкрементальными благодаря пониманию ZFS, какие блоки изменились между снимками данных.

4. Стратегия резервного копирования:
   Другой возможный подход — создать несколько копий резервных пулов дисков и с помощью zfs send периодически делать резервные копии с базовой настройкой зеркалирования. Это обеспечит вам большую гибкость и возможность восстановления данных.

Рекомендации:

Если вы хотите обеспечить эффективное использование дисков для резервного копирования, рассмотрите следующий процесс:

• Ведите учет текущих снимков данных с помощью регулярного выполнения zfs snapshot.
• Используйте команду zpool offline для диска перед его отключением.
• Переместите определенные диски в резервные пулы и используйте zfs send для создания первых резервных копий и инкрементальных обновлений.
• Тщательно планируйте и тестируйте процесс повторного подключения дисков, чтобы избежать потери данных.

Заключение

Существуют различные подходы к управлению резервными копиями в ZFS, и стратегический выбор зависит от конкретных условий и требований вашей инфраструктуры. Использование методов offline/online, split и репликации данных может существенно упростить процесс резервного копирования и управления дисками. Однако каждое решение имеет свои преимущества и потенциальные риски, и важно тщательно планировать и тестировать решаемые процессы.