Ir al contenido
  1. Posts/

Diseñar almacenamiento para casa: NAS, DAS, ZFS, Unraid y cuándo cada opción deja de tener sentido

·2470 palabras·12 mins

El almacenamiento es una de esas partes del homelab que parecen aburridas hasta que dejan de serlo. Al principio compras un disco grande, compartes una carpeta y te sientes razonablemente adulto. Luego llegan las fotos familiares, los documentos escaneados, las copias de seguridad, las máquinas virtuales, los contenedores con bases de datos, las descargas, la biblioteca multimedia y algún experimento que pesa más de lo que debería. Sin darte cuenta, esa carpeta compartida se convierte en el suelo sobre el que está apoyada media casa digital.

Ahí es cuando el almacenamiento deja de ser una compra y pasa a ser arquitectura.

Lo he ido aprendiendo a base de montar cosas que funcionaban, pero que luego eran incómodas de mantener. No siempre por mala tecnología. Muchas veces por mezclar usos que no deberían vivir juntos. Un disco rápido para máquinas virtuales no tiene las mismas necesidades que una biblioteca de fotos. Un NAS familiar no tiene la misma tolerancia al riesgo que un volumen para pruebas. Un pool ZFS precioso puede ser una maravilla o una cárcel, según cuánto entiendas sus reglas y cuánto tiempo tengas para cuidarlo.

Si hoy tuviera que diseñar almacenamiento doméstico desde cero, empezaría por una pregunta bastante menos sexy que “qué NAS compro”.

Qué datos me dolería perder
#

Para mí hay cuatro tipos de datos en casa.

Los primeros son irremplazables. Fotos, vídeos familiares, documentos, escaneos importantes, contraseñas, notas personales y cualquier cosa que no pueda volver a descargar. Estos datos mandan. No se optimizan solo por velocidad ni por comodidad. Se protegen primero.

Los segundos son reconstruibles pero pesados. Películas, series, ISOs, datasets, imágenes de contenedores, backups temporales, cachés y material que se podría volver a conseguir, aunque dé pereza. Aquí me importa más el coste por terabyte y la facilidad para crecer.

Los terceros son datos vivos de servicios. Bases de datos, volúmenes de Docker, configuración de aplicaciones, máquinas virtuales, discos de LXC y estados que cambian a diario. Aquí entran cosas como Paperless-ngx, Immich, Home Assistant, Gitea, Vaultwarden o cualquier servicio que use la familia o el trabajo.

Los cuartos son experimentos. Laboratorio, pruebas, descargas raras, clones, benchmarks y cosas que pueden desaparecer sin montar un drama. Si un experimento tiene el mismo nivel de protección que las fotos de tu hija, probablemente estás pagando complejidad de más.

Esta separación mental evita muchas tonterías. No todo necesita redundancia cara. No todo necesita NVMe. No todo merece backup externo. Y, sobre todo, no todo debería compartir el mismo dominio de fallo.

NAS no significa backup
#

Esta frase está muy repetida, pero conviene repetirla porque seguimos cayendo. Un NAS no es un backup. Un RAID no es un backup. Un snapshot no es un backup. Un segundo disco dentro de la misma caja tampoco es automáticamente un backup.

Un NAS es un sitio donde viven datos. Puede tener redundancia, snapshots, permisos, comparticiones, contenedores y una interfaz muy cómoda. Pero si borras una carpeta por error, si un ransomware cifra el volumen, si una actualización rompe una base de datos, si el equipo muere o si alguien se lleva la caja, el NAS por sí solo no te salva de todo.

Para datos irremplazables quiero al menos tres capas:

  • Redundancia local para aguantar el fallo de un disco.
  • Snapshots o versiones para recuperar errores humanos.
  • Copia fuera del equipo principal, idealmente fuera de casa o al menos desconectada de la misma avería.

En casa no hace falta convertir esto en una religión. Pero sí hace falta no engañarse. Si las fotos familiares solo existen en un NAS con dos discos en espejo, están mejor que en un portátil suelto, pero siguen teniendo un único sitio físico. Si además el backup usa la misma contraseña, el mismo usuario y el mismo montaje permanente, tampoco estás tan cubierto como parece.

