Requisitos de hardware para ZFS 2026: RAM, ECC y SLOG
· Verificado por última vez en julio 2026
ZFS tiene fama de exigir hierro de servidor, y esa fama es mitad verdad y mitad folclore endurecido en quince años de hilos de foro. La mitad verdadera es real: ZFS hace cosas concretas con la memoria y los discos que los sistemas de archivos comunes no hacen, así que unas pocas decisiones de hardware pesan mucho más que en un equipo con ext4. La mitad de folclore es justo lo que asusta a quien construye por primera vez y lo lleva a gastar de más, como creer que ZFS devora 1 GB de RAM por TB o que un scrub destruye el pool sin ECC. Esta guía separa las dos, recorre cada componente que a ZFS le importa de verdad y cierra con qué comprar para tres cargas de trabajo habituales. Si buscas el panorama más amplio, cómo se compara ZFS con Unraid o con un appliance de Synology, eso vive en la Guía de hardware para NAS; aquí bajamos un nivel más al interior del equipo ZFS.
Cómo usa ZFS la RAM: el ARC y el mito del "1 GB por TB"
Lo primero que hay que entender es que ZFS trata la memoria libre como caché de lectura, no como margen que debas mantener vacío. Esa caché es el Adaptive Replacement Cache, o ARC, y es más listo que una caché simple de "usado más recientemente" porque equilibra los datos usados hace poco contra los usados con frecuencia, y por eso un pool ZFS caliente se siente ágil incluso sobre discos giratorios. Cuando ves un equipo ZFS que "ocupa" casi toda su RAM, ese es el ARC haciendo su trabajo, y la memoria se devuelve en cuanto una aplicación la necesita. Por eso más RAM compra sobre todo lecturas más rápidas, no un margen de seguridad mayor, así que la pregunta nunca es "con qué tan poco me arreglo" sino "cuánta caché vale el precio".
Ese enfoque desmonta el mito más repetido del mundo ZFS, la idea de que debes reservar 1 GB de RAM por cada TB del pool. Nunca fue una regla dura, y la cifra que sí escala con la capacidad es la deduplicación, que la guía de hardware de TrueNAS ubica en unos 5 GB de RAM por TB de datos deduplicados. Para un pool normal sin dedup, esa misma guía trata 8 GB como el piso de trabajo y orienta la mayoría de equipos hacia 16 GB, por lo que un pool multimedia casero de 40 TB corre perfecto con 16 o 32 GB en vez de los 40 GB que exigiría la regla popular. Si alguna vez te preguntaste cómo se sitúa ZFS frente a ext4 y Btrfs en esta misma cuestión, nuestra comparativa ZFS vs ext4 vs Btrfs explica qué te compra realmente el apetito de RAM.
Donde más RAM rinde de verdad es más estrecho de lo que la gente supone: dedup como arriba, pools con mucha metadata y millones de archivos pequeños donde el ARC gasta su presupuesto cacheando estructura de directorios en vez de datos, y cargas multiusuario o de virtualización donde muchos clientes golpean el pool a la vez y una caché mayor sube la tasa de aciertos. Para una biblioteca Plex de un solo usuario o un archivo fotográfico, 16 GB sobran y 32 GB son un seguro cómodo; más allá de eso sueles rendir mejor gastando en discos que en más módulos. En resumen: arranca en 16 GB para un pool doméstico, sube a 32 GB con muchos usuarios o VMs, y persigue una cifra por TB solo si activas dedup a propósito.
RAM ECC: la versión honesta de un debate ruidoso
Ningún tema de ZFS genera más calor que la memoria ECC, así que aquí va la versión tranquila. La memoria ECC corrige en silencio los errores de un solo bit que la radiación de fondo y los chips marginales causan de vez en cuando, y lo hace antes de que el bit malo llegue a tus datos. Eso importa para ZFS porque sus famosos checksums protegen los datos de ida y vuelta al disco, pero no pueden proteger un valor mientras espera en la RAM para escribirse; si ahí se voltea un bit, ZFS calculará fielmente un checksum correcto para los datos ya corruptos y guardará ambos. ECC cierra exactamente esa brecha, y por eso es la única mejora de memoria que vale la pena tomar en serio en un equipo orientado a la integridad.
Lo que ECC no es, es un requisito duro. El propio OpenZFS describe ECC como muy recomendable, y su FAQ responde a la pregunta "¿tengo que usar ECC?" con un no claro, añadiendo que ZFS sobre memoria no ECC no es más peligroso que cualquier otro sistema de archivos sobre memoria no ECC. El célebre "scrub de la muerte", la idea de que un módulo defectuoso más un scrub se convierten en pérdida total del pool, es un mito: un scrub solo reescribe los bloques cuyo checksum en disco falla de verdad, y vuelve a verificar sus propias reparaciones. Así que ECC vale la pena en un equipo cuya razón de ser son datos que no puedes volver a descargar, y es prescindible en un servidor multimedia cuyo pool ya es una copia de algo. Dedicamos un artículo entero a qué plataformas la soportan y a su lugar en tu orden de prioridades en RAM ECC para NAS y ZFS. En resumen: compra ECC si los datos son irremplazables y la placa la admite, pero que su ausencia no te frene de usar ZFS, porque ZFS con checksums y un respaldo sigue ganándole a un sistema de archivos plano sin ninguno.
Dale a ZFS los discos directamente: un HBA, no RAID por hardware
ZFS gestiona la redundancia, los checksums y la reparación por sí mismo, lo que significa que necesita ver cada disco físico como un dispositivo crudo y no a través de una controladora que ya tomó decisiones por él. En este punto OpenZFS es de lo más enfático: sus notas de hardware dicen claramente que las controladoras RAID por hardware no deberían usarse con ZFS y que un HBA es mejor opción tanto por rendimiento como por fiabilidad. Una tarjeta RAID por hardware esconde los discos individuales detrás de su propia lógica y su propia caché, así que ZFS pierde los datos SMART directos, el control de tiempos y el reporte honesto de errores de los que depende para hacer bien su trabajo.
En la práctica eso significa un host bus adapter, una tarjeta cuya única función es sumar puertos de disco y pasar cada unidad tal cual, sin tocarla. El estándar del homelab es una tarjeta SAS LSI/Broadcom como la Broadcom 9300-8i, un adaptador PCIe x8 que suma ocho discos. El detalle a acertar al comprar usado es el firmware: muchas de estas tarjetas vienen en modo IR (RAID integrado) y hay que reflashearlas a modo IT (initiator target), lo que elimina la lógica RAID y convierte la tarjeta en una controladora de paso limpia. Una tarjeta ya flasheada a modo IT te ahorra el reflasheo, y nuestra comparativa RAID por hardware vs por software explica por qué el enfoque de paso directo es el que quiere todo build ZFS moderno.
Conviene evitar dos atajos baratos por la misma razón. El "RAID" de la placa, el modo Intel RST o AMD RAIDXpert del BIOS, es fake-RAID que esconde discos tras un driver, así que deja la controladora SATA en AHCI plano y que ZFS sea dueño de los discos. Las placas divisoras de puertos que prometen ocho discos desde dos puertos SATA se apoyan en multiplicadores de puerto SATA, y OpenZFS advierte que su soporte es inconsistente y que los discos SATA nunca deben ir en un expansor SAS sin un interposer SAS. En resumen: cuando superes los cuatro a seis puertos SATA de la placa, suma un HBA real en modo IT en vez de fake-RAID o un multiplicador de puerto, y deja que ZFS hable con el metal desnudo.
SLOG: un ZIL separado que solo agradecerán las escrituras síncronas
El SLOG es el accesorio de ZFS peor entendido, así que ayuda empezar por lo que no es. Todo pool ZFS ya tiene un ZIL, el ZFS Intent Log, donde el pool anota las escrituras que una aplicación pidió hacer durables de inmediato antes de confirmarlas. Un SLOG (log separado) simplemente mueve ese log de los discos principales a un dispositivo rápido y dedicado, y aquí está la trampa que descoloca a muchos: solo ayuda a las escrituras síncronas. La referencia de SLOG de TrueNAS es explícita en que el ZIL no maneja escrituras asíncronas por defecto, así que las cargas que se benefician son las que exigen durabilidad en cada operación, es decir datastores NFS, almacenamiento de VMs e iSCSI, y bases de datos.
Dos propiedades importan cuando de verdad necesitas uno. Primero, como el propósito entero de un SLOG es reproducir escrituras prometidas como durables si se corta la luz a mitad de la transacción, el dispositivo debe tener protección contra pérdida de energía, los condensadores a bordo que dejan a un SSD empresarial terminar sus escrituras en vuelo tras un apagón; un SSD de consumo barato sin ellos anula todo el propósito. Segundo, puede ser pequeño, porque solo guarda unos segundos de escrituras: TrueNAS sugiere un dispositivo de 16 GB, idealmente sobreaprovisionado desde un SSD de alta resistencia para repartir el desgaste. Lo que no necesitas es un SLOG para un NAS casero que sirve recursos compartidos SMB y multimedia, porque esas escrituras son asíncronas y nunca tocan el ZIL, así que el dinero rinde mucho más en RAM o discos. En resumen: añade un SLOG con protección contra pérdida de energía solo si corres NFS, VMs o bases de datos con escrituras síncronas, y si no, deja la ranura vacía.
L2ARC y el special vdev: caché que te cuesta RAM
El L2ARC es la contraparte de lectura del SLOG, una caché de segundo nivel en un SSD que atrapa los bloques expulsados del ARC en RAM, y llega con un costo contraintuitivo. Cada registro guardado en L2ARC necesita una pequeña cabecera rastreada en RAM, que la guía de hardware de TrueNAS ubica en cerca de 1 GB de RAM por 50 GB de L2ARC. Esa es la trampa: atornilla un SSD de caché de 500 GB a un equipo de 16 GB y habrás gastado en silencio 10 GB de tu preciado ARC en cabeceras de índice, de modo que la caché puede bajar tu tasa de aciertos en vez de subirla. La regla que sale de esto es simple: añade RAM antes que L2ARC, porque la RAM es ARC más rápido y no se cobra a sí misma por existir.
El L2ARC gana su ranura en un caso más estrecho, cuando tu working set supera de verdad la RAM que puedes instalar físicamente y las lecturas son lo bastante aleatorias como para que una caché SSD rápida le gane a ir al pool. TrueNAS señala que un dispositivo L2ARC solo vale la pena cuando sus IOPS de lectura aleatoria superan claramente al almacenamiento primario, así que un SSD SATA lento delante de un arreglo ancho de discos puede ser inútil. Para la mayoría de pools domésticos llegarás más lejos exprimiendo las ranuras de memoria y dejando el L2ARC para el día en que el equipo esté de verdad limitado por RAM.
Para el público más técnico: hay un tercer vdev de propósito especial que conviene conocer, el special vdev, una clase de asignación dedicada que guarda la metadata del pool (y, si lo eliges, los bloques pequeños por debajo de un tamaño que fijes) en SSDs rápidos en vez de en el pool giratorio. En un pool con mucha metadata y millones de archivos puede transformar lo ágiles que se sienten los listados de directorios y los scrubs, porque la metadata ya no compite con los datos por los discos lentos. El filo peligroso es la redundancia: un special vdev guarda datos que el pool no puede reconstruir, así que debe espejarse al menos al nivel de redundancia del pool, y perder un special vdev sin espejo pierde el pool entero. Es una ganancia de ajuste real para la carga adecuada, pero un movimiento avanzado que se planea al crear el pool, no una pieza para atornillar a la ligera.
Presupuestar las líneas PCIe: un ejemplo resuelto donde se agotan
Aquí está la restricción de la que nadie avisa a quien construye ZFS por primera vez, y la que arruina en silencio las listas de piezas ambiciosas: las líneas PCIe. Una línea es una de las conexiones de alta velocidad limitadas de la CPU hacia todo lo que no es memoria, y como explica el resumen de PCI Express, una CPU de escritorio corriente solo expone unas 20 a 24 líneas utilizables. El chipset de la placa suma más, pero las canaliza todas de vuelta a la CPU por un único enlace compartido, así que esas líneas del chipset son ancho de banda compartido, no capacidad libre. Un build ZFS es inusual porque quiere líneas desde varias direcciones a la vez, y ahí es donde una placa barata se queda seca.
Recorre una lista de deseos realista y cuenta. Un HBA de ocho puertos quiere una ranura x8 completa. Una tarjeta de red 10GbE quiere otras x4 a x8 según el modelo. Un SSD de arranque toma x4, y si además planeaste un SLOG NVMe y un L2ARC NVMe, son otras x4 cada uno. Súmalo y solo las tarjetas de expansión piden algo como x8 más x8 más tres x4, es decir cerca de 28 líneas antes de que la CPU haya gastado nada en gráficos. En una plataforma de consumo con unas 20 a 24 líneas de CPU eso no cabe: pon el HBA en la primera ranura x16 y la segunda suele caer de x16 a x8, y meter una unidad M.2 a menudo desactiva un par de puertos SATA en la misma placa. Acabas eligiendo entre el HBA y la tarjeta 10GbE, o empujas los NVMe al enlace compartido del chipset, donde compiten entre sí.
Esta es la verdadera razón por la que los builds ZFS serios derivan hacia plataformas de estación de trabajo y servidor en vez de placas gamer. Un Intel Xeon E o un chip serie W, o un AMD Ryzen sobre un chipset de estación de trabajo, expone sin más más líneas de CPU además de funciones de placa servidor como IPMI para gestión remota, de modo que un HBA, una NIC rápida y un par de NVMe pueden coexistir sin pelear por el mismo puñado de líneas. La lección es un hábito, no una pieza: si tu lista de deseos incluye HBA más 10GbE más cualquier NVMe, suma las líneas en papel antes de comprar y sube a una plataforma que las tenga, en vez de descubrir el faltante cuando llegan los paquetes. Con la plataforma resuelta, contrasta capacidades de disco y niveles RAID contra modelos reales en nuestra base de datos de discos NAS.
Las piezas en las que suele apoyarse un build ZFS
Qué HBA y qué módulos ECC elijas depende de tu plataforma, así que esos viven en las guías enlazadas arriba y no como tarjetas únicas aquí. Lo que sí acompaña a casi todo build ZFS es el reparto de apoyo de abajo, así que tómalos como anclas y presupuesta los discos y la memoria alrededor del tamaño de tu pool.
Recomendación
Para un pool casero de multimedia y respaldos (Plex, fotos, recursos compartidos por SMB), mantenlo simple: 16 GB de RAM, una placa de bajo consumo, discos CMR en RAIDZ2 desde cuatro unidades, un SAI, y ni SLOG ni L2ARC, porque las escrituras asíncronas nunca usan uno y tu dinero compra más capacidad. Para un equipo de virtualización o NFS (Proxmox, datastores ESXi, bases de datos) el panorama de escritura síncrona se invierte: presupuesta 32 GB de RAM o más, añade un SLOG con protección contra pérdida de energía y elige una plataforma con suficientes líneas PCIe para que la NIC 10GbE y el HBA no peleen. Para un pool grande o con mucha metadata (millones de archivos, o dedup deliberado), lidera con RAM primero (dedup quiere unos 5 GB por TB), considera un special vdev espejado para metadata si el cuello de botella es el rendimiento de directorios, y recurre a L2ARC solo cuando las ranuras de memoria estén llenas. En los tres, ECC es la mejora a priorizar si los datos son irremplazables y la placa la admite, y todo lo anterior sigue asumiendo la regla de oro de bitrot y scrubbing de ZFS: ZFS más un respaldo real, nunca ZFS en lugar de uno.
Artículos relacionados
Guía de hardware para NAS 2026: qué mirar según SO y sistema de archivos
Placa base para NAS: puertos SATA y líneas PCIe que importan
RAM ECC para NAS y ZFS: ¿obligatoria o mito?
ZFS vs ext4 vs Btrfs: ¿qué sistema de archivos para tu NAS?
Bitrot y scrubbing de ZFS: cuando los datos se pudren en silencio
RAID por hardware vs por software: ¿cuál gana en 2026?