Làm thế nào có thể tạo một bản sao đầy đủ các nội dung của hệ thống tập tin btrfs? Bằng cách sao chép đầy đủ, ý tôi không chỉ là dữ liệu hiện tại mà còn cả các subvolume khác với ảnh chụp nhanh của chúng , lý tưởng duy trì cấu trúc CoW của chúng (nghĩa là: không sao chép các khối có cùng nội dung.
Có vẻ như một bản sao ở cấp độ khối (chẳng hạn như với dd) không phải là một ý tưởng hay, vì nó sao chép UUID và rõ ràng không có cách nào để dễ dàng thay đổi nó .
Câu trả lời:
Đảm bảo rằng phân vùng nguồn không được đếm và sẽ không được tự động hóa.
Sử dụng dd(chậm, câm) hoặcpartclone.btrfs -b -s /dev/src -o /dev/target
Sử dụng btrfstune -uđể thay đổi UUID sau khi sao chép và trước khi gắn.
Cảnh báo mất dữ liệu : Đỗ KHÔNG cố gắng (tự động) gắn kết hoặc gốc hoặc sao chép cho đến khi UUID đã thay đổi
btrfs-cloneTôi đã không cố gắng cá nhân btrfs-clone, nhưng nó có ý định sao chép một hệ thống tệp BTRFS hiện có sang một hệ thống mới, sao chép từng subvolume theo thứ tự.
Tôi chưa tìm thấy bất kỳ giải pháp làm sẵn nào cho đến ngày hôm nay (2016-05-06), nhưng đã giải quyết vấn đề cho mục đích của tôi, bao gồm cả xử lý Sao chép trên ghi. Các bước để "nhân bản" /sourcethành /target:
Lấy một danh sách các subvolume theo thứ tự ogen: btrfs subvolume list -qu --sort ogen /source. Sắp xếp có lẽ là đủ để đảm bảo rằng các ảnh chụp nhanh hoặc subvolume phụ thuộc vào các ảnh chụp trước được xử lý trước. Điều này rất quan trọng để xử lý Copy-on-Write, bởi vì chúng ta cần phải chuyển khối lượng cơ sở trước.
Làm cho tất cả các subvolume chỉ đọc bằng cách sử dụng btrfs property set -ts /source/some-volume ro true.
Bây giờ, đối với mỗi subvolume từ danh sách trên, bắt đầu từ đầu, hãy làm như sau:
Nếu ổ đĩa không có UUID gốc (hiển thị dưới dạng -) hoặc UUID gốc không còn tồn tại trong danh sách, hãy chạy:btrfs send /source/some/volume | btrfs receive /target/some/
Nếu ổ đĩa có UUID gốc vẫn còn tồn tại, chúng ta nên chuyển nó đi vì --sort ogenchúng ta có thể sử dụng nó làm cơ sở để tránh trùng lặp dữ liệu. Do đó, tìm đường dẫn của UUID gốc trong danh sách và chạy: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs có thể sẽ đoán -pđối số tự động, nhưng tôi thích rõ ràng hơn).
Sau khi chạy một trong các lệnh trên, làm cho mục tiêu và nguồn đọc-ghi lại : btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false. Bước này có thể được bỏ qua nếu nguồn trước đây chỉ đọc.
Điều này sẽ xử lý nhiều trường hợp. Hãy cẩn thận:
Có thể có một số phức tạp liên quan đến việc đặt hàng khi lồng các subvolume / snapshot.
Toàn bộ quá trình rõ ràng là vui hơn khi được viết kịch bản.
btrfs sendchấp nhận nhiều -cđối số nguồn clone ( ). Có thể thuận lợi khi không chỉ xác định đường dẫn âm lượng của cha mẹ, mà cả đường dẫn của bất kỳ tổ tiên nào hoặc đơn giản là bất kỳ khối lượng nào được gửi trước đó. Nó không tạo ra bất kỳ sự khác biệt nào ở đây, nhưng nó có thể - chỉ là một phỏng đoán - giúp tránh trùng lặp dữ liệu trong một số trường hợp.
Tôi không chắc chắn nếu bất kỳ thông tin meta nào về ảnh chụp nhanh hoặc subvolume bị mất trên đường đi, nhưng chỉ cần về mọi thứ thú vị khác cho hầu hết các trường hợp sử dụng.
Toàn bộ quá trình đã giúp tôi chuyển một hệ thống tệp 800 GB với 3,8 GB được sử dụng (theo df) sang hình ảnh 10 GB với 3,8 GB được sử dụng. Truyền mà không có -pvà -csẽ sử dụng khoảng 190 GB, vì vậy việc sao chép dữ liệu thực sự đã tránh được.
ogencó nghĩa là?
ogenlà "thế hệ nguồn gốc" của subvolume. Tôi phải thừa nhận rằng tôi không hiểu đầy đủ về sự khác biệt hoặc liệu sử dụng thế hệ (không nguồn gốc) có đúng hay không, nhưng giả sử một số thử nghiệm chỉ ra rằng điều này hoạt động tốt hơn (tránh trùng lặp). Thế hệ dường như được cập nhật khi tạo ảnh chụp nhanh dựa trên subvolume, ogen không. Tôi sẽ quan tâm đến việc nghe về một số phát hiện. Có lẽ tốt nhất để kiểm tra IRC hoặc danh sách gửi thư Btrfs.
Tôi đã tạo ra một công cụ python có thể làm điều này. Tôi đã làm điều này bởi vì tôi đã thử cách tiếp cận của @Thomas Luzat trong cả triển khai của chính tôi và @Johannes Ernst, và không gian sử dụng đã tăng gấp đôi từ 20 GB lên 40 GB trong quy trình nhân bản. Tôi nghĩ rằng một cái gì đó hiệu quả hơn là cần thiết.
Xem xét lịch sử hệ thống tệp phổ biến này:
current ---------------------------------\
| | | |
snap4 snap3 snap2 snap1
Với thuật toán của Thomas, "hiện tại" sẽ được sao chép trước tiên và tất cả các ảnh chụp nhanh (là ảnh chụp nhanh của các trạng thái trước đây của "hiện tại") sẽ sử dụng "hiện tại" làm nguồn / bản sao gốc. Rõ ràng, sẽ tốt hơn nếu căn cứ snap3 trên snap4, snap2 trên snap3, v.v.
Và đây chỉ là phần nổi của tảng băng chìm; tìm các nguồn nhân bản "tốt nhất" (về tiết kiệm không gian) trong hệ thống tệp btrfs có lịch sử phức tạp là một vấn đề không hề nhỏ. Tôi đã đưa ra 3 chiến lược khác để giải quyết vấn đề này, dường như sử dụng không gian hiệu quả hơn nhiều. Người ta đã thực sự dẫn đến kích thước nhái thấp hơn một chút so với nguồn.
Bạn có thể đọc chi tiết trên trang github nếu bạn quan tâm.
Có một câu hỏi tương tự trên unix.stackexchange.com chỉ đến partclone.btrfs, nhưng tôi không biết bất kỳ chi tiết cụ thể nào về việc này.
Ngoài ra còn có một cuộc thảo luận về danh sách gửi thư kernel , không thực sự có triển vọng ...
Với btrfs-send, cái cuối cùng tôi thấy, vẫn là các bản vá thử nghiệm trôi nổi trên danh sách gửi thư btrfs.