Problema

Los usuarios que quieren abandonar los servicios de almacenamiento en la nube buscan una alternativa local que sea accesible desde varios dispositivos (Android, Windows, Linux) y que pueda exponerse de forma segura fuera del hogar (por ejemplo, mediante WireGuard). La decisión típica recae entre comprar un NAS comercial listo para usar o armar una solución DIY con una Single‑Board Computer (SBC) y discos externos. Ambas opciones prometen “almacenamiento en red”, pero difieren drásticamente en arquitectura, ecosistema de software y nivel de intervención requerido. El reto es elegir una arquitectura que ofrezca:

  • Redundancia de datos sin depender de software propietario.
  • Acceso fiable tanto en LAN como a través de VPN.
  • Mantenimiento predecible para un ingeniero familiarizado con Linux y la línea de comandos.

Causa

Los problemas habituales surgen por una combinación de factores:

  1. Hardware subdimensionado – Un NAS barato puede usar un CPU de bajo consumo que no soporta transcodificación o cifrado de extremo a extremo, provocando cuellos de botella bajo carga.
  2. Software cerrado – Sistemas operativos propietarios (por ejemplo, DiskStation Manager) ocultan la gestión de paquetes y limitan la instalación de herramientas personalizadas, lo que complica la automatización.
  3. RAID mal configurado – Elegir un nivel de RAID sin considerar la tolerancia a fallos o la velocidad de reconstrucción lleva a pérdidas de datos o a tiempos de inactividad prolongados.
  4. Red no optimizada – Conexiones de 1 GbE pueden ser insuficientes si se usan discos NVMe o si varios clientes acceden simultáneamente, y la falta de VLAN o QoS empeora la experiencia.
  5. Acceso remoto inseguro – Exponer puertos SMB/FTP directamente a Internet abre vectores de ataque; la ausencia de una capa VPN obliga a configuraciones ad‑hoc propensas a errores.

Solución

Una arquitectura modular basada en una SBC potente (por ejemplo, Raspberry Pi 4, Odroid N2+ o RockPro64) combinada con un chasis de discos y software de código abierto brinda control total y escalabilidad. El flujo recomendado:

  1. Seleccionar la SBC
    CPU de al menos 4 núcleos a 1.5 GHz, 4 GB RAM, y puertos Gigabit Ethernet. La Raspberry Pi 4 con 8 GB RAM y USB 3.0 es suficiente para uso doméstico; para cargas mayores, el RockPro64 con PCIe a SATA es ideal.

  2. Montar los discos
    Utilizar un chasis con backplane SATA y alimentación dedicada. Configurar un ZFS pool o mdadm RAID‑1/5 según la cantidad de discos y el nivel de tolerancia deseado. ZFS ofrece autocuración y snapshots sin necesidad de hardware RAID.

  3. Instalar un SO minimalista
    Debian Bookworm o Ubuntu Server LTS son opciones estables. Evitar entornos de escritorio para reducir consumo y superficie de ataque.

  4. Implementar los servicios de archivo

    • Samba para clientes Windows y Android (SMB3).
    • NFS para Linux/Unix.
    • WebDAV opcional para acceso desde navegadores.
      Configurar los shares con ACLs basadas en usuarios locales y habilitar cifrado en tránsito (SMB3 con encryption, NFSv4 con Kerberos).

  5. Añadir capa VPN
    Instalar WireGuard en la SBC, generar pares de claves y crear un perfil para cada dispositivo. Con una regla AllowedIPs = 0.0.0.0/0, ::/0 se permite el acceso a la red interna sin abrir puertos adicionales.

  6. Automatizar backups
    Utilizar rsnapshot o restic para replicar datos a un disco externo o a un bucket S3 compatible. Programar snapshots ZFS cada hora y replicaciones diarias.

  7. Monitorizar
    Desplegar Prometheus + node_exporter y Grafana para visualizar uso de CPU, I/O y latencia de red. Configurar alertas por fallos de disco o degradación del pool.

Alternativa comercial

Si la prioridad es tiempo de despliegue y soporte, un NAS de gama media (Synology DS925+, QNAP TS‑264) ofrece:

  • Sistema operativo basado en Linux con paquetes Docker y Virtual Machine Manager.
  • Soporte oficial para SMB, NFS, iSCSI y apps de backup.
  • Interfaz web intuitiva para crear RAID‑5/6 y snapshots.