Cuándo usaría un NAS clásico
#

Un NAS dedicado sigue teniendo muchísimo sentido si quieres que el almacenamiento sea aburrido. Y lo digo como elogio. Hay momentos en los que lo mejor que puede hacer una pieza del homelab es no pedir atención.

Usaría un NAS clásico para:

  • Fotos y vídeos familiares.
  • Documentos.
  • Biblioteca multimedia.
  • Backups de portátiles y móviles.
  • Comparticiones SMB o NFS sencillas.
  • Snapshots programados.
  • Replicación a otro destino.

La ventaja principal es que separas almacenamiento de cómputo. Tus VMs pueden vivir en Proxmox, tus contenedores en Docker o Kubernetes, tus servicios en mini PCs, pero los datos fríos o familiares viven en una caja pensada para eso. Si un nodo de laboratorio se rompe, no se lleva por delante el sitio donde están los documentos.

El problema del NAS clásico aparece cuando le pides demasiado. Empiezas con carpetas compartidas. Luego instalas contenedores. Luego bases de datos. Luego transcodificación. Luego máquinas virtuales. Luego automatizaciones. Al final tienes un servidor generalista metido en una caja que compraste para guardar datos.

No siempre está mal. Pero hay que admitir qué estás haciendo. Si tu NAS se convierte en el corazón de todos los servicios, ya no es solo almacenamiento. Es producción. Y producción necesita ventanas de mantenimiento, backups, alertas, pruebas de restauración y una tolerancia menor a los experimentos.

Cuándo usaría Unraid
#

Unraid me parece muy cómodo cuando tienes discos de distintos tamaños, quieres crecer poco a poco y no necesitas el comportamiento más purista de ZFS. Su gran baza en casa es psicológica y económica: permite aprovechar hardware heterogéneo sin sentir que cada ampliación exige rehacer media arquitectura.

Lo usaría para:

  • Almacenamiento multimedia grande.
  • Servidor doméstico todo en uno.
  • Docker sencillo.
  • Discos de diferentes capacidades.
  • Crecimiento gradual.
  • Caché SSD para escrituras y apps.

La forma en que Unraid reparte datos por discos individuales tiene una ventaja doméstica muy clara. Si algo va mal, no todo está encerrado en una estructura más rígida. También consume menos energía en algunos escenarios, porque no todos los discos tienen que estar trabajando siempre.

Pero Unraid no es magia. La paridad protege contra fallo de disco, no contra borrados, corrupción lógica o meteduras de pata. Y cuando le metes muchos contenedores con datos importantes, vuelves al mismo problema: necesitas backups buenos de appdata, bases de datos consistentes y una idea clara de qué pasa si el USB de arranque o el disco de caché fallan.

Mi opinión práctica: Unraid brilla como servidor doméstico de almacenamiento flexible. También puede ejecutar servicios. Lo que no haría es meter ahí todo lo crítico sin una estrategia externa. Si Unraid es tu caja principal, perfecto. Pero que no sea también tu único backup, tu única documentación y tu único plan.

Cuándo usaría ZFS
#

ZFS es una maravilla cuando aceptas sus reglas. Integridad de datos, snapshots, compresión, replicación, scrubs, checksums, datasets separados y una forma muy seria de tratar el almacenamiento. Para homelab tiene sentido si te importa la consistencia y estás dispuesto a entender qué estás montando.

Lo usaría para:

  • Máquinas virtuales.
  • Datos importantes con snapshots frecuentes.
  • Replicación entre servidores.
  • Pools con discos iguales o bien planificados.
  • Servicios donde la integridad pesa más que la flexibilidad.

El lado incómodo es que ZFS castiga bastante el diseño improvisado. Ampliar un pool no siempre es tan simple como meter otro disco y seguir. Elegir mal el vdev al principio te puede perseguir años. Mezclar discos raros, controladoras dudosas y poca RAM no siempre explota, pero tampoco ayuda. Y si no haces scrubs, no miras alertas y no sabes interpretar un pool degradado, estás usando una herramienta seria con ojos de turista.

