- หากต้องการ NAS พื้นฐานที่ไม่จำเป็นต้องมี GUI การสร้าง ZFS dataset แล้วแชร์ด้วย Samba ก็เพียงพอสำหรับทำสตอเรจบนเครือข่ายแบบเรียบง่าย
- สภาพแวดล้อมตัวอย่างคือ Debian 12 Bookworm, OpenZFS zfs-2.1.1, RAIDZ1, ECC RDIMM RAM 16GB, NVMe SSD 4TB จำนวน 4 ตัว โดยไม่ครอบคลุมการเข้ารหัสและกลยุทธ์การสำรองข้อมูล
- ZFS เก็บการตั้งค่าของ pool และ filesystem ไว้บนดิสก์ ดังนั้นแม้ OS จะเสียหาย ก็สามารถนำข้อมูลกลับมาได้บนเครื่องอื่นด้วย
zfs import
- สำหรับดิสก์ ควรระบุด้วย
/dev/disk/by-id หรือ alias ใน /etc/zfs/vdev_id.conf จะปลอดภัยกว่าการใช้ชื่อที่ขึ้นกับลำดับอย่าง /dev/nvme1
- การแชร์ผ่านเครือข่ายจริง ๆ ให้ Samba จัดการ โดยแยกเป็น dataset
docs สำหรับแชร์เอกสารทั่วไป และ backups สำหรับแชร์ Time Machine ของ macOS
ขอบเขตของ NAS ขั้นต่ำที่สร้างเอง
- เป้าหมายคือการสร้าง NAS พื้นฐาน เอง โดยไม่ใช้ผลิตภัณฑ์ NAS แบบฟีเจอร์ครบอย่าง Synology, QNAP หรือ TrueNAS
- ตัวอย่างนี้จำกัดขอบเขตการตั้งค่าไว้ดังนี้
- ระดับ RAID: RAIDZ1 รองรับการเสียของไดรฟ์ได้ 1 ตัว
- ระบบปฏิบัติการ: Debian 12 Bookworm
- การเข้ารหัส: ไม่มี
- การใช้งาน ZFS: OpenZFS, zfs-2.1.1
- CPU: 4 คอร์ สามารถใช้ CPU เซิร์ฟเวอร์ Xeon ราคาประหยัดได้
- RAM: ECC RDIMM RAM 16GB
- สตอเรจ: NVMe SSD 4TB จำนวน 4 ตัว
- การสำรองข้อมูล: ไม่ครอบคลุม และจำเป็นต้องตั้งค่าแยกต่างหาก
- TrueNAS ใกล้เคียงกับชุดซอฟต์แวร์ระดับองค์กรแบบฟีเจอร์ครบ ยิ่งฟีเจอร์ที่ต้องการเรียบง่ายเท่าไร ความไม่สอดคล้อง ระหว่างฟีเจอร์ที่มีให้กับข้อกำหนดที่ต้องการก็ยิ่งมากขึ้น
- การตั้งค่าเองช่วยให้เข้าใจองค์ประกอบแต่ละส่วนของระบบ และไม่จำเป็นต้องพึ่งพาชุดซอฟต์แวร์อีกชุดหนึ่ง
ข้อมูลการตั้งค่าที่ ZFS เก็บไว้บนดิสก์
- ZFS filesystem มีลักษณะ พึ่งพาตัวเองได้ครบถ้วน ดังนั้นแม้ host OS จะเสียหาย หากดิสก์ยังปกติ ก็สามารถกู้ข้อมูลกลับมาได้
- เมื่อต่อดิสก์เข้ากับเครื่องใหม่หรือ OS ใหม่ ติดตั้งเครื่องมือ
zfs แล้วรัน zfs import ก็สามารถนำ pool เดิมกลับมาได้
- การตั้งค่าและรายละเอียดของ ZFS ถูกเก็บไว้บนดิสก์เอง
- เช่น หากตั้งค่า RAIDZ2 ด้วยดิสก์ 6 ตัว เมื่อนำดิสก์เหล่านั้นไปยังเครื่องใหม่ที่ติดตั้งเครื่องมือ ZFS แล้วรันเพียง
zfs import ก็จะแสดงเป็น RAIDZ2
- แม้ host OS หรือเครื่องจะมีปัญหา หากดิสก์ไม่ได้เสียหาย ข้อมูลก็ยังคงอยู่
การระบุดิสก์และการตั้งค่า alias
- บนเครื่อง Linux ตรวจสอบรายการดิสก์ด้วย
lsblk -d -o TRAN,NAME,TYPE,MODEL,SERIAL,SIZE
- ในตัวอย่างใช้ไดรฟ์ Samsung SSD 990 PRO 4TB NVMe จำนวน 4 ตัว
- ดิสก์แต่ละตัวจะมี symbolic link ใต้
/dev/disk/by-id ที่เชื่อม ID กับชื่ออุปกรณ์ /dev/nvme...
- หากกำหนด alias ใน
/etc/zfs/vdev_id.conf จะสามารถแมป ID ดิสก์ยาว ๆ ให้เป็นชื่อสั้นได้
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
- เมื่อรัน
udevadm trigger หรือรีบูต ระบบจะนำ alias ไปใช้
- ตรวจสอบว่าใช้งานแล้วหรือไม่ด้วย
ls -lh /dev/disk/by-vdev
- Alias mapping เป็นตัวเลือกเสริม และตอนสร้าง zpool จะเขียน path เต็ม
/dev/disk/by-id/... โดยตรงก็ได้
- ควรหลีกเลี่ยงชื่ออุปกรณ์อย่าง
/dev/nvme1, /dev/nvme2 เพราะเมื่อใส่ไดรฟ์ใหม่ ลำดับไม่รับประกันว่าจะคงเดิม
/etc/zfs/vdev_id.conf เป็นการตั้งค่าเพื่อความสะดวกในการสร้าง zpool และแม้ OS จะเสียหายจนไฟล์นี้หายไป ก็ไม่กระทบต่อตัว ZFS pool เอง
การสร้าง zpool และการตั้งค่า dataset
- ตัวอย่างนี้สร้าง zpool แบบ RAIDZ1 ด้วย NVMe 4 ตัว ซึ่งรองรับการเสียของไดรฟ์ได้ 1 ตัว คล้าย RAID 5
- หากต้องการความทนทานต่อความเสียหายสูงขึ้น RAIDZ2 หรือการตั้งค่าแบบ RAID 6 จะกู้คืนได้ดีกว่า
- สำหรับการติดตั้ง ZFS ให้ดู เอกสารการติดตั้ง OpenZFS เช่น บน RHEL 9 ติดตั้งด้วย
dnf install zfs
- แนะนำให้ใช้ตัวเลือก
ashift=12 ตอนสร้าง zpool
- ดิสก์จำนวนมากรายงานขนาด sector เป็น 512KB ต่อ OS ด้วยเหตุผลด้านความเข้ากันได้
- ดิสก์ความจุสูงอย่าง Samsung 990 Pro อาจมีขนาด sector 4KB หรือ 8KB
ashift=12 หมายถึงขนาด sector 4KB และอาจช่วยเพิ่มประสิทธิภาพได้อย่างมาก- ตอนสร้าง zpool เป็นโอกาสสุดท้ายที่จะตั้งค่านี้
zpool create -o ashift=12 s16z1 raidz1 nvme0 nvme1 nvme2 nvme3
zpool status s16z1
zpool คือ abstraction ของดิสก์ ส่วน zfs คือ filesystem- เมื่อรัน
zpool create จะมีการสร้าง ZFS filesystem ไปพร้อมกัน
- ตรวจสอบว่าได้ตั้งค่า
ashift: 12 หรือไม่ด้วย zdb | grep ashift
- ก่อนแชร์ ให้ตั้งค่า mount point และ compression
zfs set mountpoint=/mnt/s16z1 s16z1
zfs set compression=lz4 s16z1
- สร้าง dataset
docs และ backups ใต้ root dataset
zfs create s16z1/docs
zfs create s16z1/backups
- ใช้
docs สำหรับเอกสาร และ backups สำหรับ Time Machine backup
- ZFS dataset ให้ความสามารถมากกว่าโฟลเดอร์ธรรมดา
- จัดการ property แยกตาม dataset
- การเข้ารหัส
- การส่งและทำสำเนา
- snapshot
- ควรสร้าง dataset แยกตามหมวดหมู่ไฟล์ขนาดใหญ่
- เช่น หากต้องการสำรองเฉพาะ
docs ไปยังเซิร์ฟเวอร์ระยะไกล ก็ไม่จำเป็นต้องส่ง root dataset s16z1 ทั้งหมด
สร้างบัญชีแชร์ด้วย Samba
- วิธีแชร์ไฟล์ผ่านเครือข่ายเป็นอิสระจาก ZFS และ ZFS เพียงต้องถูก mount อยู่บน host system เท่านั้น
- ติดตั้ง Samba
apt install samba
- สร้าง UNIX user
john สำหรับ Samba โดยเฉพาะ แล้วตั้งรหัสผ่าน
useradd -m john
passwd john
- ใช้
smbpasswd -a john เพื่อเชื่อม UNIX user john กับผู้ใช้ Samba
- host ที่เชื่อมต่อสามารถเข้าถึง share ด้วย
SYS\john
- ตรวจสอบการลงทะเบียนผู้ใช้ Samba ด้วย
pdbedit -L -v john
- ลบผู้ใช้ Samba ด้วย
pdbedit -x -u john
แชร์ทั่วไปและแชร์ Time Machine
- แก้ไข
/etc/samba/smb.conf เพื่อตั้งค่า share docs และ 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 ถูกตั้งค่าเป็น SMB share สำหรับการใช้งานทั่วไปbackups มี property สำหรับ macOS Time Machine
fruit:aapl = yesfruit:time machine = yesvfs objects = catia fruit streams_xattr
- บน macOS ให้กด
cmd+K ใน Finder แล้ว mount ในรูปแบบ smb://10.0.0.6/docs หรือ smb://10.0.0.6/backups
- บนระบบตระกูล Debian ให้ติดตั้ง
smbclient แล้วทดสอบดังนี้
apt install smbclient
smbclient -U john //10.0.0.6/docs -c 'ls'
- เมื่อ mount
smb://10.0.0.6/backups บน macOS จะแสดงเป็น Time Machine share
- หลัง mount แล้ว สามารถเพิ่ม share นั้นใน Settings > General > Time Machine ของ macOS เพื่อเริ่ม Time Machine backup ได้
รายการที่ไม่ครอบคลุม
- ขั้นตอนนี้ไม่รวมการตั้งค่าการเข้ารหัส
- ไม่รวมกลยุทธ์การสำรองข้อมูลด้วย
- ฟีเจอร์การ replication ของ ZFS dataset มีแผนจะขยายต่อในบทความแยกภายหลัง
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
ในแง่ราคา ตอนนี้ไม่ใช่ช่วงเวลาที่ดีสำหรับการ สร้าง NAS แต่ผมก็ทำอยู่ตลอด 2 สัปดาห์ที่ผ่านมา ใช้เคส Jonsbo N6 ซึ่งมี SATA backplane 8 ช่องกับ drive bay เลยถือว่าใช้ได้ทีเดียว ต่างจากรุ่น Jonsbo ก่อน ๆ
สุดท้ายตัดสินใจแกะ WD Elements Desktop 14TB จำนวน 4 ตัวมาใช้ ข้างในเป็นไดรฟ์ WD140EDGZ แบบเติมฮีเลียม ราคาถูกกว่า WD Red Plus 12TB จำนวน 4 ตัวราวหนึ่งในสาม และประสิทธิภาพก็ดูใกล้เคียงกัน การรับประกันเป็นข้อเสียชัดเจน แต่ถ้าเสียในช่วงรับประกัน 2 ปี ก็น่าจะใส่กลับเข้าเคสภายนอกได้
ใส่ M.2 SSD 256GB มือสองเป็นไดรฟ์บูต และค่อนข้างลำบากกับการใช้ LUKS, คีย์ TPM และ root ZFS ร่วมกัน เพื่อให้แม้ไดรฟ์หนึ่งตัวเสียก็ยังไม่ทำให้บูตไม่ได้ ได้เรียนรู้ systemd-boot ไปมาก และรู้สึกว่ามันปกติกว่า grub มาก
ยังรู้สึกด้วยว่า ZFS มีทั้งตำนานและ cargo cult อยู่เยอะ ตัวอย่างเช่น บทความพูดถึง ECC RAM แต่เรื่องที่ว่ามันจำเป็นเพราะ ZFS จะทำให้ pool พังระหว่าง scrub นั้นแทบจะเป็นตำนาน และปีนี้โดยเฉพาะก็แพงมาก ZFS ไม่ได้ต้องใช้ RAM เยอะ และ L2ARC ก็ไม่ได้กิน RAM มากเช่นกัน
ตอนนี้ยังลังเลว่าจะตั้ง
dnodesize=autoไหม เพราะมีเรื่องเล่าน่ากลัวที่เกี่ยวข้อง: https://github.com/openzfs/zfs/issues/11353 และยังหาผู้ให้บริการ cloud storage ราคาสมเหตุสมผลที่รองรับzfs sendได้ยาก ส่วน Rsync.net เพิ่งเพิ่มขั้นต่ำการสั่งซื้อเป็น 10TiB ซึ่งใหญ่เกินไปสำหรับการใช้งานของผม: https://www.rsync.net/products/zfsintro.htmlถ้ามีตัวเลือกวิเศษ ผมแทบจะอยากเลือกโลกที่ไม่มี AI เลย แต่สตอเรจมีราคาเหลือหนึ่งในสิบของราคาก่อนยุค AI
ผมก็ยอมเสียไดรฟ์ไป 2 ตัวเพื่อ redundancy อยู่แล้ว และจริง ๆ เมื่อเร็ว ๆ นี้ SSD 2 ตัวที่ดูเหมือนมาจากล็อตเดียวกันตายต่อกัน ก็ช่วยไว้ได้ แต่ถ้าต้องทำตามคำแนะนำที่ให้เว้นว่างเพิ่มอย่างน้อยเท่ากับไดรฟ์อีกหนึ่งตัวเพื่อประสิทธิภาพและเสถียรภาพด้วย ราคาตอนนี้ก็เจ็บพอตัว
หลังจากดู https://words.filippo.io/frood/ และ https://0pointer.net/blog/fitting-everything-together.html แล้ว ผมกำลังดูแนวทางการประกอบ home server/NAS ด้วย mkosi/systemd อยู่ น่าสนใจดีที่ได้เห็นว่าคอนฟิกต่าง ๆ แก้ปัญหานี้กันอย่างไร
/bootถูกเข้ารหัสและป้องกันการแก้ไขดัดแปลงด้วยไหม, และทนต่อการโจมตีแบบ evil maid ได้ไหมรู้ว่าเป็นโพรงกระต่าย แต่ถ้าแก้ได้หมดจริง ๆ ก็น่าสนใจมาก
https://www.samsung.com/us/memory-storage/nvme-ssd/990-pro-p...
สิ่งที่มีประโยชน์บน NAS: ถ้าติดตั้ง avahi-daemon แล้ว Samba จะโฆษณา SMB/CIFS ผ่าน DNS-SD ไปยังไคลเอนต์ macOS และ Linux โดยอัตโนมัติ
สำหรับการค้นพบอัตโนมัติใน Explorer ของไคลเอนต์ Windows 10 ขึ้นไปที่ปิด SMB 1.0 ไว้ ให้ติดตั้ง wsdd2
hostname ของ Linux มักเป็นตัวพิมพ์เล็ก แต่โดยค่าเริ่มต้น Samba จะเผยแพร่ชื่อที่ขึ้นต้นด้วยตัวพิมพ์ใหญ่ไปยัง NetBIOS และ Avahi ถ้ารำคาญ ให้ตั้ง
host-name=somethingใน[server]ของ/etc/avahi/avahi-daemon.confและใส่mdns name = mdnsใน[global]ของ/etc/samba/smb.confถ้ามีไคลเอนต์ macOS ควรเปิด vfs_fruit ในการตั้งค่า Samba: https://www.samba.org/samba/docs/current/man-html/vfs_fruit.... นอกจากเหตุผลเรื่องความเข้ากันได้แล้ว หลัก ๆ คือสามารถตั้ง
fruit:modelเพื่อให้มีไอคอนสนุก ๆ แสดงใน sidebar ของ Finder ได้ถ้าต้องการกันไม่ให้สร้าง
.DS_Storeก็ห้ามได้: https://ryanoberto.github.io/blog/2015/04/01/disabling-the-c... น่าจะเก็บการตั้งค่า Finder ไว้ใน extended attributes ได้ด้วยfruit:resource = xattrแต่ยังไม่ได้ลองเองmacOS เคยบอกไว้นานแล้วว่าจะใช้ SMB แทน AFP และใน macOS 27 ก็จะถอดการรองรับไคลเอนต์ AFP ออกด้วย แต่การรองรับ SMB client ของ macOS ก็ยังค่อนข้างแย่อยู่ จนกว่าจะถึงตอนนั้น ผมจะยังรัน Netatalk คู่กับ Samba ต่อไป และ Netatalk ก็ลงทะเบียนกับ Avahi ด้วย ขณะที่ macOS นั้นมีนัยสำคัญตรงที่ให้ความสำคัญกับ AFP มากกว่า SMB ดังนั้นไคลเอนต์จะไปเกาะกับ daemon ที่ถูกต้องโดยอัตโนมัติ
homesแบบค่าเริ่มต้นมันชวนให้รู้สึกขัดใจอะไรบางอย่างผมน่าจะลิงก์บทความในบล็อกของตัวเองที่สร้าง NAS แบบนี้ แต่ประกอบด้วยเทคโนโลยีที่ค่อนข้างต่างออกไปอย่าง dm-integrity, mdadm, XFS ได้อย่างเหมาะสม ในฐานะนักพัฒนา C/C++ ผมติดตามการพัฒนา OpenZFS อย่างใกล้ชิด แล้วรู้สึกกังวลในแง่เสถียรภาพกับแนวโน้มที่เน้นฟีเจอร์ขนาดใหญ่ และปัญหาต่อเนื่องที่เกิดจาก SPL/แคชเพจแยกต่างหาก
ผมยอมลำบากช่วงแรกแทนความสะดวกของเครื่องมือสารพัดประโยชน์อย่าง ZFS แต่ตอนนี้พอใจกับตัวเลือกนี้มาก
https://world-playground-deceit.net/blog/2025/06/nas-setup-l...
ตอนทำ NAS ผมก็ได้ข้อสรุปเดียวกัน ระบบใช้ Nix, RAID ใช้ zfs และบริการที่อยากรันก็ใช้ docker compose ก็พอแล้ว
https://www.splitbrain.org/blog/2025-08/03-diy_nas_on_nixos
เบื่อแร็กในตู้เสื้อผ้าที่เสียงดังและกินไฟมาก สุดท้ายเลยกลายเป็นทั้งโฮมเซิร์ฟเวอร์แบบ all-in-one และเราเตอร์
https://HomeFree.host
เหตุผลที่ยังยอมจ่ายเงินให้ Synology คือเมื่อดิสก์เสีย ก็แค่ดึงถาดออก เปลี่ยนดิสก์ ใส่กลับเข้าไป แล้วคลิกวิดเจ็ตไม่กี่อันก็จบ รู้ได้ว่ามันจะ rebuild ได้อย่างถูกต้อง
ถ้าดิสก์เสีย มันจะมีเสียงบี๊บ และ LED ใกล้ดิสก์ที่มีปัญหาจะติด ทำให้รู้ว่าต้องทำอะไร
การสร้าง NAS แบบที่อธิบายในบทความนั้นทำได้ง่าย แต่ระยะยาวโอกาสข้อมูลสูญหายจะสูงกว่ามาก
และผมมองว่าไกด์แบบนี้ที่ไม่พูดถึง “วิธีเปลี่ยนดิสก์หมายเลข 3 อย่างปลอดภัยเมื่อมันเสีย” ยังไม่สมบูรณ์ ต่อให้ไม่อธิบายว่าจะรู้ได้อย่างไรว่าดิสก์เสีย อย่างน้อยก็ควรมีขั้นตอนนั้น
ดังนั้นเวลาเปลี่ยนไดรฟ์ mdadm ต้องสร้างทั้งไดรฟ์ใหม่ทั้งหมด แต่ ZFS สร้างใหม่เฉพาะข้อมูลที่ใช้งานจริงเท่านั้น
zpool replace my_pool disk3 newdiskผู้คนคงมีเหตุผลที่ผลักดัน ZFS และองค์ประกอบต่าง ๆ ที่ปกติเรียกว่า “NAS” ไปไกลขนาดนั้น แต่สำหรับผม แค่รันการตั้งค่า NFSv3 แบบเข้มงวดบน HDD ความจุสูงลูกเดียวที่ใช้ ext4 ในเครื่อง Linux ก็สะดวกพอสมควรแล้ว
ยังไงมันก็เป็นระบบหลักที่เปิดอยู่เสมอตอนผมตื่น และสามารถให้ไฟล์กับอุปกรณ์อื่น ๆ ได้โดยใช้ไฟและโอเวอร์เฮดของเครื่องเดียว
ผมพยายามคงการตั้งค่าเครือข่ายให้จำกัดเป็นพื้นฐานอยู่แล้ว เลยไม่ได้กังวลเรื่องความปลอดภัยจากการรันบนเครื่องหลักมากนัก บางทีผมอาจกำลังก่อบาปร้ายแรงอยู่ก็ได้ แต่แค่ NFSv3 ล้วน ๆ กับ Samba เพื่อความเข้ากันได้ มันไม่พอจริง ๆ หรือ?
เหตุผลหลักที่ผู้คนเลือก ZFS และ “NAS” คือ checksum และการปกป้องความถูกต้องของข้อมูล และก็เพราะไม่อยากให้เครื่องหลักต้องเปิดตื่นอยู่ตลอดเวลา
ฟีเจอร์อย่าง snapshot ก็มีประโยชน์ ช่วยลดความกังวลว่าจะเสียข้อมูลจากการลบหรือเขียนทับไฟล์โดยไม่ตั้งใจ
ผมคิดว่าการใช้เครื่องหลักที่เปิด 24 ชั่วโมงเป็น NAS เองไม่ได้มีปัญหา ไม่จำเป็นต้องฝืนซื้ออะไรเพื่อสิ่งใดสิ่งหนึ่ง แต่ผมกังวลเรื่องความเชื่อถือได้และการป้องกัน bit rot มันเกิดขึ้นจริง และผมก็เคยเห็นกับตาเพราะ ZFS
ถ้าอยากคงคอนฟิกเรียบง่ายไว้ อาจพิจารณาเก็บรายการแฮชของไฟล์และตรวจสอบเป็นระยะ
ควรใช้โปรแกรมแบ็กอัปที่รองรับ snapshot ด้วย และ Restic ก็เป็นตัวเลือกที่ดี
อีกทางคือซื้อฮาร์ดดิสก์อีกลูกที่ขนาดเท่าดิสก์ปัจจุบัน แล้วใช้ SnapRAID จัดการความถูกต้องของไฟล์ หรือทำมิเรอร์ 2 ดิสก์ด้วย btrfs
Cockpit มีประโยชน์มากสำหรับการจัดการ NAS และ VPS แม้ด้วย LLM แล้วการตั้งค่าเองจะไม่ใช่ปัญหาใหญ่ แต่การมีแดชบอร์ดที่มี toggle และล็อกที่จัดระเบียบไว้ก็สะดวก และยังรันคำสั่ง shell จากมือถือได้โดยไม่ต้องใช้ SSH
บน NAS สามารถดูผลลัพธ์ของงาน cron สำหรับแบ็กอัป/บำรุงรักษาได้ง่าย จัดการ Samba และมอนิเตอร์การใช้ดิสก์ได้ โดยเฉพาะการทำให้ Samba ทำงานกับ iPhone ได้อย่างถูกต้องนั้นปวดหัวจริง ๆ
สำหรับการยืนยันตัวตนกับเซิร์ฟเวอร์ ผมมักจะไม่ลดระดับไปใช้วิธีอื่นนอกจาก public key/private key และสุดท้ายก็ทำให้ SSH จากมือถือได้อยู่ดี ตรงนี้ผมระแวงแบบเกือบ ๆ ทฤษฎีสมคบคิดหน่อย ๆ
ตอนที่เคยสร้าง NAS เอง ผมก็ใช้บทความนี้เป็นสื่อเรียนรู้ด้วย: https://xyny.art/blog/2026-building-nas/
การสร้าง NAS ตั้งแต่ศูนย์ สนุกจริง ๆ อุปสรรคเล็ก ๆ คือไม่มี “เอกสารครบถ้วน” ที่ครอบคลุมหัวข้อทั้งหมดแบบไม่ตกหล่น แต่ขณะเดียวกันนั่นก็เป็นส่วนหนึ่งของความสนุกด้วย
จุดประสงค์ของบทความผมก็ใกล้เคียงกับการเพิ่ม “ไกด์” การตั้งค่า NAS ที่มีอคติอีกชิ้นหนึ่งลงบนอินเทอร์เน็ต ถึงจะระวังที่จะเรียกว่าไกด์ แต่ถ้าต้องทำเรื่องเดียวกันอีกครั้ง ผมคงอ่านบทความของตัวเองก่อนแน่นอน
ในเชิงแนวคิด รันสิ่งเดียวกัน แต่ใช้ FreeBSD แทน Debian ไม่ได้ดีกว่าหรือแย่กว่า เพียงแต่มี trade-off ต่างกัน และสุดท้ายก็ทำงานได้ดีเหมือนกัน
ตอนสร้าง NAS ใหม่ ผมตัดสินใจใช้ NFS บน ZFS แต่เป้าหมายต่างจากผู้เขียนเล็กน้อย ผมใช้ CPU/เมนบอร์ดที่กินไฟต่ำ และสร้างระบบแยกกันสองชุดที่ทำ failover ได้ เพื่อจัดเป็นรูปแบบ high availability
จริง ๆ แล้วผมยังเขียนซอฟต์แวร์แบบคัสตอมสำหรับจัดการ failover และการทำสำเนาข้อมูลด้วย ในการทดสอบ ระหว่าง failover การเขียนของไคลเอนต์หยุดไปเพียงไม่กี่วินาที สงสัยว่าถ้าเขียนบทความเรื่องนี้จะมีคนสนใจไหม