chiến lược phân vùng và subvol với btrfs


10

Tôi mới sử dụng btrfs và tôi muốn một số lời khuyên về chiến lược phân vùng và subvolume. Hệ thống này là một máy chủ web hoạt động nhẹ và giả sử nó chỉ có một đĩa duy nhất.

Với các hệ thống tập tin mở rộng, tôi luôn tạo các phân vùng riêng cho /, / var, hoán đổi (và có thể / boot và / home). Đối với tôi, / var luôn chứa tất cả dữ liệu máy chủ web có giá trị (ví dụ: cơ sở dữ liệu MySQL) và không có mã nào. Điều đó cho phép tôi dễ dàng di chuyển dữ liệu sang một hệ thống khác (di chuyển hoặc sao chép / var) hoặc cài đặt lại HĐH mà không làm gián đoạn dữ liệu (định dạng lại /), v.v.

Sử dụng btrfs, tôi có thể làm điều tương tự, sử dụng cùng một sơ đồ phân vùng và có một hệ thống tập tin btrfs riêng trên mỗi phân vùng. Hoặc, tôi có thể có một phân vùng duy nhất và sử dụng các biểu tượng con btrfs cho /, / var và vv. Điều gì sẽ là ưu và nhược điểm của điều đó?

Đối với tôi, dường như có một số lợi thế khi có các ảnh chụp nhanh / chỉ và / var, chẳng hạn ("Khôi phục tất cả dữ liệu về điểm kiểm tra trước" so với "khôi phục tất cả mã" so với "khôi phục cả hai"). Điều đó có đúng không, hay nó chỉ xuất hiện theo cách đó?

Câu hỏi thưởng: có lợi thế nào khi sử dụng lvm bên dưới hệ thống tập tin btrfs không?

Câu hỏi thưởng 2: lời khuyên của bạn sẽ thay đổi như thế nào nếu hệ thống có hai đĩa có cùng kích thước?

Bất kỳ gợi ý nào cho "đây là những gì tôi đã làm và nó đã làm việc cho tôi như thế nào" cũng sẽ được đánh giá cao. Tôi có thể tìm thấy nhiều tài liệu về những gì tôi có thể làm, nhưng tôi không tìm thấy nhiều câu nói "đây là những gì tôi đã cố gắng và đây là lý do tại sao nó hoạt động hoặc không".


1
Câu hỏi tuyệt vời! Tôi muốn hỏi gần như giống nhau. Tôi muốn sử dụng mã hóa raid1 và luks, nhưng thật khó để tìm thấy thông tin liên quan về những điều cơ bản. Ví dụ: liệu tôi có thể cài đặt một hệ thống op trên một khối lượng trùng lặp duy nhất và có thể sử dụng subvolume cho / hoán đổi, v.v. mà không có bất kỳ nhược điểm nào không. Có lẽ tôi nên đọc hướng dẫn, nhưng tôi không thích những văn bản dài. : D
inf3rno

Câu trả lời:


6

Nếu bạn không có nhu cầu cụ thể, hãy sử dụng btrfs như bạn sẽ sử dụng hệ thống tập tin khác. Tách / nhà là một thực hành tốt.

Cá nhân, trên các máy chủ gia đình, subvolume duy nhất của tôi là / etc, vì vậy tôi có thể tạo ảnh chụp nhanh các cấu hình. Điều này có thể được tự động với các công cụ như cá hồng.

Thông thường, có rất ít sự quan tâm của việc khôi phục chỉ là một phiên bản / var trước đó, vì cũng cần phải khôi phục / lib / thứ. Đó là một tình huống tất cả hoặc không có gì.

Ảnh chụp nhanh của / home có thể RẤT lớn, vì vậy việc quản lý kích thước đĩa sẽ sớm gặp vấn đề. Nó có thể được thực hiện mà không có bất kỳ vấn đề, nhưng hãy chú ý đến không gian còn lại. Ngoài ra, vì ảnh chụp nhanh chỉ có thể được thực hiện trên cùng một đĩa, chúng không phải là giải pháp sao lưu trong trường hợp hỏng đĩa. Hãy nghĩ về chúng như một cái gì đó cho các tình huống như "oups, tôi đã xóa tệp này hai giờ trước, nhưng tôi vẫn cần nó".

Tiền thưởng 1: không có. Trong thực tế, btrfs đã được thiết kế để đơn giản hóa ngăn xếp mdadm + lvm + fs. Vì vậy, nó là thực sự tốt hơn để tránh nó.

Phần thưởng 2: Không, nhưng tạo RAID 1! Đơn giản và hiệu quả, dữ liệu của bạn sẽ yêu bạn :)

Phần thưởng Ninja: bạn thực sự có thể muốn có một cái nhìn tốt về wiki btrfs .


btrfs hỗ trợ phản chiếu và cấu hình RAID'ish khác. Thậm chí bạn nên tránh tái tạo RAID6, bạn có thể dễ dàng tạo một bản sao bằng cách thêm một phân vùng sau khi cài đặt. Bạn có thể tìm thấy một cách tốt đẹp để đến đây ( oblang.tuwien.ac.at/anton/btrfs-ston1.html )
JOduMonT

0

Gần đây tôi đã xem lại bài này và nghĩ rằng tôi sẽ chia sẻ một bài viết được suy nghĩ rất kỹ, đề xuất một phân vùng với các thư mục cấp cao nhất chứa subvolume: https://bbs.archlinux.org/viewtopic.php?id=194491

TL; DR

subvolid=0
      ├── subvol_root
      │        └── /usr, /bin, /sbin, /.snapshots, etc
      ├── subvol_snapshots
      ├── subvol_home
      └── subvol_opt
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.