En casa usaría ZFS para almacenamiento que quiero cuidar de verdad, pero no lo pondría en todas partes por defecto. Para un volumen enorme de multimedia descargable, quizá prefiero flexibilidad. Para una base de datos, snapshots y replicación me gustan mucho. Para fotos familiares, ZFS me da bastante paz, siempre que el backup externo esté resuelto.

Lo que no compraría es el discurso de “ZFS lo arregla todo”. ZFS te protege de algunas clases de corrupción y te da herramientas muy buenas. No te protege de borrar la carpeta equivocada y replicar el borrado a todas partes como un campeón.

DAS y discos USB: útiles, pero con límites
#

Un DAS o una caja de discos conectada por USB, Thunderbolt o similar puede ser una solución muy razonable para backups y almacenamiento local. No todo tiene que ser un NAS con interfaz web y apps.

Me gusta para:

  • Copias frías.
  • Backups periódicos desconectables.
  • Ampliar un servidor pequeño.
  • Restauraciones rápidas sin depender de red.
  • Archivos grandes que no cambian mucho.

El punto fuerte es la simplicidad. Un disco externo bien etiquetado, cifrado y probado puede ser mejor backup que una arquitectura preciosa que nunca has restaurado. Además, para muchos hogares, una copia mensual en un disco guardado fuera de la máquina principal ya mejora muchísimo la situación.

El límite está en la fiabilidad operativa. USB puede ser puñetero para cargas constantes. Las cajas baratas calientan discos. Los cables se mueven. Los discos externos se quedan montados eternamente y entonces dejan de ser copia fría. Si un DAS está conectado siempre al servidor principal y accesible con los mismos permisos, cuenta como almacenamiento adicional, no como protección seria frente a meteduras de pata.

Yo lo usaría como parte del plan, no como única base.

Separaría rápido y grande
#

Una de las decisiones que más orden trae es separar almacenamiento rápido de almacenamiento grande.

El almacenamiento rápido sería NVMe o SSD para:

  • VMs activas.
  • Contenedores.
  • Bases de datos.
  • Cachés.
  • Compilaciones.
  • Servicios con mucha lectura y escritura pequeña.

El almacenamiento grande serían discos duros para:

  • Multimedia.
  • Fotos originales.
  • Backups.
  • Archivos.
  • Exportaciones.
  • Datos fríos.

Mezclarlo todo funciona al principio, pero se nota cuando el sistema crece. Si las bases de datos de los servicios compiten con una copia enorme de fotos o con una tarea de backup, aparecen latencias raras. Si una VM vive sobre discos lentos saturados, todo parece roto aunque la CPU esté libre.

En un diseño doméstico sencillo, me gusta esta idea:

  • NVMe local en cada nodo para sistema y servicios.
  • NAS o servidor de almacenamiento para datos persistentes grandes.
  • Backups separados del almacenamiento principal.
  • Replicación solo de lo que merece volver rápido.

No movería cada byte a través de la red solo por pureza arquitectónica. Hay servicios que funcionan mejor con disco local y backup frecuente. Hay datos que prefieren vivir en el NAS. La gracia está en no tratar una carpeta compartida como respuesta universal.

Bases de datos: cuidado con el NAS
#

Poner bases de datos sobre NFS o SMB porque “así queda centralizado” es una tentación peligrosa. A veces funciona. A veces funciona hasta que no. Y cuando falla, suele fallar de formas desagradables.

Para servicios domésticos con PostgreSQL, MariaDB o SQLite, prefiero disco local rápido en la máquina que ejecuta el servicio, con backup consistente hacia el NAS. Esto reduce latencia, evita dependencias de red en caliente y simplifica el rendimiento. El NAS recibe dumps, snapshots, copias o exports, pero no tiene por qué ser el disco vivo de todo.

Hay excepciones, claro. Un entorno virtualizado con almacenamiento compartido bien montado puede tener sentido. Pero en casa, si no tengo una razón clara, no pongo la base de datos viva en una carpeta de red.

