1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Si solo necesitas un NAS básico sin GUI, basta con crear datasets de ZFS y compartirlos con Samba para armar un almacenamiento en red simple
  • El entorno de ejemplo usa Debian 12 Bookworm, OpenZFS zfs-2.1.1, RAIDZ1, 16 GB de RAM ECC RDIMM y 4 SSD NVMe de 4 TB; el cifrado y la estrategia de respaldo quedan fuera del alcance
  • ZFS guarda la configuración del pool y del sistema de archivos en los discos, así que aunque el sistema operativo falle, puedes recuperar los datos en otra máquina con zfs import
  • Es más seguro identificar los discos con /dev/disk/by-id o con alias en /etc/zfs/vdev_id.conf que con nombres dependientes del orden como /dev/nvme1
  • Samba se encarga de la compartición real en red, separando un recurso general de documentos y otro de Time Machine de macOS en los datasets docs y backups

Alcance de un NAS mínimo hecho por ti mismo

  • El objetivo es montar por cuenta propia un NAS básico sin usar productos NAS con todas las funciones, como Synology, QNAP o TrueNAS
  • La configuración de ejemplo se limita al siguiente alcance
    • Nivel RAID: RAIDZ1, tolerancia a la falla de 1 unidad
    • Sistema operativo: Debian 12 Bookworm
    • Cifrado: ninguno
    • Implementación de ZFS: OpenZFS, zfs-2.1.1
    • CPU: 4 núcleos, se puede usar un CPU Xeon de servidor económico
    • RAM: 16 GB de RAM ECC RDIMM
    • Almacenamiento: 4 SSD NVMe de 4 TB
    • Respaldo: no se cubre y requiere una configuración aparte
  • TrueNAS se parece más a una suite de software empresarial con todas las funciones, así que mientras más simple sea lo que necesitas, mayor será el desajuste entre lo que ofrece y lo que exige
  • Si lo montas tú mismo, puedes entender cada elemento del sistema y no dependes de otra suite de software

La información de configuración que ZFS guarda en los discos

  • El sistema de archivos ZFS es autocontenido, así que aunque el SO del host se dañe, si los discos siguen sanos puedes recuperar los datos
  • Si conectas los discos a una máquina nueva o a un sistema nuevo, instalas la herramienta zfs y luego ejecutas zfs import, puedes importar el pool existente
  • La configuración y los detalles de ZFS se almacenan en los propios discos
    • Por ejemplo, si tenías un RAIDZ2 con 6 discos, basta con moverlos a una máquina nueva con las herramientas de ZFS instaladas y ejecutar zfs import para que aparezca como RAIDZ2
  • Aunque haya problemas con el sistema operativo o la máquina, si los discos no están dañados, los datos se conservan

Identificación de discos y configuración de alias

  • En una máquina Linux, la lista de discos se puede revisar con lsblk -d -o TRAN,NAME,TYPE,MODEL,SERIAL,SIZE
  • En el ejemplo se usan 4 unidades Samsung SSD 990 PRO 4TB NVMe
  • Cada disco tiene, debajo de /dev/disk/by-id, un enlace simbólico entre su ID y el nombre de dispositivo /dev/nvme...
  • Si defines alias en /etc/zfs/vdev_id.conf, puedes mapear los IDs largos de disco a nombres cortos
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
  • Al ejecutar udevadm trigger o reiniciar, los alias se aplican
  • Puedes verificarlo con ls -lh /dev/disk/by-vdev
  • Alias mapping es opcional; al crear el zpool también puedes escribir directamente la ruta completa /dev/disk/by-id/...
  • Conviene evitar nombres de dispositivo como /dev/nvme1 o /dev/nvme2, porque el orden no está garantizado cuando instalas nuevas unidades
  • /etc/zfs/vdev_id.conf es una configuración para facilitar la creación del zpool; aunque el SO se dañe y se pierda ese archivo, el pool de ZFS en sí no se ve afectado

