1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Nếu chỉ cần một NAS cơ bản không cần GUI, chỉ cần kết hợp tạo dataset ZFS và chia sẻ qua Samba là có thể dựng một hệ thống lưu trữ mạng đơn giản
  • Môi trường ví dụ là Debian 12 Bookworm, OpenZFS zfs-2.1.1, RAIDZ1, RAM ECC RDIMM 16GB, SSD NVMe 4×4TB; mã hóa và chiến lược sao lưu nằm ngoài phạm vi
  • ZFS lưu cấu hình pool và filesystem trên đĩa, nên ngay cả khi OS hỏng, vẫn có thể lấy lại dữ liệu trên máy khác bằng zfs import
  • Với đĩa, dùng /dev/disk/by-id hoặc alias trong /etc/zfs/vdev_id.conf sẽ an toàn hơn các tên phụ thuộc vào thứ tự như /dev/nvme1
  • Việc chia sẻ mạng thực tế do Samba đảm nhiệm; cấu hình chia sẻ tài liệu thông thường và chia sẻ macOS Time Machine bằng cách tách thành các dataset docs, backups

Phạm vi của NAS tối giản tự dựng

  • Mục tiêu là tự cấu hình một NAS cơ bản mà không cần các sản phẩm NAS đầy đủ tính năng như Synology, QNAP, TrueNAS
  • Cấu hình ví dụ được giới hạn trong phạm vi sau
    • Cấp RAID: RAIDZ1, cho phép hỏng 1 ổ đĩa
    • Hệ điều hành: Debian 12 Bookworm
    • Mã hóa: không có
    • Triển khai ZFS: OpenZFS, zfs-2.1.1
    • CPU: 4 nhân, có thể dùng CPU máy chủ Xeon giá rẻ
    • RAM: ECC RDIMM RAM 16GB
    • Lưu trữ: SSD NVMe 4×4TB
    • Sao lưu: không đề cập, cần cấu hình riêng
  • TrueNAS gần giống một bộ phần mềm cấp doanh nghiệp đầy đủ tính năng, nên khi chức năng cần thiết càng đơn giản thì độ lệch giữa tính năng cung cấp và yêu cầu càng lớn
  • Tự cấu hình giúp hiểu từng thành phần của hệ thống và không phải phụ thuộc vào một bộ phần mềm khác

Thông tin cấu hình ZFS lưu trên đĩa

  • Filesystem ZFS có tính tự chứa, nên nếu OS máy chủ bị hỏng nhưng đĩa vẫn bình thường thì có thể khôi phục dữ liệu
  • Chỉ cần gắn đĩa vào máy mới hoặc OS mới, cài công cụ zfs, rồi chạy zfs import là có thể import pool hiện có
  • Cấu hình và chi tiết của ZFS được lưu trên chính đĩa
    • Ví dụ nếu cấu hình RAIDZ2 bằng 6 đĩa, chỉ cần chuyển các đĩa sang máy mới đã cài công cụ ZFS rồi chạy zfs import, hệ thống vẫn hiển thị là RAIDZ2
  • Nếu host OS hoặc máy gặp vấn đề nhưng đĩa không bị hỏng thì dữ liệu vẫn được giữ nguyên

Nhận diện đĩa và cấu hình alias

  • Trên máy Linux, kiểm tra danh sách đĩa bằng lsblk -d -o TRAN,NAME,TYPE,MODEL,SERIAL,SIZE
  • Ví dụ sử dụng 4 ổ NVMe Samsung SSD 990 PRO 4TB
  • Mỗi đĩa có một symbolic link dưới /dev/disk/by-id, trỏ từ ID sang tên thiết bị /dev/nvme...
  • Nếu định nghĩa alias trong /etc/zfs/vdev_id.conf, có thể ánh xạ ID đĩa dài thành tên ngắn
