Jak skopiować system plików btrfs

Jak zrobić pełną kopię zawartości systemu plików btrfs? Przez pełną kopię rozumiem nie tylko bieżące dane , ale także różne podwolumny z ich migawkami , idealnie zachowując ich struktury CoW (tj. Nie powielając bloków o tej samej treści.

Wydaje się, że kopia na poziomie bloku (na przykład with dd) nie jest dobrym pomysłem, ponieważ powiela UUID i najwyraźniej nie ma sposobu na łatwą zmianę .

Opcja 1 - Głupia kopia danych, a następnie zmiana UUID

Upewnij się, że partycja źródłowa jest odmontowana i nie zostanie automatycznie zamontowana.

Użyj albo dd(wolno, głupio) lubpartclone.btrfs -b -s /dev/src -o /dev/target

Służy btrfstune -udo zmiany UUID po kopiowaniu i przed montażem.

Ostrzeżenie utrata danych : Do NIE próbować (auto) zamontować albo oryginał lub kopia aż UUID zmieniła

Opcja 2 - btrfs-clone

Nie próbowałem osobiście btrfs-clone, ale ma to na celu sklonowanie istniejącego systemu plików BTRFS do nowego, klonując kolejno każdą podobjętość.

Na dzień dzisiejszy nie znalazłem gotowego rozwiązania (2016-05-06), ale rozwiązałem problem dla moich celów, w tym obsługę kopiowania na zapisie. Kroki do „klona” /sourcena /targetto:

1. Pobierz listę wielkości podrzędnych zamówionych przez ogen: btrfs subvolume list -qu --sort ogen /source. Sortowanie jest prawdopodobnie wystarczające, aby zagwarantować, że najpierw zostaną wykonane migawki lub podwolumny zależne od poprzednich. Jest to ważne w przypadku kopiowania przy zapisie, ponieważ najpierw musimy przenieść woluminy podstawowe.

2. Ustaw wszystkie podwoluminy tylko do odczytu, używając btrfs property set -ts /source/some-volume ro true.

3. Teraz, dla każdej podobjętości z powyższej listy, zaczynając od góry, wykonaj następujące czynności:

   1. Jeśli wolumin nie ma nadrzędnego identyfikatora UUID (wyświetlany jako -) lub nadrzędny identyfikator UUID już nie istnieje na liście, uruchom:btrfs send /source/some/volume | btrfs receive /target/some/

   2. Jeśli wolumin ma nadrzędny identyfikator UUID, który nadal istnieje, powinniśmy go już przenieść z tego powodu --sort ogeni możemy go użyć jako podstawy, aby uniknąć powielania danych. Dlatego znajdź ścieżkę nadrzędnego UUID na liście i uruchom: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs prawdopodobnie odgadłby -pargument automatycznie, ale wolę być jawny).

   3. Po uruchomieniu jednego z powyższych poleceń dokonać cel i źródło odczytu ponownie: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Ten krok można pominąć, jeśli źródło było wcześniej tylko do odczytu.

To powinno obsłużyć wiele spraw. Ostrzeżenia:

1. Mogą występować pewne komplikacje w zakresie porządkowania podczas zagnieżdżania podwoluminów / migawek.

2. Cały proces jest oczywiście bardziej zabawny, gdy jest skryptowany.

3. btrfs sendakceptuje wiele -cargumentów source ( ) klonowania . Korzystne może być nie tylko określenie ścieżki woluminu rodzica, ale także ścieżek dowolnego przodka lub po prostu wcześniej wysłanych woluminów. Nie miało to tutaj znaczenia, ale może - tylko zgadnąć - pomóc w niektórych przypadkach uniknąć powielania danych.

4. Nie jestem pewien, czy po drodze zostaną utracone jakiekolwiek meta informacje dotyczące migawek lub podwoluminów, ale należy zachować prawie wszystko, co interesujące w większości przypadków użycia.

Cały proces pomógł mi przenieść system plików 800 GB z użytym 3,8 GB (zgodnie z df) do obrazu 10 GB z użytym 3,8 GB. Przesyłanie bez -pi -czużyłoby około 190 GB, więc w rzeczywistości uniknięto powielania danych.

Stworzyłem narzędzie Pythona, które może to zrobić. Zrobiłem to, ponieważ wypróbowałem podejście @Thomas Luzat zarówno we własnej, jak i @Johannes Ernst, a wykorzystana przestrzeń podwoiła się z 20 GB do 40 GB w procedurze klonowania. Myślałem, że potrzeba czegoś bardziej wydajnego.

Rozważ tę wspólną historię systemu plików:

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

W przypadku algorytmu Thomasa „prąd” byłby najpierw sklonowany, a wszystkie migawki (będące migawkami wcześniejszych stanów „prądu”) użyłyby „prądu” jako źródła klonowania / rodzica. Oczywiście lepiej byłoby oprzeć snap3 na snap4, snap2 na snap3 itp.

A to tylko wierzchołek góry lodowej; znalezienie „najlepszych” źródeł klonowania (pod względem oszczędności miejsca) w systemie plików btrfs ze złożoną historią jest nietrywialnym problemem. Opracowałem 3 inne strategie rozwiązania tego problemu, które wydają się znacznie wydajniej wykorzystywać przestrzeń. Jeden faktycznie spowodował, że rozmiar klonów był nieco niższy niż rozmiar źródła.

Możesz przeczytać szczegóły na stronie github, jeśli jesteś zainteresowany.

Jest to podobne pytanie na unix.stackexchange.com że punkty do partclone.btrfs, ale nie znam żadnych szczegółów na ten temat.

Trwa także dyskusja na liście mailingowej jądra , która nie wygląda naprawdę obiecująco ...

Z tym btrfs-send, co ostatnio widziałem, wciąż były łatki eksperymentalne unoszące się na liście mailingowej btrfs.