Чи можна від'єднати та повторно приєднати ZFS-диск, не вимагаючи повного повторного надсилання?

10

У мене є дзеркальний басейн ZFS з чотирма загальними накопичувачами. Два приводи призначені для використання для обертання резервних копій за межами місця. Моє сподівання полягало в тому, що після первинного повторного релівертування я можу detachпізніше attachотримати диск і матиму йому лише інкрементальне перенапруження - проте при тестуванні виявляється виконати повний resilver незалежно від того, приєднаний диск чи ні містить майже весь пул вмісту.

Чи використання методу offline/ onlineпідходу дасть мені бажаний результат лише оновлення диска, а не повного його відновлення? Або для того, щоб ця робота була належним чином, мені потрібно буде зробити щось зовсім інше - наприклад, використовувати кожен резервний диск як пул 1-диска та sendробити найновіші знімки до нього, коли це потрібно оновлювати?

zfs zpool backup

— STW
джерело

5

-1 Не від'єднуйте / не приєднуйте накопичувачі для резервного копіювання, використовуйте команди відправлення / отримання так, як планували дизайнери ZFS.

— Кріс С

2

@ChrisS замість -1 як щодо написання відповіді з деякими цитатами. Здається, що ви говорите, що єдиним варіантом резервного копіювання є інтернет-пул десь в іншому місці - що було б чудово знати, чи це правда, але я підозрюю, що це не так.

— STW

1

Вибачте, я не маю наміру бути зухвалим ривком, але помилка сервера повинна бути лише для професійних системних адміністраторів (та інших). Метод розбиття дзеркал резервного копіювання настільки незмінний, схильний до помилок та непрофесійний, що його не слід вважати життєздатним методом резервного копіювання. Я пропоную вам відформатувати два диски резервного копіювання за допомогою будь-якої файлової системи і за допомогою zfs sendкоманди взяти повні або додаткові потоки резервного копіювання, збережені на резервних дисках, або використовувати zfs recvдля створення дубліката диска. Я настійно рекомендую використовувати якесь програмне забезпечення для управління цим процесом.

— Кріс С

Я думаю, що ваші пункти справедливі, я б схвалив це як відповідь. Я розглядаю можливість переписати своє питання, щоб менше зосередитись на моєму конкретному сценарії (який виникає із бюджету, що склався для некритичного, але важливого, власного сервера) та іншого в основі: "чи можу я повторно підключити диск, не вимагаючи повного resilvering? "

— STW

14

Не йдіть по дорозі розриву масиву ZFS, щоб "обертати" диски за межами. Як ви вже бачили, час відновлення високий, і процес повторного перегляду буде прочитати / перевірити використаний розмір набору даних.

Якщо у вас є можливість, знімки та надсилання даних у віддалену систему - це чистий, не нав'язливий підхід. Я думаю, ви могли пройти процес створення спеціального пулу з одним диском, його копіювання та експортування / імпорту zpool ... але це не дуже елегантно.

— ewwhite
джерело

На жаль, я не можу використати підхід моментального фотографування> надіслати, оскільки у мене немає апаратури чи пропускної здатності для запуску другого сервера на ZFS. Однак виявляється, що використання офлайн / он-лайн працюватиме з компромісом, який повідомляє про стан як про погіршення. Я побачу, як пройде наступний тиждень чи так.

— STW

1

Зрозумів. Але витягнути бігові диски з системи як форми резервного копіювання не є надійним рішенням. Коли ви це робите, ризик різко зростає.

— ewwhite

Хороший момент, мій план - відключити їх, призупинити їх, зняти лоток для гарячої заміни, а потім дати йому хвилинку, щоб забезпечити повну зупинку, перш ніж повністю витягнути її

— STW

1

Чи можете ви керувати другим сервером на місці (або навіть другим масивом ZFS на тому ж сервері)? Покладіть у нього свої відсіки гарячої заміни, синхронізуйте між собою та основним, а потім обертайте весь резервний ZFS-масив із сервера як єдине ціле.

— Dan Dan Fiddling Firelight

11

Після подальших експериментів я знайшов справедливе рішення, однак це спричинило значну компромісію. Диски, які були offline'd, але не від'єднані, пізніше можна буде повернути в Інтернет за допомогою лише покрокової операції повторного перегляду (" Коли пристрій приведено в Інтернет, будь-які дані, записані в пул, синхронізуються з недавно доступним пристроєм. "). У моїх тестах це призводить до зменшення часу перегляду дзеркала на 3-х дисках з 28 годин до трохи більше 30 хвилин, дельта даних - близько 40 Гб.

Вигода полягає в тому, що будь-який пул з офлайн-диском буде позначено як деградований. За наявності ще принаймні двох онлайн-дисків (у дзеркальному пулі) це фактично попередження - цілісність та надмірність залишаються недоторканими.

Як згадували інші, цей загальний підхід далеко не ідеальний - надсилання знімків до віддаленого басейну було б куди більш доречним, але в моєму випадку це неможливо.

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

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

Оскільки це все ще неперевірено, існує ризик, що операція перестановки дельти не буде точною. "Живий" пул та / або офлайн-диски можуть мати проблеми. Я оновлю, якщо це станеться зі мною, але поки що буду експериментувати з таким підходом.

— STW
джерело

1

Якщо resilver введе помилки з даними, вони з часом заживають автоматично або після скрабу zpool.

— the wabbit

Я зрозумів цінність скрабу; Я чекаю, поки після успішного скрабування в автономному режимі та видалення резервного диска

— STW

2

Просто швидке оновлення: за останній рік такий підхід працював досить добре. Щомісячні тести на відновлення резервного копіювання за межами сайту були успішними та послідовними. Обертання масиву (а не одного диска) було б краще забезпечити надмірність надмірної копії, і я рекомендую робити це, якщо це можливо. Загалом, це все ще хакерський підхід і створює певний ризик, але він забезпечив досить безпечне та недороге резервне копіювання наших даних.

— STW

Я б заперечував проти обертання всіх дисків у масиві, оскільки транспорт може повільно пошкодити їх. Я б не робив обертання, навіть якщо диски залишатимуться на місці.

— Костін

2

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

(Моя оригінальна публікація випливає нижче.)

Увага! З різних коментарів на цій сторінці випливає, що можна (або можливо) це zpool detachзробити диск, а потім якось повторно приєднати диск та отримати доступ до даних, які він містить.

Однак відповідно до цього потоку (і мого власного експерименту) zpool detachвидаляється "інформація про пул" з відокремленого накопичувача. Іншими словами, a 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обробити резервне копіювання мого пулу. Як і в оригінальному плакаті, я планую використовувати чотири диски, два в постійному дзеркалі і два для щомісячних резервних копій, що обертаються, за межами сайту (і за межами мережі). Я буду перевіряти кожну резервну копію, імпортуючи та очищаючи її в окрему систему, перед тим, як транспортувати її за межі сайту. На відміну від оригінального плаката, я не проти переписувати весь резервний диск щомісяця. Насправді я віддаю перевагу повним перепискам, щоб мати свіжі шматочки.

— mpb
джерело

0

На цій же машині ви намагалися створити новий пул із двома дисками в дзеркалі? Далі створіть знімок у своєму робочому пулі, потім надішліть цей знімок до нового пулу, повторіть, тоді наступне надсилання знімка буде поступовим. Це не те саме, що з "надсиланням даних у віддалену систему", оскільки це пул всередині тієї самої системи / сервера / машини. За допомогою цього налаштування ви все ще можете застосувати zpool split / offline / detach / attach, але ви робите це лише у другому (копіювальному) пулі, а не у вихідному пулі.

— сояікс
джерело