SQLite merece una mención especial. Muchos servicios pequeños usan SQLite y van perfectos. Pero SQLite sobre almacenamiento de red puede ser una mala idea si hay bloqueos, latencias o implementaciones raras. Si un servicio usa SQLite, casi siempre lo dejo local y lo respaldo con cuidado.

Mi diseño base para una casa real
#

Si tuviera que montar una arquitectura bastante sensata para una casa con homelab, haría algo así:

  • Un servidor o NAS principal con discos grandes para datos familiares y multimedia.
  • Snapshots locales para carpetas importantes.
  • Un disco o destino externo para copia periódica de datos irremplazables.
  • NVMe en el servidor de cómputo para VMs, contenedores y bases de datos.
  • Backups de configuración y bases de datos hacia el NAS.
  • Copia fuera de casa para fotos, documentos y secretos importantes.
  • Una hoja simple con qué vive dónde y cómo se recupera.

No intentaría que todo fuese altamente disponible. No intentaría que todo estuviese replicado en tiempo real. No intentaría que cada servicio tuviera almacenamiento distribuido. En una casa, la disponibilidad perfecta suele costar más en mantenimiento que lo que aporta.

Sí intentaría que los datos importantes pudieran sobrevivir a tres cosas: fallo de disco, error humano y muerte del equipo principal. Si el diseño no cubre esas tres, todavía no está maduro.

Cuándo deja de tener sentido
#

El almacenamiento deja de tener sentido cuando la arquitectura solo la entiendes tú después de mirar cinco notas y tres dashboards. También cuando cada ampliación exige comprar discos idénticos, migrar servicios, cambiar pools, tocar permisos y cruzar los dedos. O cuando el miedo a romper algo te impide actualizar.

He visto homelabs donde el almacenamiento era técnicamente impresionante, pero operativamente frágil. Demasiadas capas. Demasiadas dependencias. Demasiadas cosas montadas entre sí. Un servicio necesitaba DNS, red, NAS, NFS, permisos, autenticación, proxy, certificados y un nodo concreto solo para arrancar. Eso no es arquitectura doméstica. Es una gymkana para tu yo cansado.

Mi regla ahora es bastante simple: si no puedo explicar dónde está un dato importante y cómo lo recupero en cinco minutos, tengo deuda operativa.

Lo que haría distinto
#

Si empezara de cero, compraría menos pensando en capacidad máxima y más pensando en recuperación. Es muy fácil obsesionarse con terabytes. Pero los terabytes no te dicen cuánto tardas en restaurar, qué pasa si se rompe el servidor, dónde está la clave de cifrado o si puedes acceder a una copia sin el sistema principal.

También separaría antes los datos familiares del laboratorio. El laboratorio puede romperse. Debe poder romperse. Si cada prueba con Kubernetes, Proxmox, Docker o red tiene la posibilidad de tocar datos familiares, la arquitectura está mal planteada.

Y documentaría desde el primer día. No una wiki infinita. Una tabla corta:

  • Servicio.
  • Datos.
  • Ubicación.
  • Backup.
  • Frecuencia.
  • Restauración probada.
  • Prioridad.

Con eso ya ganas mucho. Más que con otro disco comprado por ansiedad.

Mi conclusión
#

Para casa, el mejor almacenamiento no es el más elegante. Es el que sabes mantener, ampliar y recuperar sin convertir una tarde normal en una operación quirúrgica.

NAS tiene sentido para datos familiares y comparticiones estables. Unraid tiene sentido cuando quieres flexibilidad y crecimiento gradual. ZFS tiene sentido cuando valoras integridad, snapshots y replicación, siempre que aceptes su disciplina. DAS y discos externos siguen siendo muy útiles para copias frías y restauraciones simples.

La decisión importante no es elegir una marca o una tecnología. Es separar qué datos son irremplazables, qué servicios necesitan rendimiento, qué cosas pueden romperse y qué plan tienes cuando el equipo principal muere.

El almacenamiento doméstico bueno no se presume. Se nota el día que algo falla y, en vez de improvisar, sabes exactamente qué disco, qué backup y qué orden seguir.