Как сделать полную копию содержимого файловой системы btrfs? Под полной копией я подразумеваю не только текущие данные , но также различные подобъемы с их снимками , в идеале сохраняя их структуры CoW (т.е. не дублируя блоки с одинаковым содержимым.
Кажется, что копирование на уровне блоков (например, с помощью dd) не очень хорошая идея, поскольку оно дублирует UUID, и , по-видимому, нет способа легко его изменить .
Ответы:
Убедитесь, что исходный раздел отключен и не будет автоматически подключен.
Используйте dd(медленно, тупо) илиpartclone.btrfs -b -s /dev/src -o /dev/target
Используйте btrfstune -uдля изменения UUID после копирования и перед монтированием.
Предупреждение потери данных : Do НЕ пытаться (авто) смонтировать либо оригинал или копия , пока UUID не изменилось
btrfs-cloneЯ лично не пробовал btrfs-clone, но он подразумевает клонирование существующей файловой системы BTRFS в новую, клонирование каждого подобъема по порядку.
На сегодняшний день я не нашел ни одного готового решения (2016-05-06), но решил эту проблему для своих целей, включая обработку копирования при записи. Шаги к «клону» /sourceна /targetэто:
Получить список подобъемов заказанные ogen: btrfs subvolume list -qu --sort ogen /source. Сортировки, вероятно, достаточно, чтобы гарантировать, что снимки или подобъемы, которые зависят от предыдущих, обрабатываются первыми. Это важно для работы с Copy-on-Write, потому что мы должны сначала перенести базовые тома.
Сделайте все подобъемы доступными только для чтения btrfs property set -ts /source/some-volume ro true.
Теперь для каждого подобъема из приведенного выше списка, начиная сверху, сделайте следующее:
Если у тома нет родительского UUID (отображается как -) или родительский UUID больше не существует в списке, выполните:btrfs send /source/some/volume | btrfs receive /target/some/
Если у тома есть родительский UUID, который все еще существует, мы должны были перенести его уже из-за этого --sort ogenи можем использовать его в качестве базы, чтобы избежать дублирования данных. Следовательно, найдите путь родительского UUID в списке и запустите: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs, вероятно, угадал бы -pаргумент автоматически, но я предпочитаю быть явным).
После выполнения одной из перечисленных выше команд делают цель и источник снова для чтения и записи: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Этот шаг можно пропустить, если источник ранее был доступен только для чтения.
Это должно справиться со многими случаями. Предостережения:
При размещении вложенных томов / снимков могут возникнуть некоторые сложности с упорядочением.
Весь процесс, очевидно, веселее, когда он написан по сценарию.
btrfs sendпринимает несколько -cаргументов clone source ( ). Может быть выгодно указать не только путь тома родителя, но также пути любых предков или просто любые ранее отправленные тома. Здесь это не имеет никакого значения, но это может - только предположение - помочь избежать дублирования данных в некоторых случаях.
Я не уверен, что какая-либо метаинформация о снимках или подобъемах будет потеряна по пути, но почти все, что интересно для большинства случаев использования, должно быть сохранено.
Весь процесс помог мне перенести 800 ГБ файловой системы с 3,8 ГБ (согласно df) в образ 10 ГБ с 3,8 ГБ. Передача без -pи -cпотребовала бы около 190 ГБ, поэтому дублирования данных действительно удалось избежать.
ogenзначит?
ogen- это «происхождение поколения». Я должен признать, что я не полностью понимаю различия или то, что использование поколения (не источника) было бы правильным, но предполагаю, что некоторые тесты показали, что это работало лучше (избегая дублирования). Генерация, кажется, обновляется при создании снимков на основе подобъема, а Ogen - нет. Мне было бы интересно услышать о некоторых выводах. Вероятно, лучше всего проверить IRC или список рассылки Btrfs.
Я создал инструмент 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.