ReFS vs NTFS: cuándo usar cada uno y por qué importa

Cuando trabajas con Windows Server, virtualización, SQL Server o grandes servidores de ficheros, llega un momento en el que la pregunta es inevitable: ¿me conviene más NTFS o ReFS? No es solo una cuestión técnica; elegir bien el sistema de archivos condiciona el rendimiento, la capacidad máxima, la resiliencia frente a corrupción de datos e incluso qué funcionalidades de Windows puedes aprovechar.

En los últimos años Microsoft ha impulsado con fuerza ReFS (Resilient File System) como el gran aliado para cargas de trabajo modernas, sin eliminar a NTFS, que sigue siendo el sistema de archivos imprescindible para arrancar Windows y para muchos escenarios clásicos. Entender de verdad qué ofrece cada uno, sus límites y sus carencias, es clave para no equivocarse al diseñar un entorno de producción.

Qué es NTFS y en qué destaca

NTFS (New Technology File System) es el sistema de archivos de referencia en Windows desde los tiempos de Windows NT. Es el formato por defecto en versiones de escritorio y servidor, y sigue siendo hoy el único sistema de archivos soportado para instalar y arrancar Windows, así como para el archivo de paginación y soportes extraíbles gestionados por el sistema.

Uno de sus grandes puntos fuertes es la seguridad a nivel de archivo. NTFS soporta listas de control de acceso (ACL), permisos granulares, auditoría y otras características de seguridad que permiten controlar con precisión quién accede a qué. Además, incorpora cifrado EFS (Encrypting File System) para proteger datos a nivel de fichero, independiente de BitLocker.

NTFS también destaca por sus funciones avanzadas de gestión del almacenamiento: cuotas de disco por usuario, compresión transparente a nivel de archivo o carpeta, archivos dispersos (sparse files), atributos extendidos, nombres cortos, flujos alternativos de datos, enlaces duros y simbólicos, puntos de montaje y puntos de unión, entre otros.

En lo relativo a la integridad, NTFS utiliza un sistema de journaling (registro en diario) que guarda un log de cambios en los metadatos del sistema de archivos. En caso de apagón repentino o fallo del sistema, este diario permite recuperar rápidamente un estado consistente del volumen. A esto se suma la llamada autorreparación del sistema de archivos, que puede corregir ciertos problemas sin necesidad de desmontar el volumen.

Desde Windows Server 2008 NTFS dispone además de transacciones (Transactional NTFS), que permiten agrupar operaciones de escritura en una transacción atómica: o se escriben todas, o no se escribe ninguna. Aunque no es una funcionalidad muy utilizada hoy en día, fue diseñada para aplicaciones que necesitan una consistencia muy estricta en el sistema de archivos.

Qué es ReFS y cuál es su objetivo

ReFS (Resilient File System) aparece con Windows Server 2012 como respuesta de Microsoft a las nuevas necesidades: almacenar cantidades masivas de datos, minimizar el riesgo de corrupción silenciosa y trabajar de la mano con Storage Spaces y entornos muy virtualizados. Su meta no es sustituir de golpe a NTFS, sino ofrecer un sistema optimizado para resiliencia, integridad y escalabilidad.

A nivel de diseño, ReFS se basa en la idea de proteger los datos extremo a extremo. Todos los metadatos del sistema de archivos llevan sumas de comprobación (checksums) y, opcionalmente, también los datos de usuario mediante secuencias de integridad. Gracias a estas sumas de comprobación, el sistema es capaz de detectar corrupción con precisión y actuar en consecuencia.

ReFS utiliza un modelo de copy-on-write (asignación de escritura transaccional): en lugar de sobrescribir bloques ya existentes, cuando se modifica un archivo o metadato se escriben los cambios en bloques nuevos, y solo cuando todo está correcto se actualizan las referencias. Esto reduce de manera drástica la posibilidad de que un corte de energía deje estructuras internas en un estado inconsistente.

