Synology, QNAP, TrueNAS के बिना न्यूनतम ZFS NAS बनाना (2024)

 (neil.computer)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अगर GUI की ज़रूरत नहीं है, तो सिर्फ ZFS dataset बनाकर उसे Samba से शेयर करने के संयोजन से एक पर्याप्त रूप से सरल network storage तैयार किया जा सकता है
  • उदाहरण वातावरण Debian 12 Bookworm, OpenZFS zfs-2.1.1, RAIDZ1, ECC RDIMM 16GB RAM, 4×4TB NVMe SSD पर आधारित है, और encryption तथा backup strategy इस दायरे में शामिल नहीं हैं
  • ZFS pool और filesystem की configuration डिस्क पर ही स्टोर करता है, इसलिए OS खराब हो जाने पर भी दूसरी मशीन में zfs import से डेटा वापस लाया जा सकता है
  • डिस्क को /dev/nvme1 जैसे क्रम-निर्भर नामों की बजाय /dev/disk/by-id या /etc/zfs/vdev_id.conf में दिए गए alias से निर्दिष्ट करना अधिक सुरक्षित है
  • वास्तविक network sharing Samba संभालता है, और सामान्य document sharing तथा macOS Time Machine sharing को docs, backups dataset में अलग करके कॉन्फ़िगर किया जाता है

खुद बनाने वाले न्यूनतम NAS का दायरा

  • लक्ष्य यह है कि Synology, QNAP, TrueNAS जैसे full-feature NAS products के बिना basic NAS को सीधे खुद बनाया जाए
  • उदाहरण configuration निम्न दायरे तक सीमित है
    • RAID level: RAIDZ1, 1 drive failure तक सहनशील
    • ऑपरेटिंग सिस्टम: Debian 12 Bookworm
    • encryption: नहीं
    • ZFS implementation: OpenZFS, zfs-2.1.1
    • CPU: 4-core, कम-कीमत Xeon server CPU इस्तेमाल किया जा सकता है
    • RAM: ECC RDIMM RAM 16GB
    • storage: 4×4TB NVMe SSD
    • backup: शामिल नहीं है, अलग configuration की आवश्यकता है
  • TrueNAS एक full-featured enterprise-grade software suite के अधिक करीब है, इसलिए जितनी सरल ज़रूरतें हों, उतना ही इसके फीचर्स और आवश्यकताओं के बीच mismatch बढ़ सकता है
  • खुद configuration करने पर सिस्टम के हर हिस्से को समझा जा सकता है, और किसी दूसरे software suite पर निर्भर रहना भी ज़रूरी नहीं रहता

ZFS डिस्क पर कौन-सी configuration जानकारी रखता है

  • ZFS filesystem self-contained है, इसलिए host OS खराब हो जाने पर भी अगर डिस्क सुरक्षित हैं तो डेटा वापस पाया जा सकता है
  • डिस्क को नई मशीन या नए OS से जोड़कर zfs tool install करने के बाद zfs import चलाने पर मौजूदा pool इम्पोर्ट किया जा सकता है
  • ZFS की configuration और details डिस्क पर ही स्टोर होती हैं
    • उदाहरण के लिए, अगर 6 डिस्क से RAIDZ2 बनाया गया था, तो उन डिस्क को ZFS tools वाली नई मशीन में ले जाकर सिर्फ zfs import चलाने पर भी वह RAIDZ2 के रूप में दिखाई देगा
  • host OS या मशीन में समस्या होने पर भी, अगर डिस्क खराब नहीं हुई हैं, तो डेटा बना रहता है

डिस्क पहचान और alias configuration

  • Linux मशीन में डिस्क सूची lsblk -d -o TRAN,NAME,TYPE,MODEL,SERIAL,SIZE से देखी जाती है
  • उदाहरण में Samsung SSD 990 PRO 4TB NVMe drive की 4 इकाइयाँ इस्तेमाल की गई हैं
  • हर डिस्क का /dev/disk/by-id के नीचे ID और /dev/nvme... device name से जुड़ा symbolic link होता है
  • /etc/zfs/vdev_id.conf में alias परिभाषित करने से लंबे disk ID को छोटे नाम से map किया जा सकता है
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 चलाने या reboot करने पर alias लागू हो जाते हैं
  • यह लागू हुआ है या नहीं, इसे ls -lh /dev/disk/by-vdev से देखा जा सकता है
  • Alias mapping वैकल्पिक है; zpool बनाते समय पूरा /dev/disk/by-id/... path सीधे भी लिखा जा सकता है
  • /dev/nvme1, /dev/nvme2 जैसे device name से बचना चाहिए, क्योंकि नई drive लगाने पर इनका क्रम निश्चित नहीं रहता
  • /etc/zfs/vdev_id.conf zpool creation की सुविधा के लिए है; OS खराब होकर यह फ़ाइल खो भी जाए, तब भी ZFS pool पर कोई असर नहीं पड़ता