Sin embargo, la personalización está limitada a los paquetes oficiales; cualquier herramienta fuera del ecosistema requiere contenedores o máquinas virtuales, lo que añade complejidad.

Cuándo aplicar esta solución

DIY SBC es apropiado cuando:

  • Se desea control total del stack (kernel, paquetes, scripts).
  • Se planea integrar herramientas de desarrollo propias (por ejemplo, servicios Rust).
  • El presupuesto permite comprar discos y un chasis por separado, pero no se justifica un NAS premium.
  • Se necesita flexibilidad para añadir servicios (Pi‑hole, Home‑Assistant, etc.) en la misma máquina.

NAS comercial conviene cuando:

  • Se prefiere una instalación “plug‑and‑play” con garantía y actualizaciones de firmware.
  • La carga de trabajo incluye transcodificación de medios 4K o máquinas virtuales que requieren CPU potente y GPU integrada.
  • El equipo no quiere gestionar la capa de hardware (alimentación, disipación, RAID hardware).

En entornos donde la seguridad es crítica y la exposición a Internet es frecuente, siempre se debe colocar la VPN delante del NAS, sin importar la solución elegida.

Código

# Instalar paquetes base en Debian
apt update && apt install -y \
    samba nfs-kernel-server zfsutils-linux wireguard \
    prometheus-node-exporter grafana

# Crear pool ZFS con 2 discos /dev/sdb /dev/sdc (RAID‑1)
zpool create -f -o ashift=12 tank mirror /dev/sdb /dev/sdc

# Exportar dataset para SMB/NFS
zfs create -o mountpoint=/srv/storage tank/data
chmod 770 /srv/storage
chown root:users /srv/storage

# Configuración mínima de Samba (añadir al final de /etc/samba/smb.conf)
cat >> /etc/samba/smb.conf <<'EOF'
[share]
   path = /srv/storage
   browseable = yes
   read only = no
   force user = root
   vfs objects = streams_xattr
   smb encrypt = required
EOF
systemctl restart smbd

# WireGuard: generar claves y crear /etc/wireguard/wg0.conf
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
cat > /etc/wireguard/wg0.conf <<'EOF'
[Interface]
PrivateKey = <PRIVATE_KEY>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.0.0.2/32
EOF
systemctl enable --now wg-quick@wg0

Verificación

  1. Comprobar pool ZFS
    zpool status -v debe mostrar ONLINE y los discos bajo mirror.

  2. Montar desde cliente Linux
    sudo mount -t nfs 192.168.1.10:/srv/storage /mnt/test y crear un archivo; verificar que aparece en el directorio del servidor.

  3. Acceso SMB desde Windows
    En el explorador, \\192.168.1.10\share y crear un archivo. Confirmar que el cifrado está activo mediante Get-SmbConnection en PowerShell.

  4. Conexión WireGuard
    En el cliente, wg show debe listar peer: 10.0.0.1 con latest handshake reciente. Probar ping a 10.0.0.1.

  5. Alertas Grafana
    Acceder a http://<ip>:3000, crear dashboard con métricas node_disk_io_time_seconds_total. Simular fallo de disco desconectando un disco y observar la alerta.

Notas adicionales

  • Alimentación – Los discos externos pueden superar la capacidad del puerto USB de la SBC; usar una fuente de 12 V/5 A dedicada evita reinicios inesperados.
  • Enfriamiento – Un chasis con ventilación activa es esencial cuando se usan discos HDD 7200 RPM; la Raspberry Pi necesita disipador y ventilador bajo carga sostenida.
  • Actualizaciones del kernel – ZFS en Debian requiere el módulo zfs-dkms; mantén el kernel actualizado para evitar incompatibilidades.
  • Backup fuera del sitio – Incluso con RAID, una copia fuera del sitio (NAS secundario o servicio S3) protege contra desastres físicos.
  • Licencias – Algunas funciones de NAS comerciales (por ejemplo, sincronización con OneDrive) requieren licencias adicionales; evalúa si realmente las necesitas antes de comprar.