La integración con Storage Spaces es otra de las piedras angulares de ReFS. Al trabajar sobre pools de discos en espejo o paridad gestionados por Storage Spaces, ReFS puede usar las copias redundantes para reparar automáticamente bloques dañados: si detecta corrupción en un bloque, lee la copia sana y reescribe el contenido correcto, todo ello sin dejar fuera de línea el volumen.

Además, ReFS incorpora un proceso de depuración o scrubbing periódico, conocido como «integrity scrubber», que escanea los datos en segundo plano, comprueba sus sumas de comprobación y corrige de forma proactiva errores latentes antes de que lleguen a afectar a las aplicaciones.

ReFS vs NTFS: fiabilidad e integridad de datos

Si nos centramos en la fiabilidad del almacenamiento, NTFS y ReFS siguen enfoques diferentes. NTFS se apoya en el diario de transacciones para garantizar la coherencia de los metadatos después de un fallo; cuando el sistema se reinicia, revisa el log y vuelve a un estado consistente. Cuando encuentra sectores defectuosos, los marca como malos, los aísla y reasigna otros clústeres para los datos.

La autorreparación de NTFS le permite detectar ciertos tipos de corrupción y corregirlos en caliente, sin desmontar el volumen. Sumado a eso, al registrar todos los cambios de metadatos, el sistema puede revertir más rápidamente tras un crash o una migración de datos interrumpida, ofreciendo un alto nivel de confianza en el sistema de archivos en entornos de producción tradicionales.

ReFS, por su parte, lleva la integridad un paso más allá gracias a las suma de comprobación para metadatos y datos, el modelo copy-on-write y la integración con Storage Spaces. Cuando se habilitan secuencias de integridad y se usa un espacio en espejo o paridad, ReFS puede detectar corrupción silenciosa (bit rot) y arreglarla de forma automática leyendo la copia sana.

En escenarios donde no existe otra copia del bloque (por ejemplo, un único disco sin redundancia), ReFS no puede «adivinar» el contenido correcto; en esos casos retira el dato corrupto del espacio de nombres para evitar que las aplicaciones trabajen con información dañada. Lo importante es que intenta mantener el volumen operativo y accesible, solo forzando modos sin conexión en casos extremos.

Otra diferencia clave es la corrección de errores proactiva. Mientras que en NTFS la detección de corrupción suele ser reactiva (cuando un proceso intenta leer un archivo o cuando se ejecutan herramientas tipo chkdsk), ReFS incluye un verificador en segundo plano que recorre periódicamente el volumen, compara las sumas de comprobación y lanza reparaciones sin que el administrador tenga que intervenir.

ReFS vs NTFS: rendimiento en la práctica

En términos de rendimiento puro, NTFS sigue ofreciendo un comportamiento muy sólido y versátil. Tiene soporte para compresión de archivos que permite aumentar de forma efectiva la capacidad aprovechable del disco, aunque a costa de cierta carga de CPU. Las cuotas de disco facilitan controlar el espacio asignado a cada usuario, y la posibilidad de redimensionar volúmenes (crecer o, en algunos casos, reducir) usando espacio no asignado añade flexibilidad a la gestión.

Además, las transacciones NTFS permiten a ciertas aplicaciones críticas asegurar que un conjunto de operaciones complejas sobre archivos se realiza de forma atómica. Y aunque la fragmentación de archivos puede terminar degradando el rendimiento, se dispone de herramientas de desfragmentación y buenas prácticas (como tamaños de clúster adecuados) para mitigar ese efecto.

ReFS, en cambio, está muy orientado a mejorar el rendimiento en entornos de virtualización y almacenamiento a gran escala. Uno de sus pilares es la optimización de niveles en tiempo real cuando se utiliza con Storage Spaces: un mismo volumen ReFS se puede dividir en un nivel de rendimiento (por ejemplo, SSD) y un nivel de capacidad (discos más lentos y grandes). Las escrituras se realizan primero en el nivel rápido, y bloques grandes o fríos se van moviendo al nivel de capacidad sin intervención manual.