alias nvme0 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
alias nvme1 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
alias nvme2 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
alias nvme3 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
  • Alias sẽ được áp dụng sau khi chạy udevadm trigger hoặc khởi động lại
  • Có thể kiểm tra đã áp dụng hay chưa bằng ls -lh /dev/disk/by-vdev
  • Alias mapping là tùy chọn; khi tạo zpool, cũng có thể viết trực tiếp toàn bộ đường dẫn /dev/disk/by-id/...
  • Nên tránh các tên thiết bị như /dev/nvme1, /dev/nvme2 vì thứ tự không được đảm bảo khi gắn thêm ổ mới
  • /etc/zfs/vdev_id.conf là cấu hình giúp tiện tạo zpool; ngay cả khi OS hỏng và mất file này thì bản thân ZFS pool vẫn không có vấn đề

Tạo zpool và cấu hình dataset

  • Ví dụ tạo zpool RAIDZ1 bằng 4 ổ NVMe, cho phép hỏng 1 ổ tương tự RAID 5
  • Nếu cần khả năng chịu lỗi cao hơn, RAIDZ2, tức cấu hình RAID 6, sẽ có khả năng phục hồi tốt hơn
  • Việc cài ZFS tham khảo tài liệu cài đặt OpenZFS; ví dụ trên RHEL 9 cài bằng dnf install zfs
  • Khi tạo zpool, khuyến nghị dùng tùy chọn ashift=12
    • Nhiều đĩa báo với OS kích thước sector 512KB vì lý do tương thích
    • Các đĩa dung lượng lớn như Samsung 990 Pro có thể có kích thước sector 4KB hoặc 8KB
    • ashift=12 biểu thị kích thước sector 4KB và có thể cải thiện hiệu năng đáng kể
    • Thời điểm tạo zpool là cơ hội cuối cùng để đặt giá trị này
zpool create -o ashift=12 s16z1 raidz1 nvme0 nvme1 nvme2 nvme3
zpool status s16z1
  • zpool là lớp trừu tượng hóa đĩa, còn zfs là filesystem
  • Khi chạy zpool create, filesystem ZFS cũng được tạo cùng lúc
  • Có thể kiểm tra đã đặt ashift: 12 hay chưa bằng zdb | grep ashift
  • Trước khi chia sẻ, đặt điểm mount và nén
zfs set mountpoint=/mnt/s16z1 s16z1
zfs set compression=lz4 s16z1
  • Tạo các dataset docsbackups dưới dataset gốc
zfs create s16z1/docs
zfs create s16z1/backups
  • docs dùng cho tài liệu, backups dùng cho sao lưu Time Machine
  • Dataset ZFS cung cấp nhiều tính năng hơn thư mục đơn giản
    • Quản lý thuộc tính theo từng dataset
    • Mã hóa
    • Gửi và sao chép
    • Snapshot
  • Nên tạo dataset riêng cho từng nhóm file lớn
  • Ví dụ khi chỉ muốn sao lưu docs lên máy chủ từ xa, không cần gửi toàn bộ dataset gốc s16z1

Tạo tài khoản chia sẻ bằng Samba

  • Cách chia sẻ file qua mạng độc lập với ZFS; ZFS chỉ cần được mount trên hệ thống host
  • Cài Samba
apt install samba
  • Tạo người dùng UNIX john dành riêng cho Samba và đặt mật khẩu
useradd -m john
passwd john
  • Dùng smbpasswd -a john để liên kết người dùng UNIX john với người dùng Samba
  • Host kết nối có thể truy cập chia sẻ bằng SYS\john
  • Có thể xác nhận đăng ký người dùng Samba bằng pdbedit -L -v john
  • Xóa người dùng Samba bằng pdbedit -x -u john

Chia sẻ thông thường và chia sẻ Time Machine

  • Chỉnh sửa /etc/samba/smb.conf để cấu hình chia sẻ docsbackups
[docs]
path = /mnt/s16z1/docs
browseable = yes
read only = no
guest ok = no
valid users = john
create mask = 0755

[backups]
path = /mnt/s16z1/backups
read only = no
guest ok = no
inherit acls = yes
spotlight = yes
fruit:aapl = yes
fruit:time machine = yes
vfs objects = catia fruit streams_xattr
valid users = john
  • docs được cấu hình làm SMB share mục đích chung
  • backups bao gồm các thuộc tính dành cho macOS Time Machine
    • fruit:aapl = yes
    • fruit:time machine = yes
    • vfs objects = catia fruit streams_xattr
  • Trên macOS, nhấn cmd+K trong Finder rồi mount theo dạng smb://10.0.0.6/docs hoặc smb://10.0.0.6/backups
  • Trên các hệ thống họ Debian, cài smbclient rồi kiểm thử như sau
