Як скопіювати файлову систему btrfs

Як можна зробити повну копію вмісту файлової системи btrfs? Під повною копією я маю на увазі не лише поточні дані , але й різні підпункти з їхніми знімками , в ідеалі зберігаючи їх структури CoW (тобто: не дублювання блоків з однаковим вмістом.

Здається, що копія на рівні блоку (наприклад, з dd) не є гарною ідеєю, оскільки вона дублює UUID, і , мабуть, немає способу її легко змінити .

Варіант 1 - німа копія даних, а потім змінити UUID

Переконайтесь, що джерельний розділ відключений та не буде автоматизований.

Використовуйте або dd(повільно, німо) абоpartclone.btrfs -b -s /dev/src -o /dev/target

Використовуйте btrfstune -uдля зміни UUID після копіювання та перед монтажем.

Попередження втрати даних : Do НЕ намагатися (авто) змонтувати або оригінал або копія , поки UUID не змінилося

Варіант 2 - btrfs-clone

Я особисто не пробував btrfs-clone, але це намагається клонувати існуючу файлову систему BTRFS до нової, клонуючи кожен підпункт по порядку.

На сьогодні я не знайшов жодного готового рішення (2016-05-06), але вирішив проблему для своїх цілей, включаючи обробку копію на запис. Кроки до "клонування" /sourceдля /target:

1. Отримати список подоб'емов замовлені ogen: btrfs subvolume list -qu --sort ogen /source. Сортування, ймовірно, досить, щоб гарантувати, що спочатку обробляються знімки або підпункти, які залежать від попередніх. Це важливо для роботи з Copy-on-Write, оскільки нам потрібно передати базові обсяги спочатку.

2. Зробіть усі підпункти лише для читання, використовуючи btrfs property set -ts /source/some-volume ro true.

3. Тепер для кожного підтомника зі списку вище, починаючи вгорі, виконайте наступне:

   1. Якщо в томі немає батьківського UUID (відображається як -) або батьківський UUID більше не існує у списку, запустіть:btrfs send /source/some/volume | btrfs receive /target/some/

   2. Якщо в томі є батьківський UUID, який все ще існує, нам слід було б перенести його вже через, --sort ogenі ми можемо використовувати це як базу, щоб уникнути дублювання даних. Отже, знайдіть у списку шлях батьківського UUID та запустіть: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs, ймовірно, -pавтоматично вгадає аргумент, але я вважаю за краще явний).

   3. Після виконання однієї з перерахованих вище команд роблять мета і джерело знову для читання і запису: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Цей крок можна пропустити, якщо джерело раніше було лише для читання.

Це має вирішуватись у багатьох випадках. Застереження:

1. Можуть виникнути деякі ускладнення щодо замовлення під час введення суб-томів / знімків.

2. Весь процес, очевидно, веселіший при написанні сценарію.

3. btrfs sendприймає кілька -cаргументів клонування source ( ). Може бути вигідним не тільки вказати батьківський об'ємний шлях, але й будь-які предки або просто будь-які раніше надіслані томи. Тут це нічого не змінило, але це може - лише здогадка - допоможе уникнути дублювання даних у деяких випадках.

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

Весь процес допоміг мені перенести файлову систему 800 ГБ з 3,8 ГБ, що використовується (згідно df), на 10 ГБ зображення з 3,8 ГБ. Передача без -pі -cвикористовувала б близько 190 ГБ, тому дублювання даних справді уникнуто.

Я створив інструмент python, який може це зробити. Я зробив це, тому що я спробував підхід @Thomas Luzat як у власному, так і в реальному виконанні @Johannes Ernst, і використаний простір удвічі збільшився з 20 ГБ до 40 Гб в процедурі клонування. Я думав, що потрібно щось більш ефективне.

Розглянемо цю загальну історію файлової системи:

current ---------------------------------\
             |       |        |          |
           snap4   snap3    snap2      snap1

За алгоритмом Томаса "струм" буде клонований спочатку, і всі знімки (будучи знімками колишніх станів "поточного") використовуватимуть "поточний" як джерело / батьківський клон. Очевидно, було б краще базувати snap3 на snap4, snap2 на snap3 тощо.

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

Ви можете прочитати деталі на сторінці github, якщо вас цікавить.

На unix.stackexchange.com є подібне запитання, яке вказує на partclone.btrfs, але я не знаю жодної конкретики з цього приводу.

Існує також дискусія у списку розсилки ядра , що не дуже виглядає перспективно ...

З btrfs-send, який я востаннє бачив, були ще експериментальні патчі, що плавали навколо у списку розсилки btrfs.