Para cargas de trabajo con Hyper-V, ReFS introduce características específicas como la clonación de bloques. Cuando clonas una máquina virtual o fusionas puntos de control (checkpoints), ReFS no copia todos los datos físicamente, sino que actualiza los metadatos apuntando a los mismos bloques, generando clones casi instantáneos y reduciendo la carga de E/S.

Otra funcionalidad clave es la VDL dispersa (Sparse Valid Data Length), que permite «poner a cero» archivos de forma extremadamente rápida. En la práctica esto se traduce en creación de archivos VHD/VHDX casi instantánea, algo muy apreciado en plataformas de virtualización con muchas máquinas.

Hay que tener en cuenta, eso sí, que todas estas capacidades avanzadas tienen un coste: ReFS suele consumir más CPU y memoria que NTFS, especialmente cuando se activan todas las funciones de integridad y se gestiona un volumen de gran tamaño. En sistemas muy cargados o con recursos limitados, este overhead puede hacerse notar.

Escalabilidad: tamaños máximos y nombres de archivo

Uno de los campos donde ReFS brilla con luz propia es la escalabilidad. NTFS soporta de manera teórica volúmenes de hasta 16 exabytes, pero en la práctica las implementaciones habituales trabajan con límites mucho más modestos y con tamaños de archivo máximo típicos de 256 TB en escenarios documentados

En implementaciones concretas muy utilizadas, se suelen manejar cifras de hasta 256 TB de tamaño de archivo y 256 TB de volumen como referencia, suficientes para la gran mayoría de entornos de servidor clásicos, pero que pueden quedarse cortas cuando hablamos de repositorios masivos, grandes nubes privadas o almacenamiento de datos no estructurados a escala enorme.

ReFS fue diseñado para manejar volúmenes y archivos muy superiores. En plataformas donde se ha documentado su uso, se habla de tamaños de archivo de hasta 35 PB y volúmenes también de 35 PB, es decir, del orden de 137 veces la capacidad práctica que se atribuye a NTFS en muchas configuraciones. A nivel teórico, el diseño de ReFS permite llegar a escalas de cientos de miles de exabytes.

En lo que respecta a los nombres de archivo y rutas, tanto NTFS como ReFS permiten nombres de archivo de hasta 255 caracteres y rutas máximas de 32.768 caracteres. La diferencia está en que ReFS viene más preparado de fábrica para trabajar con rutas largas, mientras que en NTFS conviene desactivar manualmente ciertas limitaciones de compatibilidad heredadas si se quieren aprovechar esos máximos.

Los tamaños de clúster (unidad de asignación) también influyen en la escalabilidad y el rendimiento. En NTFS se puede elegir entre 512 bytes y 64 KB, aunque en la práctica se recomienda 4 KB para uso general, ya que equilibra bien el desperdicio de espacio con archivos pequeños y el rendimiento general. En entornos que necesitan más de 16 TB, a menudo se opta por 64 KB para evitar límites derivados del tamaño de clúster.

ReFS ofrece un rango algo más acotado, normalmente entre 4 KB y 64 KB. Igual que en NTFS, se sugiere usar 4 KB para la mayoría de escenarios y reservar 64 KB para entornos con cargas muy secuenciales o volúmenes gigantescos donde esa elección mejore la eficiencia.

Dónde encaja mejor cada sistema de archivos

En la práctica, tanto NTFS como ReFS son válidos para servidores de ficheros y volúmenes compartidos, pero el enfoque es distinto. ReFS suele ser la apuesta preferida cuando hablamos de grandes volúmenes de datos, pools de almacenamiento basados en Storage Spaces y entornos con muchas máquinas virtuales o grandes repositorios de copias de seguridad.