Creación del zpool y organización de datasets

  • El ejemplo crea un zpool RAIDZ1 con 4 NVMe, que como RAID 5 tolera la falla de 1 unidad
  • Si necesitas mayor tolerancia a fallos, RAIDZ2, es decir una configuración tipo RAID 6, ofrece más resiliencia
  • Para instalar ZFS, consulta la documentación de instalación de OpenZFS; por ejemplo, en RHEL 9 se instala con dnf install zfs
  • Al crear el zpool se recomienda la opción ashift=12
    • Muchos discos reportan al SO un tamaño de sector de 512 KB por compatibilidad
    • Discos de gran capacidad como el Samsung 990 Pro pueden tener un tamaño de sector de 4 KB u 8 KB
    • ashift=12 representa un tamaño de sector de 4 KB y puede mejorar mucho el rendimiento
    • El momento de crear el zpool es la última oportunidad para fijar ese valor
zpool create -o ashift=12 s16z1 raidz1 nvme0 nvme1 nvme2 nvme3
zpool status s16z1
  • zpool es la abstracción de discos, y zfs es el sistema de archivos
  • Cuando ejecutas zpool create, también se crea el sistema de archivos ZFS
  • Puedes comprobar si quedó ashift: 12 con zdb | grep ashift
  • Antes de compartirlo, se configuran el punto de montaje y la compresión
zfs set mountpoint=/mnt/s16z1 s16z1
zfs set compression=lz4 s16z1
  • Debajo del dataset raíz se crean los datasets docs y backups
zfs create s16z1/docs
zfs create s16z1/backups
  • docs se usa para documentos y backups para respaldos de Time Machine
  • Los datasets de ZFS ofrecen muchas más funciones que una carpeta simple
    • Gestión de propiedades por dataset
    • Cifrado
    • Envío y replicación
    • Snapshots
  • Conviene crear datasets separados por categorías grandes de archivos
  • Por ejemplo, si luego quieres respaldar solo docs a un servidor remoto, no hace falta enviar todo el dataset raíz s16z1

Crear cuentas compartidas con Samba

  • El método de compartición de archivos por red es independiente de ZFS; ZFS solo necesita estar montado en el sistema host
  • Instala Samba
apt install samba
  • Crea el usuario UNIX exclusivo para Samba john y asígnale contraseña
useradd -m john
passwd john
  • Con smbpasswd -a john se vincula el usuario UNIX john con un usuario de Samba
  • Los hosts que se conecten pueden acceder al recurso como SYS\\john
  • Puedes verificar el registro del usuario Samba con pdbedit -L -v john
  • Para borrar el usuario Samba se usa pdbedit -x -u john

Recurso compartido general y recurso de Time Machine

  • Edita /etc/samba/smb.conf para configurar los recursos docs y 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 se configura como un recurso SMB de propósito general
  • backups incluye propiedades para Time Machine de macOS
    • fruit:aapl = yes
    • fruit:time machine = yes
    • vfs objects = catia fruit streams_xattr
  • En macOS, se monta desde Finder con cmd+K usando un formato como smb://10.0.0.6/docs o smb://10.0.0.6/backups
  • En sistemas de la familia Debian, puedes instalar smbclient y probar así
apt install smbclient
smbclient -U john //10.0.0.6/docs -c 'ls'
  • Si montas smb://10.0.0.6/backups, macOS lo mostrará como un recurso de Time Machine
  • Después de montarlo, en macOS puedes ir a Settings > General > Time Machine, agregar ese recurso e iniciar el respaldo con Time Machine