apt install smbclient
smbclient -U john //10.0.0.6/docs -c 'ls'
  • Khi mount smb://10.0.0.6/backups, macOS sẽ hiển thị đây là chia sẻ Time Machine
  • Sau khi mount, trong macOS vào Settings > General > Time Machine để thêm chia sẻ đó và bắt đầu sao lưu Time Machine

Các mục bị loại trừ

  • Cấu hình mã hóa không nằm trong quy trình này
  • Chiến lược sao lưu cũng không được bao gồm
  • Tính năng sao chép dataset của ZFS dự kiến sẽ được mở rộng trong một bài viết riêng sau này

1 bình luận

 
Các ý kiến trên Hacker News
  • Xét về giá thì hiện giờ không phải thời điểm tốt để dựng NAS, nhưng tôi vẫn đang làm trong 2 tuần qua. Tôi dùng case Jonsbo N6; nó có 8 SATA backplane và khay ổ đĩa nên khá ổn, khác với các mẫu Jonsbo trước đây
    Cuối cùng tôi quyết định tháo 4 ổ 14TB WD Elements Desktop ra để dùng, bên trong là WD140EDGZ, loại ổ nạp helium. Rẻ hơn khoảng một phần ba so với 4 ổ 12TB WD Red Plus và hiệu năng trông cũng tương đương. Bảo hành chắc chắn là điểm trừ, nhưng nếu hỏng trong thời hạn bảo hành 2 năm thì có lẽ vẫn có thể lắp lại vào vỏ ổ ngoài
    Tôi lắp một SSD M.2 256GB cũ làm ổ boot, và khá vất vả để dùng chung LUKS, khóa TPM và root ZFS sao cho dù một ổ hỏng thì vẫn không bị chặn boot. Tôi học được rất nhiều về systemd-boot và cảm thấy nó bình thường hơn grub rất nhiều
    Tôi cũng thấy quanh ZFS có nhiều huyền thoại và kiểu làm theo phong trào. Ví dụ bài viết có nhắc ECC RAM, nhưng chuyện nó là bắt buộc vì ZFS sẽ làm hỏng pool trong lúc scrub gần như là một huyền thoại, mà năm nay lại đặc biệt đắt. ZFS cũng không cần nhiều RAM đến vậy, và L2ARC cũng không dùng nhiều RAM
    Tôi vẫn đang phân vân có nên đặt dnodesize=auto hay không; có một câu chuyện đáng sợ liên quan: https://github.com/openzfs/zfs/issues/11353. Và rất khó tìm nhà cung cấp lưu trữ đám mây hỗ trợ zfs send với giá hợp lý; Rsync.net gần đây đã nâng mức đặt hàng tối thiểu lên 10TiB, quá lớn cho nhu cầu của tôi: https://www.rsync.net/products/zfsintro.html

    • Nói “xét về giá thì không phải thời điểm tốt” vẫn còn nhẹ. Hiện giờ là mức giá kinh khủng để dựng NAS
      Nếu có một lựa chọn kỳ diệu, tôi gần như muốn chọn thế giới hoàn toàn không có AI nhưng lưu trữ chỉ còn bằng 1/10 giá trước AI
    • Tôi đang chạy một pool ZFS RAIDZ2 8 ổ, và tự hỏi khuyến nghị về dung lượng trống của ZFS là kiểu làm theo phong trào hay thực sự có cơ sở
      Tôi đã hy sinh 2 ổ cho tính dư thừa, và thực tế gần đây 2 SSD có vẻ cùng lô đã chết liên tiếp nên điều đó đã có ích. Nhưng nếu còn làm theo lời khuyên chừa trống thêm ít nhất dung lượng tương đương một ổ nữa vì hiệu năng và độ ổn định, thì với giá hiện nay khá là đau
    • Tôi tò mò liệu có công khai dù chỉ một phần của “script lớn debootstrap NAS dựa trên Debian” hay không
      Sau khi xem https://words.filippo.io/frood/https://0pointer.net/blog/fitting-everything-together.html, tôi đang tìm hiểu hướng cấu hình home server/NAS bằng mkosi/systemd. Thật thú vị khi xem các cấu hình khác nhau giải bài toán này như thế nào
    • Tôi tò mò tổ hợp LUKS và khóa TPM có thực sự hoạt động tốt không. Khi server khởi động lại, liệu có thể dùng TPM để mở khóa root filesystem không, /boot có được mã hóa và chống chỉnh sửa không, có chịu được tấn công evil maid không
      Tôi biết đây là một hố thỏ, nhưng nếu đã giải quyết được hết thì thật sự rất thú vị
    • 4 ổ Samsung SSD 990 PRO 4TB NVMe SSD có giá 1100 USD mỗi ổ. Chóng mặt
      https://www.samsung.com/us/memory-storage/nvme-ssd/990-pro-p...
  • Những thứ hữu ích trên NAS: cài avahi-daemon thì Samba sẽ tự động quảng bá SMB/CIFS qua DNS-SD cho các client macOS và Linux
    Với client Windows 10 trở lên đã tắt SMB 1.0, để Explorer tự động phát hiện thì cài wsdd2 là được
    Hostname Linux thường là chữ thường, nhưng Samba mặc định công bố tên bắt đầu bằng chữ hoa lên NetBIOS và Avahi. Nếu để ý chuyện này, có thể đặt host-name=something trong [server] của /etc/avahi/avahi-daemon.conf, và đặt mdns name = mdns trong [global] của /etc/samba/smb.conf
    Nếu có client macOS, nên bật vfs_fruit trong cấu hình Samba: https://www.samba.org/samba/docs/current/man-html/vfs_fruit..... Một phần vì lý do tương thích, nhưng chủ yếu là có thể đặt fruit:model để hiện một biểu tượng thú vị trong sidebar Finder
    Có thể cấm tạo .DS_Store nếu muốn chặn: https://ryanoberto.github.io/blog/2015/04/01/disabling-the-c.... Có lẽ cũng có thể lưu thiết lập Finder vào extended attributes bằng fruit:resource = xattr, nhưng tôi chưa tự thử
    macOS từ lâu đã nói sẽ thay AFP bằng SMB và dự kiến cũng sẽ gỡ hỗ trợ client AFP trong macOS 27, nhưng hỗ trợ client SMB của macOS vẫn khá tệ. Cho đến lúc đó tôi vẫn sẽ tiếp tục chạy Netatalk cùng với Samba; Netatalk cũng đăng ký vào Avahi, và macOS — một cách khá hàm ý — ưu tiên dùng AFP hơn SMB, nên client sẽ tự động kết nối vào daemon phù hợp

    • Với Samba, tốt hơn là thêm thư mục home của người dùng thành một mục riêng. Cấu hình thư mục homes mặc định gây cảm giác hơi ám ảnh cưỡng chế
  • Có lẽ cũng phù hợp nếu tôi liên kết bài blog của mình, nơi tôi tạo một NAS như vậy nhưng dùng một tổ hợp công nghệ khá khác: dm-integrity, mdadm, XFS. Là một lập trình viên C/C++, khi theo sát quá trình phát triển OpenZFS, tôi thấy lo ngại về mặt ổn định vì xu hướng tập trung vào các tính năng khổng lồ và những vấn đề dai dẳng phát sinh từ SPL/bộ nhớ đệm trang riêng
    Tôi đã chấp nhận vất vả ban đầu thay vì sự tiện lợi của công cụ vạn năng mang tên ZFS, nhưng giờ thì rất hài lòng với lựa chọn đó
    https://world-playground-deceit.net/blog/2025/06/nas-setup-l...

  • Khi dựng NAS, tôi cũng đi đến cùng kết luận. Hệ thống dùng Nix, RAID dùng zfs, còn các dịch vụ muốn chạy thì docker compose là đủ
    https://www.splitbrain.org/blog/2025-08/03-diy_nas_on_nixos

    • Tôi cũng đang dùng NixOS cho NAS. Để quản lý container, nên xem qua quadlets cùng với Nix, tức các container Docker do systemd quản lý
    • Tôi cũng dùng NixOS làm NAS tương tự, và nó ngày càng phình to nên giờ tôi đang chuẩn bị chia sẻ với người khác. Tuy nhiên tôi dùng BTRFS trên MDADM
      Vì chán cái rack ồn ào và ngốn điện trong tủ quần áo, cuối cùng nó đã trở thành home server kiêm router tất cả trong một
      https://HomeFree.host
  • Lý do tôi vẫn trả tiền cho Synology là vì khi ổ đĩa hỏng, chỉ cần rút khay ra, thay ổ, lắp lại rồi bấm vài widget là xong. Tôi biết chắc nó sẽ được rebuild đúng cách
    Khi ổ đĩa hỏng, nó phát tiếng bíp và đèn LED gần ổ có vấn đề sáng lên, nên tôi biết phải làm gì
    Dựng một NAS như mô tả trong bài thì dễ, nhưng về dài hạn khả năng mất dữ liệu sẽ lớn hơn nhiều
    Và tôi cho rằng những hướng dẫn như vậy là chưa hoàn chỉnh nếu không nói đến “cách thay ổ đĩa số 3 một cách an toàn khi nó hỏng”. Dù không giải thích cách nhận biết ổ đĩa hỏng, thì quy trình đó vẫn cần có

    • Tôi thắc mắc snooty là lỗi tự động hoàn thành của Synology, hay là một sản phẩm khác
    • Thực ra đó chính là cách ZFS hoạt động đúng như vậy. Hướng dẫn chưa hoàn chỉnh là đúng, nhưng rebuild mảng chỉ là thay ổ đĩa rồi chạy một lệnh ZFS
    • ZFS xử lý lỗi ổ đĩa vững chắc hơn bất cứ thứ gì khác. Có lý do Synology dùng mdadm bên dưới BTRFS thay vì tính năng RAID tích hợp của BTRFS, và mdadm hoạt động ở cấp thiết bị
      Vì vậy khi thay ổ, mdadm phải dựng lại toàn bộ ổ, còn ZFS chỉ dựng lại phần dữ liệu đang thực sự được dùng
      zpool replace my_pool disk3 newdisk
    • Với ZFS, thủ tục này trở nên hoàn toàn tầm thường, trừ phần “tiếng bíp và đèn LED”
  • Hẳn có lý do để mọi người đẩy ZFS và các thành phần thường được gọi là “NAS” đi xa đến vậy, nhưng với tôi, chỉ cần chạy cấu hình NFSv3 chặt chẽ trên một HDD dung lượng lớn đơn lẻ dùng ext4 trong máy Linux cũng đã khá thoải mái
    Dù sao đó cũng là hệ thống chính luôn bật khi tôi thức, và chỉ với điện năng cùng overhead của một máy, nó có thể phục vụ tệp cho các thiết bị khác
    Tôi cố giữ cấu hình mạng mặc định theo hướng hạn chế, nên cũng không quá lo về các luận điểm bảo mật khi chạy trên máy chính. Có lẽ tôi đang phạm một tội lớn nào đó, nhưng chỉ NFSv3 thuần và Samba để tương thích thì thật sự không đủ sao?

    • Trước hết tôi muốn biết bạn có bản sao lưu cho HDD dung lượng lớn đơn lẻ đó không. Đó là điều đáng lo nhất. Một ngày nào đó HDD đó chắc chắn sẽ hỏng, và kế hoạch khi ấy mới quan trọng
      Lý do chính mọi người chọn ZFS và “NAS” là checksum và bảo vệ tính toàn vẹn dữ liệu, cũng như vì họ không muốn luôn đánh thức máy chính
      Các tính năng như snapshot cũng hữu ích, giúp giảm lo mất dữ liệu do vô tình xóa hoặc ghi đè tệp
      Tôi nghĩ dùng máy chính bật 24/7 làm NAS bản thân nó không có vấn đề. Không cần phải gượng mua thứ gì đó chỉ vì cho có, nhưng tôi lo về độ tin cậy và khả năng chống bit rot. Chuyện đó thực sự xảy ra, và nhờ ZFS tôi đã tận mắt thấy
    • Trong cấu hình đó, cấu trúc lưu trữ một ổ đơn lẻ là vấn đề lớn hơn. Một ổ đĩa hỏng là không chịu nổi, và nếu phần cứng bắt đầu âm thầm làm hỏng dữ liệu thì toàn bộ dữ liệu đều gặp nguy hiểm. Giả định là cả bản sao lưu cũng dựa trên dữ liệu của ổ cứng đơn lẻ đó
      Nếu muốn giữ cấu hình đơn giản, có thể cân nhắc lưu danh sách hash của tệp và kiểm tra định kỳ
      Cũng nên dùng chương trình sao lưu hỗ trợ snapshot, Restic là một lựa chọn ổn
      Bạn cũng có thể mua thêm một ổ cứng cùng dung lượng với ổ hiện tại để quản lý tính toàn vẹn tệp bằng SnapRAID, hoặc cấu hình mirror 2 ổ bằng btrfs
    • Khi nhiều máy bắt đầu đọc/ghi đồng thời, bạn sẽ chạm giới hạn. Dù vậy, cứ làm thứ hiện tại cần là được, không cần tối ưu hóa quá mức
  • Cockpit rất hữu ích cho việc quản lý NAS và VPS. Dù nhờ LLM mà bản thân việc cấu hình không còn là vấn đề lớn, có một dashboard với các nút bật/tắt và log được sắp xếp vẫn rất tiện, và có thể chạy lệnh shell từ điện thoại mà không cần SSH
    Trên NAS, có thể dễ dàng xem kết quả các tác vụ cron sao lưu/bảo trì, quản lý Samba và theo dõi dung lượng đĩa. Đặc biệt việc làm cho Samba hoạt động ổn trên iPhone thật sự rất đau đầu

    • Nếu chạy lệnh shell từ điện thoại mà không cần SSH, tôi thắc mắc Cockpit xác thực như thế nào. Có đặt HTTP basic auth ở phía trước không?
      Với xác thực máy chủ, thay vì hạ xuống phương thức khác ngoài khóa công khai/khóa riêng, cuối cùng tôi thường làm cho SSH dùng được trên điện thoại. Ở điểm này tôi khá thận trọng theo kiểu hơi âm mưu luận
  • Trước đây khi tự dựng NAS, tôi cũng dùng bài này làm tài liệu học: https://xyny.art/blog/2026-building-nas/
    Dựng NAS từ đầu thật sự rất thú vị. Việc không có “tài liệu hoàn chỉnh” bao quát toàn bộ chủ đề là một trở ngại nhỏ, nhưng đồng thời cũng là một phần của niềm vui
    Mục đích bài viết của tôi cũng gần với việc thêm một “hướng dẫn” cấu hình NAS thiên lệch nữa lên Internet. Tôi hơi dè dặt khi gọi nó là hướng dẫn, nhưng nếu phải làm lại việc tương tự, chắc chắn tôi sẽ đọc bài của mình trước

  • Về mặt khái niệm là chạy cùng một thứ, nhưng dùng FreeBSD thay vì Debian. Không hẳn tốt hơn hay tệ hơn, chỉ là các đánh đổi khác nhau, và rốt cuộc vẫn hoạt động tốt như nhau

  • Khi dựng lại NAS, tôi đã quyết định dùng NFS trên ZFS. Tuy nhiên mục tiêu hơi khác với tác giả bài viết. Tôi dùng CPU/mainboard tiết kiệm điện, tạo hai hệ thống riêng biệt có khả năng failover và cấu hình theo kiểu độ sẵn sàng cao
    Thực tế tôi cũng đã viết phần mềm tùy chỉnh để xử lý failover và sao chép dữ liệu. Trong thử nghiệm, khi failover, thao tác ghi của client chỉ bị dừng khoảng vài giây. Tôi tự hỏi liệu có ai quan tâm nếu tôi viết một bài về nội dung này không