Как скопировать файловую систему 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аргументов clone source ( ). Может быть выгодно указать не только путь тома родителя, но также пути любых предков или просто любые ранее отправленные тома. Здесь это не имеет никакого значения, но это может - только предположение - помочь избежать дублирования данных в некоторых случаях.

4. Я не уверен, что какая-либо метаинформация о снимках или подобъемах будет потеряна по пути, но почти все, что интересно для большинства случаев использования, должно быть сохранено.

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

Я создал инструмент Python, который может сделать это. Я сделал это потому, что попробовал подход @Thomas Luzat как в своей собственной, так и в реализации @Johannes Ernst, а используемое пространство удвоилось с 20GB до 40GB в процедуре клонирования. Я думал, что нужно что-то более эффективное.

Рассмотрим эту общую историю файловой системы:

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

С помощью алгоритма Томаса сначала будет клонировано «current», и все снимки (являющиеся снимками предыдущих состояний «current») будут использовать «current» в качестве источника / родителя клона. Очевидно, что было бы лучше основать snap3 на snap4, snap2 на snap3 и т. Д.

И это только верхушка айсберга; Найти «лучшие» источники клонов (с точки зрения экономии места) в файловой системе btrfs со сложной историей - нетривиальная проблема. Я предложил 3 другие стратегии для решения этой проблемы, которые, кажется, используют пространство намного эффективнее. Один из них на самом деле привел к размеру клонов чуть ниже исходного.

Вы можете прочитать подробности на странице GitHub, если вам интересно.

На unix.stackexchange.com есть похожий вопрос, который указывает на partclone.btrfs, но я не знаю каких-либо подробностей по этому поводу.

Существует также обсуждение в списке рассылки ядра , не очень многообещающе ...

С btrfs-send, который я видел в последний раз, все еще были экспериментальные патчи, плавающие в списке рассылки btrfs.