Elementos excluidos

  • La configuración de cifrado no está incluida en este procedimiento
  • Tampoco se incluye la estrategia de respaldo
  • La función de replicación de datasets de ZFS se planea ampliar en otra publicación posterior

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News
  • En términos de precio, ahora no es un buen momento para armar un NAS, pero he estado construyendo uno durante las últimas 2 semanas. Estoy usando un case Jonsbo N6, y como tiene backplane SATA de 8 bahías y bandejas para discos, está bastante bien, a diferencia de modelos anteriores de Jonsbo
    Al final decidí extraer 4 WD Elements Desktop de 14TB para usarlos, y adentro venían WD140EDGZ, que son discos llenados con helio. Salen como un tercio más baratos que 4 WD Red Plus de 12TB y el rendimiento parece similar. La garantía es una desventaja clara, pero si fallan dentro de los 2 años de garantía, probablemente podría volver a meterlos en sus carcasas externas
    Como unidad de arranque puse un SSD M.2 usado de 256GB, y me costó bastante lograr que LUKS, claves TPM y ZFS en raíz funcionaran juntos sin que una falla de un solo disco impidiera el arranque. Aprendí bastante de systemd-boot y se siente mucho más sensato que grub
    También siento que alrededor de ZFS hay muchos mitos y culto al cargo. Por ejemplo, en el artículo se menciona ECC RAM, pero que sea indispensable porque ZFS va a destruir el pool durante un scrub está más cerca del mito, y este año además está especialmente cara. ZFS tampoco necesita tanta RAM, y L2ARC tampoco consume tanta RAM
    Todavía estoy pensando si dejar dnodesize=auto, pero hay historias de terror al respecto: https://github.com/openzfs/zfs/issues/11353. Y es difícil encontrar un proveedor de almacenamiento en la nube a precio razonable que soporte zfs send; Rsync.net recientemente subió el pedido mínimo a 10TiB, así que para mi caso es demasiado: https://www.rsync.net/products/zfsintro.html

    • Decir que “no es un buen momento en precio” se queda corto. Ahora mismo es un precio terrible para armar un NAS
      Si hubiera una opción mágica, casi elegiría una sin nada de IA a cambio de que el almacenamiento costara una décima parte de lo que costaba antes de la IA
    • Estoy corriendo un pool ZFS RAIDZ2 de 8 discos y me pregunto si las recomendaciones de espacio libre en ZFS son culto al cargo o algo real
      Ya estoy sacrificando 2 discos por redundancia, y de hecho hace poco murieron en cadena 2 SSD que parecían del mismo lote, así que ayudó. Pero si además sigo el consejo de dejar libre al menos el equivalente a otro disco por rendimiento y estabilidad, con los precios actuales duele bastante
    • Me pregunto si hay publicada хотя бы alguna parte del “gran script que hace debootstrap de un NAS basado en Debian”
      Después de ver https://words.filippo.io/frood/ y https://0pointer.net/blog/fitting-everything-together.html, he estado mirando la idea de armar un home server/NAS con mkosi/systemd. Es interesante ver cómo distintas configuraciones resuelven este problema
    • Me pregunto si la combinación de LUKS y claves TPM realmente funciona bien. Si el servidor se reinicia, ¿el TPM puede desbloquear el sistema de archivos raíz? ¿/boot queda cifrado y protegido contra manipulaciones? ¿Resiste ataques de evil maid?
      Sé que es una madriguera de conejo, pero si ya resolviste todo eso, sería realmente interesante
    • Cuatro SSD NVMe Samsung SSD 990 PRO de 4TB cuestan 1100 dólares cada uno. De locos
      https://www.samsung.com/us/memory-storage/nvme-ssd/990-pro-p...
  • Cosas que me resultaron útiles en un NAS: si instalas avahi-daemon, Samba anuncia automáticamente SMB/CIFS por DNS-SD a clientes macOS y Linux
    Para el autodescubrimiento en Explorer de clientes con SMB 1.0 desactivado en Windows 10 o superior, basta con instalar wsdd2
    Los nombres de host en Linux normalmente van en minúsculas, pero Samba por defecto publica en NetBIOS y Avahi un nombre que empieza con mayúscula. Si te molesta, puedes poner host-name=something en [server] de /etc/avahi/avahi-daemon.conf, y mdns name = mdns en [global] de /etc/samba/smb.conf
    Si tienes clientes macOS, conviene activar vfs_fruit en la configuración de Samba: https://www.samba.org/samba/docs/current/man-html/vfs_fruit..... También por compatibilidad, pero sobre todo porque puedes configurar fruit:model para que aparezca un ícono divertido en la barra lateral de Finder
    Si quieres evitar la creación de .DS_Store, se puede bloquear: https://ryanoberto.github.io/blog/2015/04/01/disabling-the-c.... También parece posible guardar la configuración de Finder en atributos extendidos con fruit:resource = xattr, aunque no lo he probado personalmente
    Hace mucho que macOS dijo que iba a reemplazar AFP por SMB, y en macOS 27 también se eliminará el soporte del cliente AFP, pero el soporte de cliente SMB en macOS sigue siendo bastante deficiente. Hasta entonces, pienso seguir ejecutando Netatalk junto con Samba; Netatalk también se registra en Avahi, y macOS, de forma bastante reveladora, sigue prefiriendo AFP sobre SMB, así que el cliente termina conectándose automáticamente al daemon correcto

    • En Samba, conviene agregar los directorios home de usuario como entradas separadas. La configuración predeterminada del directorio homes me provoca algo parecido a TOC
  • Parece apropiado enlazar también mi entrada del blog donde armé un NAS similar, pero con tecnologías bastante distintas: dm-integrity, mdadm y XFS. Como desarrollador de C/C++, al seguir de cerca el desarrollo de OpenZFS, me preocupaba en términos de estabilidad la tendencia a enfocarse en funciones gigantescas y los problemas persistentes causados por SPL y la caché de páginas separada
    En vez de quedarme con la comodidad de ZFS como herramienta universal, asumí el sufrimiento inicial, pero ahora estoy muy satisfecho con la decisión
    https://world-playground-deceit.net/blog/2025/06/nas-setup-l...

  • Llegué a la misma conclusión al armar mi NAS. El sistema era Nix, para RAID bastaba con zfs, y para los servicios que quería correr era suficiente con docker compose
    https://www.splitbrain.org/blog/2025-08/03-diy_nas_on_nixos

    • Yo también uso NixOS en mi NAS. Para manejar contenedores, vale la pena revisar quadlets junto con Nix, o sea, contenedores Docker gestionados por systemd
    • Yo también uso algo parecido, NixOS como NAS, pero fue creciendo y ahora incluso estoy tratando de compartirlo con otras personas. Eso sí, yo uso BTRFS sobre MDADM
      Me harté del rack ruidoso y tragón de energía en el clóset, así que al final terminó siendo un servidor doméstico todo en uno y además router
      https://HomeFree.host
  • La razón por la que sigo pagando el costo de Synology es que, cuando falla un disco, basta con sacar la bandeja, cambiar el disco, volver a meterla y hacer clic en unos cuantos widgets. Sé que se va a reconstruir correctamente
    Cuando un disco falla suena un pitido y se enciende un LED cerca del disco con problema, así que también sabes qué te toca hacer
    Armar un NAS como el que describe el artículo es fácil, pero a largo plazo la posibilidad de perder datos es mucho mayor
    Y considero incompleta una guía así si no cubre “cómo reemplazar de forma segura el disco 3 cuando falla”. Aunque no explique cómo enterarte de la falla, ese procedimiento debería estar

    • Me pregunto si snooty es un error de autocorrección de Synology o si es otro producto
    • En realidad, así es exactamente como funciona ZFS. Es cierto que la guía no está completa, pero reconstruir el arreglo solo requiere cambiar el disco y ejecutar un comando de ZFS
    • ZFS maneja las fallas de discos con más solidez que cualquier otra cosa. Hay una razón por la que Synology usa mdadm debajo de BTRFS en vez de las funciones RAID integradas de BTRFS, y es que mdadm opera a nivel de dispositivo
      Por eso, al reemplazar un disco, mdadm tiene que rehacer la unidad completa, mientras que ZFS solo rehace los datos realmente en uso
      zpool replace my_pool disk3 newdisk
    • En ZFS, salvo por la parte del “pitido y el LED”, este procedimiento se vuelve completamente trivial
  • Seguro hay motivos por los que la gente lleva tan lejos ZFS y los componentes de lo que normalmente llaman un “NAS”, pero a mí me ha resultado bastante cómodo correr solo un único HDD grande con ext4 en una máquina Linux con una configuración estricta de NFSv3
    De todos modos es mi sistema principal, que siempre está encendido mientras estoy despierto, y con el consumo y la sobrecarga de una sola máquina puedo servir archivos a los demás dispositivos
    Además trato de mantener la configuración de red bastante restringida por defecto, así que no me preocupan demasiado las implicaciones de seguridad de correrlo en la máquina principal. Tal vez estoy cometiendo un pecado terrible, pero ¿de verdad se queda tan corto usar NFSv3 puro y Samba solo por compatibilidad?

    • Lo primero que me preguntaría es si tienes respaldo de ese único HDD grande. Esa es la mayor preocupación. Ese HDD va a fallar algún día, y lo importante es cuál es el plan para entonces
      La razón principal por la que la gente elige ZFS y un “NAS” son los checksums y la protección de integridad de datos, y también no querer tener la máquina principal despierta todo el tiempo
      Funciones como los snapshots también son útiles porque reducen la preocupación de perder datos por borrar o sobrescribir archivos por accidente
      No le veo problema a usar la máquina principal, encendida 24/7, como NAS. No hace falta comprarse algo a la fuerza, pero sí me preocuparía la confiabilidad y la protección contra bit rot. Pasa de verdad, y yo mismo lo he visto gracias a ZFS
    • En esa configuración, el mayor problema es la estructura de almacenamiento con una sola unidad. Si ese disco falla, no hay cómo aguantar, y si el hardware empieza a corromper datos silenciosamente, todos los datos quedan en riesgo. Asumiendo además que tus respaldos también están basados en los datos de ese único disco duro
      Si quieres mantener una configuración simple, vale la pena considerar guardar una lista de hashes de archivos y verificarlos periódicamente
      También conviene usar un programa de respaldo con soporte para snapshots; Restic es una opción decente
      Otra opción es comprar un disco duro más del mismo tamaño que el actual y usar SnapRAID para gestionar la integridad de los archivos, o armar un espejo de 2 discos con btrfs
    • Vas a toparte con límites cuando varias máquinas empiecen a leer y escribir al mismo tiempo. Aun así, construye lo que necesitas ahora; no hace falta sobreoptimizar
  • Cockpit me ha resultado muy útil para administrar NAS y VPS. Aunque gracias a los LLM la configuración en sí ya no sea un gran problema, sigue siendo cómodo tener un panel con toggles y logs ordenados, y poder ejecutar comandos de shell desde el celular sin usar SSH
    En un NAS, puedes ver fácilmente los resultados de tareas cron de respaldo y mantenimiento, administrar Samba y monitorear el uso de disco. En especial, lograr que Samba funcione bien en iPhone es un verdadero dolor de cabeza

    • Si ejecutas comandos de shell desde el celular sin usar SSH, me da curiosidad cómo manejas la autenticación de Cockpit. ¿Le pones autenticación HTTP básica por delante o algo así?
      Yo, en vez de bajar a métodos distintos de llave pública/privada para autenticar servidores, al final termino haciendo posible usar SSH desde el celular. En esto soy un poco paranoico
  • Cuando armé mi propio NAS hace tiempo, también usé este artículo como material de aprendizaje: https://xyny.art/blog/2026-building-nas/
    Construir un NAS desde cero es realmente divertido. Que no exista un “recurso completo” que cubra todo el tema sin dejar huecos es un pequeño obstáculo, pero al mismo tiempo también es parte de la diversión
    El objetivo de mi artículo también está más cerca de sumar otra “guía” sesgada de configuración de NAS a internet. Me cuesta llamarlo guía, pero si tuviera que hacer lo mismo otra vez, sin duda empezaría por leer mi propio texto

  • Conceptualmente corre lo mismo, pero usa FreeBSD en lugar de Debian. Más que ser mejor o peor, los trade-offs son distintos, y al final funciona igual de bien.

  • Al volver a armar el NAS, decidí ir con NFS sobre ZFS. Eso sí, mi objetivo es un poco distinto al del autor. Usé un CPU/placa madre de bajo consumo e hice dos sistemas separados con capacidad de failover, armados en una configuración de alta disponibilidad.
    De hecho, también escribí software personalizado para manejar el failover y la replicación de datos. En las pruebas, durante el failover las escrituras del cliente solo se detienen unos pocos segundos. Me pregunto si habría interés en que escriba sobre esto.