zpool बनाना और dataset configuration

  • उदाहरण में 4 NVMe से RAIDZ1 zpool बनाया जाता है, जो RAID 5 की तरह 1 drive failure तक सहन कर सकता है
  • अगर अधिक fault tolerance चाहिए, तो RAIDZ2 यानी RAID 6 configuration अधिक resilient है
  • ZFS installation के लिए OpenZFS installation docs देखें; उदाहरण के तौर पर RHEL 9 में dnf install zfs से install किया जाता है
  • zpool बनाते समय ashift=12 option की सिफारिश की जाती है
    • compatibility के कारण कई डिस्क OS को 512KB sector size के रूप में रिपोर्ट करती हैं
    • Samsung 990 Pro जैसी high-capacity डिस्क में 4KB या 8KB sector size हो सकती है
    • ashift=12 4KB sector size को दर्शाता है और performance को काफी बेहतर बना सकता है
    • zpool creation के समय यह मान सेट करना आख़िरी मौका होता है
zpool create -o ashift=12 s16z1 raidz1 nvme0 nvme1 nvme2 nvme3
zpool status s16z1
  • zpool डिस्क abstraction है, और zfs filesystem है
  • zpool create चलाने पर ZFS filesystem भी साथ में बन जाता है
  • zdb | grep ashift से ashift: 12 सेट हुआ है या नहीं, यह जाँचा जा सकता है
  • share करने से पहले mount point और compression सेट किए जाते हैं
zfs set mountpoint=/mnt/s16z1 s16z1
zfs set compression=lz4 s16z1
  • root dataset के नीचे docs और backups dataset बनाए जाते हैं
zfs create s16z1/docs
zfs create s16z1/backups
  • docs दस्तावेज़ों के लिए और backups Time Machine backup के लिए इस्तेमाल होता है
  • ZFS dataset साधारण folder की तुलना में अधिक फीचर देते हैं
    • dataset-स्तर property management
    • encryption
    • transfer और replication
    • snapshots
  • बड़े फ़ाइल वर्गों के हिसाब से अलग dataset बनाना बेहतर रहता है
  • उदाहरण के लिए, अगर सिर्फ docs को remote server पर backup करना हो, तो पूरे s16z1 root dataset को भेजने की ज़रूरत नहीं होती

Samba के लिए share account बनाना

  • network file sharing का तरीका ZFS से स्वतंत्र है; ZFS का सिर्फ host system पर mount होना ज़रूरी है
  • Samba install करें
apt install samba
  • Samba के लिए अलग UNIX user john बनाकर उसका password सेट करें
useradd -m john
passwd john
  • smbpasswd -a john से UNIX user john को Samba user से जोड़ा जाता है
  • कनेक्ट होने वाला host SYS\\john के रूप में share को access कर सकता है
  • pdbedit -L -v john से Samba user registration की पुष्टि की जा सकती है
  • Samba user हटाने के लिए pdbedit -x -u john का उपयोग किया जाता है

सामान्य share और Time Machine share

  • /etc/samba/smb.conf को edit करके docs और backups share configure किए जाते हैं