Sin embargo, ReFS arrastra todavía limitaciones funcionales importantes que impiden considerarlo un reemplazo total de NTFS. Por ejemplo, a día de hoy no se puede arrancar Windows desde un volumen ReFS, no hay soporte para compresión de sistema de archivos, no existe cifrado EFS, no gestiona cuotas de disco ni atributos extendidos de la misma forma que NTFS, y el soporte para medios extraíbles es muy limitado o inexistente.

Esto hace que NTFS siga siendo casi obligatorio para particiones de sistema, unidades donde residen aplicaciones de usuario, soportes externos y muchos escenarios mixtos. Además, muchas herramientas de terceros, utilidades de copia de seguridad y software de gestión de almacenamiento siguen estando mucho mejor adaptadas a NTFS, lo que también influye en la decisión.

ReFS, por otro lado, se siente «en su salsa» como sistema de archivos para repositorios de backup, volúmenes de VHDX de Hyper-V, grandes archivos de datos poco cambiantes y almacenamiento masivo. La combinación de integridad, clonación de bloques y niveles de almacenamiento en tiempo real lo convierten en un candidato ideal para ese tipo de cargas.

Comparativa de funcionalidades: qué tiene uno que no tiene el otro

Si se comparan lado a lado las características disponibles, se ve claramente que ReFS ha heredado muchas capacidades de NTFS, pero también que NTFS sigue ofreciendo un conjunto de herramientas más completo en algunos frentes clave.

Ambos sistemas de archivos soportan BitLocker para cifrado de unidades completas, deduplicación (en el caso de ReFS, a partir de ciertas versiones como Windows Server 1709 en adelante), compatibilidad con volúmenes compartidos en clúster (CSV), enlaces simbólicos, clústeres de conmutación por error, ACL, diario USN, notificaciones de cambio, puntos de unión, puntos de montaje, puntos de repetición de análisis, instantáneas de volumen, identificación de archivos, oplocks y archivos dispersos.

Tanto NTFS como ReFS pueden trabajar con aprovisionamiento fino y operaciones Trim/Unmap cuando se usan sobre Storage Spaces, optimizando así el uso de espacio físico. ReFS añade además características como clonación de bloques, VDL disperso, paridad acelerada por espejo y, en versiones recientes como Windows Server 2022, instancias a nivel de archivo que mejoran aún más el comportamiento en algunos escenarios.

Por el lado de NTFS están una serie de funcionalidades que ReFS no tiene: compresión de sistema de archivos, cifrado EFS, transacciones NTFS, enlaces duros completos, identificadores de objeto, nombres cortos, atributos ampliados, cuotas de disco, soporte de arranque, compatibilidad con archivo de paginación y soportes extraíbles, así como ODX (Offloaded Data Transfer) en algunos escenarios.

Esto explica por qué, pese a sus ventajas técnicas, ReFS aún no puede sustituir a NTFS en el día a día. Falta cobertura en zonas muy usadas por administradores y aplicaciones, y Microsoft ha dejado claro que su idea es que convivan, no que uno elimine al otro a corto plazo.

Versiones de ReFS y compatibilidad con Windows

Otro aspecto que no se puede pasar por alto es la compatibilidad entre versiones de ReFS y distintas ediciones de Windows. ReFS ha ido evolucionando con el tiempo, introduciendo nuevas versiones internas (1.1, 1.2, 3.1, 3.2, 3.3, 3.4, 3.7, 3.9…) y no todas se montan ni se soportan en todas las versiones del sistema operativo.

Por ejemplo, las primeras versiones 1.x cuentan con soporte en Windows Server 2012, 2012 R2, Windows 8.1, y también en builds posteriores como Windows 10 v1507, v1607, v1703, v1709, v1803, Windows 11 y Windows Server 2022. Sin embargo, las versiones 3.x solo se soportan a partir de determinadas ediciones más modernas.

