- 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
docs và backups 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ẻ docs và backups
[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=autohay 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 sendvớ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.htmlNế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 đã 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
Sau khi xem https://words.filippo.io/frood/ và 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
/bootcó được mã hóa và chống chỉnh sửa không, có chịu được tấn công evil maid khôngTô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ị
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=somethingtrong[server]của/etc/avahi/avahi-daemon.conf, và đặtmdns name = mdnstrong[global]của/etc/samba/smb.confNế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 FinderCó thể cấm tạo
.DS_Storenế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ằngfruit: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
homesmặ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
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ó
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 newdiskHẳ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?
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
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
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
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