[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 को सामान्य-purpose SMB share के रूप में configure किया जाता है
  • backups में macOS Time Machine के लिए आवश्यक properties शामिल हैं
    • fruit:aapl = yes
    • fruit:time machine = yes
    • vfs objects = catia fruit streams_xattr
  • macOS में Finder में cmd+K दबाकर smb://10.0.0.6/docs या smb://10.0.0.6/backups फ़ॉर्मेट से mount किया जाता है
  • Debian-आधारित सिस्टम में smbclient install करने के बाद इस तरह test किया जा सकता है
apt install smbclient
smbclient -U john //10.0.0.6/docs -c 'ls'
  • smb://10.0.0.6/backups mount करने पर macOS में यह Time Machine share के रूप में दिखाई देता है
  • mount के बाद macOS के Settings > General > Time Machine में उस share को जोड़कर Time Machine backup शुरू किया जा सकता है

शामिल नहीं किए गए विषय

  • encryption configuration इस प्रक्रिया में शामिल नहीं है
  • backup strategy भी शामिल नहीं है
  • ZFS dataset replication फीचर को बाद में किसी अलग लेख में विस्तार से शामिल करने की योजना है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • कीमत के लिहाज़ से अभी NAS बनाना अच्छा समय नहीं है, लेकिन पिछले 2 हफ्तों से मैं एक बना रहा हूँ। मैं Jonsbo N6 case इस्तेमाल कर रहा हूँ, और इसमें 8 SATA backplane और drive bay हैं, इसलिए पुराने Jonsbo models से अलग यह काफ़ी अच्छा है
    आख़िरकार मैंने 14TB WD Elements Desktop के 4 drives निकालकर इस्तेमाल करने का फैसला किया, और इनके अंदर helium-filled drive WD140EDGZ निकली। यह 12TB WD Red Plus के 4 drives की तुलना में लगभग एक-तिहाई सस्ती है और performance भी मिलती-जुलती लगती है। warranty निश्चित रूप से एक कमी है, लेकिन अगर 2 साल की warranty अवधि में खराब हो जाए तो शायद इसे फिर से external case में रखा जा सकता है
    boot drive के लिए मैंने एक used 256GB M.2 SSD लगाया, और LUKS, TPM key, root ZFS को साथ में इस्तेमाल करते हुए ऐसा सेटअप बनाने में काफ़ी मेहनत लगी कि एक drive fail हो जाए तो भी boot रुक न जाए। इस दौरान systemd-boot के बारे में बहुत सीखा, और यह grub से काफ़ी ज़्यादा ठीक-ठाक लगा
    यह भी महसूस हुआ कि ZFS को लेकर बहुत से myths और cargo cult मौजूद हैं। उदाहरण के लिए लेख में ECC RAM का ज़िक्र है, लेकिन यह कहना कि ZFS scrub के दौरान pool खराब कर देगा इसलिए यह ज़रूरी है, लगभग myth जैसा है, और इस साल तो यह ख़ास तौर पर बहुत महँगा है। ZFS को इतना ज़्यादा RAM भी नहीं चाहिए और L2ARC भी बहुत RAM इस्तेमाल नहीं करता
    मैं अभी भी सोच रहा हूँ कि dnodesize=auto रहने दूँ या नहीं, क्योंकि इससे जुड़ी डरावनी कहानियाँ हैं: https://github.com/openzfs/zfs/issues/11353. और उचित कीमत पर zfs send सपोर्ट करने वाला cloud storage provider ढूँढना मुश्किल है, और Rsync.net ने हाल ही में minimum order 10TiB कर दिया है, जो मेरे उपयोग के लिए बहुत बड़ा है: https://www.rsync.net/products/zfsintro.html

    • “कीमत के लिहाज़ से अच्छा समय नहीं है” कहना कम है। अभी NAS बनाने के लिए भयानक कीमतें चल रही हैं
      अगर कोई जादुई विकल्प हो, तो मैं शायद लगभग यह चुनूँ कि AI बिल्कुल न हो लेकिन storage की कीमत AI से पहले वाली कीमत की 10% रह जाए
    • मैं 8-drive वाला ZFS RAIDZ2 pool चला रहा हूँ, और सोच रहा हूँ कि ZFS के free space recommendation cargo cult हैं या सचमुच ज़रूरी
      redundancy के लिए मैं पहले ही 2 drives छोड़ चुका हूँ, और हाल ही में एक जैसे batch के लगने वाले 2 SSD लगातार खराब हुए, तो इससे मदद मिली। लेकिन अगर performance और reliability के लिए कम-से-कम एक drive जितनी जगह और खाली छोड़ने की सलाह भी मानूँ, तो मौजूदा कीमतों पर यह काफ़ी दर्दनाक है
    • यह जानने की उत्सुकता है कि “Debian-based NAS को debootstrap करने वाली बड़ी script” का कोई हिस्सा public है या नहीं
      https://words.filippo.io/frood/ और https://0pointer.net/blog/fitting-everything-together.html देखने के बाद, मैं home server/NAS को mkosi/systemd से बनाने के तरीक़े देख रहा हूँ। अलग-अलग setups इस समस्या को कैसे हल करते हैं, यह देखना दिलचस्प है
    • यह जानना चाहता हूँ कि LUKS और TPM key का संयोजन वास्तव में ठीक से काम करता है या नहीं। server reboot होने पर क्या TPM root filesystem को unlock कर सकता है, क्या /boot encrypted और tamper-protected रहता है, और क्या यह evil maid attack के ख़िलाफ़ टिकता है
      यह एक rabbit hole है, लेकिन अगर किसी ने यह सब हल कर लिया है तो यह सच में दिलचस्प है
    • Samsung SSD 990 PRO 4TB NVMe SSD के 4 drives, हर एक 1100 डॉलर के हैं। सिहरन पैदा कर देने वाला
      https://www.samsung.com/us/memory-storage/nvme-ssd/990-pro-p...

  • NAS पर उपयोगी लगी चीज़ें: avahi-daemon install करने पर Samba अपने-आप SMB/CIFS को DNS-SD के ज़रिए macOS और Linux clients पर advertise करता है
    Windows 10 या उसके बाद के versions में, जिन clients पर SMB 1.0 बंद है, उनके Explorer auto-discovery के लिए wsdd2 install कर सकते हैं
    Linux hostnames आमतौर पर lowercase होते हैं, लेकिन Samba default रूप से NetBIOS और Avahi में uppercase से शुरू होने वाले नाम publish करता है। अगर यह खटकता हो, तो /etc/avahi/avahi-daemon.conf के [server] में host-name=something सेट करें, और /etc/samba/smb.conf के [global] में mdns name = mdns रखें
    अगर macOS clients हैं, तो Samba config में vfs_fruit चालू करना अच्छा है: https://www.samba.org/samba/docs/current/man-html/vfs_fruit..... compatibility की वजह से भी, लेकिन मुख्य रूप से इसलिए कि fruit:model सेट करके Finder sidebar में मज़ेदार icons दिखाए जा सकते हैं
    .DS_Store बनने से रोकना हो तो इसे disable किया जा सकता है: https://ryanoberto.github.io/blog/2015/04/01/disabling-the-c.... शायद fruit:resource = xattr के साथ Finder settings को extended attributes में भी रखा जा सकता है, लेकिन मैंने खुद यह नहीं आज़माया
    macOS ने बहुत पहले कहा था कि वह AFP को SMB से replace करेगा, और macOS 27 में AFP client support भी हटने वाला है, लेकिन macOS का SMB client support अभी भी काफ़ी खराब है। तब तक मैं Samba के साथ Netatalk भी चलाता रहूँगा, और Netatalk भी Avahi में register हो जाता है, जबकि macOS दिलचस्प तौर पर SMB से पहले AFP को प्राथमिकता देता है, इसलिए client अपने-आप सही daemon से जुड़ जाता है

    • Samba में user home directories को अलग entries के रूप में जोड़ना बेहतर है। default homes directory setting में कुछ ऐसा है जो अजीब बेचैनी पैदा करता है

  • ऐसा NAS बनाते समय dm-integrity, mdadm, XFS जैसी काफ़ी अलग तकनीकों से बनी मेरी ब्लॉग पोस्ट का लिंक देना भी उपयुक्त लग सकता है। C/C++ डेवलपर के रूप में OpenZFS डेवलपमेंट को नज़दीक से फ़ॉलो करते हुए, बड़े फीचर्स पर केंद्रित रुझान और SPL/अलग page cache की वजह से पैदा होने वाली लगातार समस्याएँ मुझे स्थिरता के लिहाज़ से चिंताजनक लगीं
    ZFS जैसे सर्वगुणसंपन्न टूल की सुविधा छोड़कर मैंने शुरुआत की मुश्किलें झेलीं, लेकिन अब मैं अपने इस चुनाव से बहुत संतुष्ट हूँ
    https://world-playground-deceit.net/blog/2025/06/nas-setup-l...

  • NAS बनाते समय मैं भी इसी निष्कर्ष पर पहुँचा। सिस्टम के लिए Nix, RAID के लिए zfs, और जिन services को चलाना था उनके लिए docker compose काफ़ी था
    https://www.splitbrain.org/blog/2025-08/03-diy_nas_on_nixos

    • मैं भी अपने NAS पर NixOS इस्तेमाल करता हूँ। कंटेनर मैनेजमेंट के लिए Nix के साथ quadlets, यानी systemd द्वारा मैनेज किए जाने वाले Docker containers, देखना अच्छा रहेगा
    • मैं भी इसी तरह NixOS को NAS के रूप में इस्तेमाल कर रहा हूँ, और यह इतना बढ़ गया है कि अब मैं इसे दूसरे लोगों के साथ भी साझा करने की तैयारी कर रहा हूँ। फ़र्क बस इतना है कि मैं MDADM के ऊपर BTRFS इस्तेमाल करता हूँ
      अलमारी में रखे शोरगुल वाले और ज़्यादा बिजली खाने वाले rack से तंग आकर, यह आखिरकार all-in-one home server और router बन गया
      https://HomeFree.host

  • मैं अब भी Synology की कीमत इसलिए चुकाता हूँ, क्योंकि डिस्क खराब होने पर बस tray निकालो, डिस्क बदलो, वापस लगाओ, और कुछ widgets पर क्लिक करो, काम ख़त्म। मुझे पता होता है कि यह सही तरह से rebuild हो जाएगा
    डिस्क खराब होने पर beep बजती है और समस्या वाली डिस्क के पास LED जल उठती है, इसलिए क्या करना है यह भी साफ़ पता चल जाता है
    लेख में बताए गए जैसी NAS बनाना आसान है, लेकिन लंबी अवधि में data loss की संभावना कहीं ज़्यादा हो जाती है
    और मेरी नज़र में, “जब disk 3 फेल हो जाए तो उसे सुरक्षित रूप से कैसे बदलें” जैसी बात शामिल न करने वाली ऐसी गाइड अधूरी है। भले यह न बताए कि डिस्क फेलियर का पता कैसे चले, कम से कम वह प्रक्रिया तो होनी ही चाहिए

    • समझ नहीं आया कि snooty, Synology का कोई autocomplete typo है या कोई दूसरा product
    • असल में ZFS ठीक इसी तरह काम करता है। यह सही है कि गाइड पूरी नहीं है, लेकिन array rebuild के लिए बस डिस्क बदलनी होती है और एक ZFS command चलानी होती है
    • ZFS, drive failure को किसी भी दूसरे विकल्प की तुलना में कहीं ज़्यादा मज़बूती से हैंडल करता है। Synology, built-in BTRFS RAID features की जगह BTRFS के नीचे mdadm इस्तेमाल करता है, इसके पीछे कारण है, और mdadm device स्तर पर काम करता है
      इसलिए drive बदलते समय mdadm को पूरी drive फिर से बनानी पड़ती है, जबकि ZFS सिर्फ़ वास्तव में इस्तेमाल हो रहे data को दोबारा बनाता है
      zpool replace my_pool disk3 newdisk
    • ZFS में “beep और LED” वाले हिस्से को छोड़ दें, तो यह प्रक्रिया पूरी तरह मामूली हो जाती है

  • ZFS और जिन चीज़ों को लोग आम तौर पर “NAS” कहते हैं उन्हें लोग कितनी दूर तक ले जाते हैं, इसके अपने कारण होंगे, लेकिन Linux मशीन पर ext4 single large HDD के साथ सख़्त NFSv3 setup चलाकर भी मैं काफ़ी आराम से रहा हूँ
    वैसे भी यह मेरा मुख्य सिस्टम है, जो जागे रहने के दौरान हमेशा चालू रहता है, और एक ही मशीन की बिजली और overhead में दूसरी डिवाइसेज़ को फ़ाइलें दे सकता है
    मैं नेटवर्क setup को मूल रूप से सीमित रखने की कोशिश करता हूँ, इसलिए मुख्य मशीन पर चलने से जुड़े security concerns को लेकर बहुत परेशान नहीं हूँ। हो सकता है मैं कोई बड़ा पाप कर रहा हूँ, लेकिन क्या सिर्फ़ plain NFSv3 और compatibility के लिए Samba सच में इतने अपर्याप्त हैं?

    • सबसे पहले यह जानना चाहूँगा कि उस single large HDD का backup है या नहीं। मेरी सबसे बड़ी चिंता वही है। वह HDD कभी न कभी ज़रूर फेल होगा, इसलिए उस समय की योजना क्या है, यही अहम है
      लोग ZFS और “NAS” मुख्य रूप से checksums और data integrity protection के लिए चुनते हैं, और इसलिए भी कि वे अपने main machine को हमेशा जागा हुआ नहीं रखना चाहते
      snapshots जैसी सुविधाएँ भी उपयोगी हैं, क्योंकि वे गलती से फ़ाइल delete या overwrite होने पर data loss की चिंता कम करती हैं
      24x7 चालू main machine को NAS की तरह इस्तेमाल करना अपने आप में समस्या नहीं है। किसी चीज़ के लिए ज़बरदस्ती खरीदने की ज़रूरत नहीं, लेकिन reliability और bit rot protection को लेकर चिंता रहती है। यह सच में होता है, और मैंने इसे ZFS की वजह से खुद देखा है
    • उस setup में single-drive storage layout ही बड़ा मुद्दा है। एक डिस्क फेल हुई तो आप टिक नहीं पाएँगे, और अगर hardware चुपचाप data corrupt करना शुरू कर दे तो सारा data जोखिम में पड़ जाता है। यह मानकर चल रहे हैं कि backup भी उसी single hard disk के data को आधार बनाकर किया जा रहा है
      अगर आप setup को सरल रखना चाहते हैं, तो फ़ाइल hashes की सूची रखकर समय-समय पर उनकी जाँच करने का तरीका विचार करने लायक है
      snapshots सपोर्ट करने वाला backup program भी इस्तेमाल करना अच्छा होगा, और Restic एक ठीक विकल्प है
      मौजूदा डिस्क जितनी ही क्षमता वाली एक और hard disk खरीदकर SnapRAID से file integrity मैनेज की जा सकती है, या btrfs के साथ 2-disk mirror बनाया जा सकता है
    • जैसे ही कई machines एक साथ पढ़ना-लिखना शुरू करेंगी, सीमाएँ सामने आ जाएँगी। फिर भी अभी जो ज़रूरी है वही बनाना चाहिए, ज़रूरत से ज़्यादा optimization की आवश्यकता नहीं

  • Cockpit NAS और VPS मैनेजमेंट में बहुत उपयोगी रहा है। LLM की वजह से configuration खुद कोई बड़ी समस्या न भी हो, तब भी toggles वाला dashboard और व्यवस्थित logs होना सुविधाजनक है, और SSH के बिना भी फ़ोन से shell commands चला सकते हैं
    NAS पर backup/maintenance cron jobs के नतीजे आसानी से देखे जा सकते हैं, Samba मैनेज किया जा सकता है, और disk usage मॉनिटर किया जा सकता है। खासकर iPhone पर Samba को ठीक से चलाना सच में बहुत सिरदर्द वाला काम है

    • अगर SSH के बिना फ़ोन से shell commands चला रहे हैं, तो Cockpit authentication कैसे करते हैं? क्या front-end में basic HTTP auth जैसा कुछ लगाते हैं?
      मेरे मामले में, server authentication के लिए public/private key के अलावा किसी और तरीके पर जाने के बजाय, मैं आख़िरकार फ़ोन पर SSH चलने लायक बना देता हूँ। इस मामले में मैं थोड़ा साज़िश-सिद्धांत वाले अंदाज़ में सतर्क रहता हूँ

  • पहले जब मैंने अपना NAS खुद बनाया था, तब इस लेख को भी सीखने की सामग्री के रूप में इस्तेमाल किया था: https://xyny.art/blog/2026-building-nas/
    शुरुआत से NAS बनाना वास्तव में बहुत मज़ेदार है। एक छोटी रुकावट यह है कि पूरे विषय को बिना कुछ छोड़े कवर करने वाली “पूर्ण सामग्री” उपलब्ध नहीं है, लेकिन यही इसकी मज़ेदार बातों में से एक भी है
    मेरी पोस्ट का उद्देश्य भी इंटरनेट पर एक और पक्षपाती NAS कॉन्फ़िगरेशन “गाइड” जोड़ने के काफ़ी क़रीब है। इसे गाइड कहना थोड़ा सावधानी वाला मामला है, लेकिन अगर मुझे वही काम फिर से करना पड़े, तो मैं सबसे पहले अपनी ही पोस्ट पढ़ूँगा

  • अवधारणात्मक रूप से यह वही काम करता है, लेकिन Debian की जगह FreeBSD इस्तेमाल करता है। यह बेहतर या बदतर होने से ज़्यादा अलग-अलग trade-offs की बात है, और आखिरकार दोनों ही समान रूप से अच्छी तरह काम करते हैं

  • NAS को दोबारा बनाते समय मैंने ZFS के ऊपर NFS चुनने का फैसला किया। हालांकि मेरा लक्ष्य लेखक से थोड़ा अलग था। मैंने low-power CPU/मदरबोर्ड का इस्तेमाल किया और failover-सक्षम दो अलग सिस्टम बनाकर उसे high availability रूप में कॉन्फ़िगर किया।
    failover और data replication को संभालने के लिए मैंने custom software भी लिखा। टेस्ट में failover के दौरान क्लाइंट की writes सिर्फ़ कुछ सेकंड के लिए रुकीं। सोच रहा हूँ, अगर मैं इस बारे में लिखूँ तो क्या लोगों की दिलचस्पी होगी?