Versiones como ReFS 3.1 y 3.2 ya no pueden montarse en Windows Server 2012 o Windows 8.1, y requieren al menos Windows Server 2016 o versiones específicas de Windows 10. A medida que avanzamos en la numeración (3.3, 3.4, 3.7, 3.9), la compatibilidad se restringe prácticamente a versiones recientes de Windows 10/11 y Windows Server 2019/2022.

Esto significa que, al diseñar una solución basada en ReFS, es crucial tener claro desde qué sistemas se va a acceder a esos volúmenes. Montar un volumen creado con una versión nueva de ReFS en un sistema antiguo puede no ser posible, lo que complica escenarios de migración o recuperación si no se ha planificado bien.

ReFS y Hyper-V: ¿sigue siendo la mejor práctica?

En el mundo Hyper-V se popularizó la recomendación de usar volúmenes ReFS para almacenar VHD/VHDX desde Windows Server 2012 R2, precisamente por los beneficios en rendimiento y administración: creación casi instantánea de discos, clonación rápida de máquinas, mejor integridad de datos y una gran sinergia con Storage Spaces Direct.

Algunos proveedores han sugerido en los últimos años que Microsoft habría suavizado esa recomendación, pero lo cierto es que la documentación y formación oficial de Microsoft sigue presentando ReFS como una opción muy recomendable para volúmenes de datos de máquinas virtuales en Windows Server 2016, 2019 y posteriores, especialmente cuando se utiliza Storage Spaces Direct.

Esto encaja con las experiencias en producción: en hosts con Windows Server 2019 o 2022, sobre cabinas SAN SSD (por ejemplo, RAID 1+0 con varios terabytes para VMs), muchos administradores continúan eligiendo ReFS para los discos de datos de Hyper-V, reservando NTFS para la partición de sistema.

En estos escenarios, la combinación de clonación de bloques, VDL disperso y la integración con espacios de almacenamiento suele traducirse en un incremento notable de IOPS efectivos y en tiempos de mantenimiento mucho menores para tareas como desplegar nuevas VMs o gestionar checkpoints.

Eso sí, conviene asegurarse de que todas las herramientas de backup y replicación que se vayan a utilizar (Veeam, Nakivo, etc.) tienen compatibilidad plena con ReFS y la versión concreta de Windows Server en cuestión. Los principales fabricantes hace tiempo que soportan este escenario, pero no está de más confirmarlo en la matriz de compatibilidad de cada producto.

ReFS vs NTFS para SQL Server y bases de datos

Cuando entramos en el terreno de SQL Server, la comparación se vuelve algo más delicada. NTFS es un sistema veterano, muy probado en producción, y respaldado por un ecosistema enorme de herramientas y buenas prácticas. Soporta todas las características que suelen aprovecharse en servidores de bases de datos y, aunque puede sufrir con cargas de E/S masivas y grandes volúmenes, su comportamiento es predecible.

ReFS, en teoría, ofrece ventajas claras para bases de datos: mejor resiliencia, menor fragmentación y buena integración con Storage Spaces, que permite crear pools de discos grandes, en espejo o paridad, con corrección automática de errores. Esto podría parecer ideal para archivos MDF, NDF y LDF con mucha actividad.

Sin embargo, hay un matiz importante: SQL Server gestiona su propia integridad de datos mediante transacciones ACID, checksums internos y mecanismos de recuperación muy sofisticados. Microsoft, de hecho, recomienda desactivar las secuencias de integridad de ReFS para los archivos de bases de datos, precisamente para evitar que el sistema de archivos intente «corregir» cosas que SQL Server necesita detectar y manejar por sí mismo.

Al desactivar estas funciones, una de las grandes ventajas teóricas de ReFS se diluye, y además seguimos teniendo el inconveniente de que ReFS consume más CPU y memoria que NTFS. En servidores de bases de datos muy exigentes, donde cada ciclo de CPU cuenta, ese overhead puede jugar en contra del rendimiento global.

Por ese motivo, muchos especialistas en SQL Server siguen prefiriendo NTFS para los volúmenes que alojan bases de datos en producción, reservando ReFS, como mucho, para volúmenes de copias de seguridad o almacenamiento secundario donde la deduplicación y otras características puedan aportar valor sin penalizar el motor de base de datos.

ReFS, deduplicación y backups

La deduplicación de datos es otra pieza relevante cuando hablamos de ReFS y entornos de backup. ReFS, en determinadas versiones de Windows Server, permite habilitar deduplicación sobre volúmenes con este sistema de archivos, algo muy útil para repositorios de copias de seguridad donde se repiten muchos bloques entre distintos puntos de restauración.

En el caso de SQL Server, la deduplicación no se aplica ni es recomendable sobre archivos de base de datos en uso, ya que los bloques internos son únicos y están muy estructurados. Sin embargo, puede tener sentido en volúmenes de backup de bases de datos, donde la deduplicación ayuda a reducir el espacio ocupado por copias sucesivas muy similares.

Dicho esto, utilizar deduplicación para copias de seguridad introduce su propio riesgo: los datos deduplicados pasan a depender de un conjunto más pequeño de bloques físicos, con lo que se crea un cierto punto único de fallo. Si la estructura de deduplicación se corrompe gravemente, se pueden perder múltiples copias de seguridad de una sola vez.

Por tanto, aunque la combinación de ReFS y deduplicación es muy atractiva para ahorrar espacio en grandes repositorios, conviene diseñar la estrategia de backup con cuidado, manteniendo copias adicionales en otros soportes o ubicaciones que no dependan exclusivamente de ese mecanismo.

Muchos fabricantes de soluciones de backup para virtualización, como NAKIVO Backup & Replication, Veeam y otros, han ido optimizando sus productos para sacar partido de ReFS: backups incrementales, uso de CBT/RCT (Changed Block Tracking/Resilient Change Tracking), backups sintéticos, soporte de appliances de deduplicación hardware, etc. Estas soluciones suelen apoyarse en ReFS para maximizar el ahorro de espacio y la velocidad de restauración, al tiempo que aplican sus propios motores de deduplicación y compresión.

NTFS, ReFS y la llegada a Windows 11

Hasta hace poco, ReFS estaba prácticamente limitado a ediciones de servidor y a algunos casos especiales en Windows 10. Sin embargo, en builds recientes de Windows 11, especialmente en el canal Canary, Microsoft ha empezado a probar instalaciones limpias de Windows 11 sobre ReFS, dando al usuario la opción de elegir entre NTFS (predeterminado) y ReFS durante el asistente de instalación.

En estas compilaciones preliminares, al seleccionar la partición donde se va a instalar el sistema, aparece un desplegable que permite formatear en NTFS o en ReFS, abriendo la puerta a que en el futuro Windows 11 pueda funcionar directamente sobre este sistema de archivos en equipos cliente.

La motivación principal es que ReFS proporciona, sobre el papel, mejor integridad de datos, soporte para volúmenes y archivos más grandes y un rendimiento muy bueno con las unidades de almacenamiento modernas (SSD NVMe, etc.). No obstante, mientras ciertos componentes críticos dependan de NTFS (arranque, compatibilidad con determinadas herramientas, etc.), es previsible que la transición sea gradual.

Para el administrador y el usuario avanzado esto significa que, en los próximos años, será cada vez más importante dominar las diferencias entre NTFS y ReFS, incluso en entornos de escritorio. La gestión adecuada de discos, particiones y backups pasará por entender qué gana y qué pierde cada sistema de archivos en cada escenario concreto.

En definitiva, NTFS sigue siendo la base sobre la que se asienta todo el ecosistema Windows, pero ReFS se ha consolidado como una pieza clave para almacenamiento moderno, virtualización y grandes repositorios de datos. Escoger el más adecuado en cada volumen no es cuestión de moda, sino de leer con detenimiento requisitos de rendimiento, resiliencia y compatibilidad, y apoyarse en el amplio trabajo que Microsoft y la comunidad han ido recopilando en los últimos años.