Windows Server y el nuevo soporte de arranque en ReFS

Portada » Internet » Windows Server y el nuevo soporte de arranque en ReFS

El soporte de arranque de Windows Server sobre volúmenes ReFS marca un antes y un después en la estrategia de almacenamiento de Microsoft. Tras años donde ReFS se utilizaba casi en exclusiva para datos y volúmenes secundarios, las compilaciones más recientes de Windows Server vNext Insider permiten que el propio sistema operativo se instale y ejecute directamente desde este sistema de archivos moderno.

Este cambio llega después de casi 14 años desde la aparición inicial de ReFS y se suma a una serie de mejoras de rendimiento, resiliencia y herramientas de administración que afectan especialmente a escenarios de copias de seguridad, grandes volúmenes de datos, virtualización intensiva y centros de datos que exprimen al máximo la infraestructura de almacenamiento.

Qué es ReFS y por qué importa para Windows Server

ReFS (Resilient File System) es el sistema de archivos más reciente de Microsoft, diseñado para ofrecer mayor integridad frente a la corrupción de datos, una escalabilidad muy superior a NTFS y optimizaciones específicas para entornos de almacenamiento modernos. Debutó con Windows Server 2012 y se ha ido consolidando en escenarios profesionales antes de ir llegando, poco a poco, a usuarios avanzados en equipos domésticos que manejan grandes volúmenes de información.

A diferencia de NTFS, ReFS fue concebido desde el principio con la prioridad puesta en la resiliencia, la detección temprana de errores y la reparación automática cuando es posible. Esto reduce la dependencia de utilidades clásicas como chkdsk, que en volúmenes masivos pueden requerir tiempos de parada inasumibles para muchas organizaciones.

Otra diferencia clave es la capacidad máxima de volumen. NTFS ya es capaz de manejar tamaños grandes, pero ReFS empuja el límite hasta aproximadamente 35 petabytes, una cifra pensada para centros de datos, infraestructuras de virtualización y entornos de expansión constante donde el crecimiento del almacenamiento es prácticamente continuo.

Con el paso del tiempo, ReFS ha pasado de ser un sistema de archivos reservado a servidores y estaciones de trabajo profesionales a convertirse también en una opción atractiva para quienes almacenan datos críticos y grandes repositorios en sus equipos personales. Eso sí, como cualquier sistema de archivos, no está exento de riesgos de pérdida de datos y requiere herramientas especializadas para la recuperación en caso de problemas.

Nuevo soporte de arranque ReFS en Windows Server

Las nuevas compilaciones de Windows Server vNext Insider incorporan soporte oficial de arranque desde ReFS. Esto significa que, durante el proceso de instalación de Windows Server, el administrador puede formatear la partición del sistema utilizando ReFS y completar la instalación arrancando desde ese volumen sin tener que recurrir a hacks, máquinas virtuales o configuraciones no soportadas.

La principal condición técnica es que el servidor cuente con firmware UEFI. El arranque heredado basado en BIOS no es compatible con esta funcionalidad, de modo que las infraestructuras que sigan dependiendo de BIOS tradicional no podrán aprovechar este avance sin una actualización de hardware o de configuración de firmware.

Este movimiento supone la primera vez que Microsoft habilita de forma oficial el arranque directo desde ReFS. Aunque en entornos de pruebas y versiones preliminares de Windows 11 algunos usuarios ya habían conseguido poner en marcha sistemas instalados en volúmenes ReFS, se trataba de escenarios no soportados donde se recurría a combinaciones de unidades NTFS, máquinas virtuales o técnicas avanzadas que se alejaban del uso estándar recomendado por Microsoft.

En la práctica, instalar Windows Server con soporte de arranque ReFS se reduce a unos pocos pasos: emplear una compilación Insider reciente con esta capacidad, elegir ReFS como sistema de archivos para la partición del sistema durante la instalación y, una vez completado el proceso, verificar el tipo de volumen tras el primer arranque para confirmar que todo está funcionando sobre ReFS.

Esta simplificación hace que integrar ReFS en el corazón mismo del sistema operativo deje de ser un experimento para convertirse en una opción estratégica en entornos de producción, especialmente en infraestructuras donde la integridad y la continuidad de servicio pesan más que cualquier otra consideración.

Ventajas técnicas de ReFS frente a NTFS

La adopción de ReFS como sistema de archivos de arranque no se entiende sin repasar sus ventajas técnicas fundamentales. Más allá del soporte de volúmenes gigantescos, ReFS ofrece características pensadas para minimizar la corrupción de datos, mejorar la continuidad del servicio y acelerar determinados flujos de trabajo típicos de entornos empresariales.

En primer lugar, ReFS incorpora mecanismos de detección y corrección de errores muy tempranos. Gracias a sumas de comprobación y metadatos adicionales, el sistema puede identificar corrupciones en bloques concretos y, cuando dispone de redundancia subyacente (por ejemplo, a través de Storage Spaces), reparar automáticamente dichos errores sin necesidad de interrumpir el servicio ni de montar operaciones de reparación masivas.

En segundo lugar, el diseño de ReFS reduce la dependencia de herramientas de mantenimiento tradicionales como chkdsk, que en discos de gran tamaño o con millones de archivos pueden convertirse en auténticos cuellos de botella operativos. Con ReFS, las operaciones de reparación y validación se distribuyen y localizan mejor, evitando revisiones monolíticas de todo el volumen.

También sobresale en escenarios donde se manejan archivos de gran tamaño de manera intensiva, como entornos de virtualización, bases de datos o repositorios de copias de seguridad. La funcionalidad de clonación de bloques y aprovisionamiento disperso permite crear, expandir y copiar archivos VHD o VHDX de tamaño fijo sin sufrir las penalizaciones de rendimiento típicas de otros sistemas de archivos.

Para empresas que trabajan con flujos de copia masiva, esta optimización se traduce en operaciones de copia sustancialmente más rápidas y en la posibilidad de gestionar grandes plantillas de máquinas virtuales, snapshots y volúmenes de backup sin que cada clonación se convierta en un proceso lento y costoso en recursos.

Impacto en almacenamiento empresarial y virtualización

La decisión de permitir que Windows Server arranque directamente desde ReFS refuerza el papel de este sistema de archivos en el ecosistema de almacenamiento empresarial. Hasta ahora, ReFS se utilizaba sobre todo para volúmenes de datos, repositorios de copias de seguridad, almacenamiento de máquinas virtuales y cargas de trabajo altamente escalables. Ahora pasa a poder hospedarse también el propio sistema operativo sobre ese mismo formato.

En entornos de virtualización, donde es habitual mantener decenas o cientos de máquinas virtuales, la capacidad de clonar discos virtuales con menor impacto en el rendimiento es una ventaja decisiva. La combinación de clonación de bloques, aprovisionamiento disperso y alta escalabilidad hace que ReFS resulte especialmente atractivo para infraestructuras que crecen con rapidez.

Además, al poder utilizar ReFS desde la partición de arranque, las organizaciones pueden unificar criterios y mantener una política homogénea de sistema de archivos en sus servidores, simplificando tareas de administración, monitorización, copias de seguridad y recuperación ante desastres.

Por otra parte, el hecho de que ReFS haya sido pensado para detectar corrupciones de datos sin detener el sistema reduce la probabilidad de ventanas de mantenimiento largas e imprevistas. La continuidad operativa en entornos críticos se ve beneficiada por esta capacidad de detectar y solucionar problemas en caliente siempre que haya redundancia de almacenamiento debajo.

No obstante, es importante tener en cuenta algunos matices. En pruebas realizadas en entornos de cliente, donde se ha llegado a arrancar Windows 11 Pro en unidades ReFS, se han observado en ocasiones ciertas operaciones de lectura y escritura algo más lentas que en NTFS, así como incompatibilidades puntuales con algunas aplicaciones de la Microsoft Store. Aunque en servidores los escenarios y requisitos son distintos, conviene evaluar el impacto real en cada entorno antes de una migración masiva.

Consumo de memoria y copias de seguridad en ReFS (Windows Server 2016)

Uno de los puntos más delicados que se han observado con ReFS, especialmente en equipos con Windows Server 2016, es el uso intensivo de memoria asociado al sistema de archivos. Administradores han reportado situaciones en las que los volúmenes ReFS parecen dejar de responder o se bloquean al ejecutar copias de seguridad, sobre todo cuando se utilizan aplicaciones que realizan operaciones de clonación de bloques de gran tamaño.

Para abordar estos problemas, Microsoft publicó una actualización incluida dentro de la actualización acumulativa del 22 de febrero de 2018. Esta corrección introduce mejoras de rendimiento en ReFS modificando la forma en que se gestionan las vistas de archivo en memoria, y añade una serie de parámetros de registro opcionales que permiten afinar el comportamiento del sistema de archivos en escenarios problemáticos.

Estas opciones de configuración están pensadas para entornos donde se manejan flujos de metadatos de gran tamaño, tal y como se documentó en artículos de soporte anteriores (referencias 4016173 KB y 4035951 KB). Es importante recalcar que, para que los cambios surtan efecto, es imprescindible reiniciar el servidor después de modificar los parámetros correspondientes en el registro.

Otro aspecto crítico es que estos parámetros no se solapan entre sí funcionalmente, de modo que pueden combinarse de diferentes maneras dependiendo de las necesidades de cada entorno. Eso sí, en configuraciones con clústeres de conmutación por error, es obligatorio mantener la misma configuración de estos valores en todos los nodos para evitar comportamientos inconsistentes.

A continuación se detallan los ajustes de registro más relevantes que se pueden utilizar para controlar el consumo de memoria y el comportamiento de los volúmenes ReFS sometidos a cargas de copia de seguridad intensivas.

Parámetros de registro para ajustar el rendimiento de ReFS

El principal objetivo de los parámetros de registro introducidos por Microsoft es permitir que los administradores tengan un mayor control sobre cómo ReFS asigna y libera memoria, así como sobre la forma en que se procesan determinadas colas internas que pueden crecer demasiado y provocar ralentizaciones o bloqueos.

Salvo que se indique lo contrario, la mayoría de estos valores se configuran en la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem, utilizando valores de tipo REG_DWORD y ajustando el dato decimal en función de la recomendación o de las pruebas realizadas en el entorno concreto.

Es fundamental realizar copias de seguridad del registro y probar estos cambios primero en entornos de preproducción o laboratorio antes de trasladarlos a sistemas críticos, ya que un ajuste demasiado agresivo puede derivar en comportamiento inesperado o en una degradación de rendimiento distinta a la que se pretende resolver.

Además, en escenarios donde se utiliza Microsoft Data Protection Manager (DPM) como solución de copia de seguridad, se han definido parámetros adicionales en ramas específicas del registro para controlar el tamaño de ciertas operaciones de duplicación de datos, que pueden introducir latencias elevadas cuando se realizan con tamaños de bloque excesivos.

Veamos uno a uno los parámetros más importantes y su efecto sobre el sistema.

RefsEnableLargeWorkingSetTrim

El parámetro RefsEnableLargeWorkingSetTrim controla el comportamiento de ReFS a la hora de liberar memoria asociada a las transmisiones de metadatos. Cuando se activa, el sistema de archivos realiza una comprobación de todo el mapa de memoria (MM map) de las transmisiones de metadatos en cada punto de control.

Esta opción resulta útil en equipos donde se observa que el conjunto de trabajo de ReFS crece de manera excesiva y no se libera con la rapidez deseada. Al activar este recorte, ReFS puede intentar recuperar memoria que ya no se está utilizando de forma efectiva, reduciendo así la presión sobre el subsistema de memoria.

Es importante señalar que esta configuración solo cumple su función óptima cuando el volumen ReFS está relativamente inactivo y no tiene páginas de metadatos asignadas activamente. En entornos donde la actividad sea constante, el efecto puede ser más limitado o incluso no apreciarse de forma inmediata.

Para habilitarlo, se debe crear o modificar el valor de registro con nombre RefsEnableLargeWorkingSetTrim en la ruta de sistema de archivos, de tipo REG_DWORD y con dato 1. Tras aplicar el cambio y reiniciar, el servidor empezará a realizar estas comprobaciones completas en cada punto de control del sistema de archivos.

RefsNumberOfChunksToTrim

ReFS incorpora una lógica de asignación diferida de memoria, lo que significa que no siempre libera de inmediato todos los rangos de direcciones virtuales cuando ya no son necesarios. El parámetro RefsNumberOfChunksToTrim determina cuántos segmentos de espacio de direcciones virtuales se desasocian en cada ciclo de liberación de memoria.

El número de espacios de direcciones desasignados depende tanto del valor configurado como del tamaño del volumen. Para volúmenes mayores de 10 TB, la cantidad se calcula como RefsNumberOfChunksToTrim multiplicado por 128 MB; para volúmenes menores de 10 TB, como RefsNumberOfChunksToTrim por 64 MB. Es decir, un valor de 4 puede traducirse en varios cientos de megabytes liberados por ciclo, según el tamaño del volumen.

Este recorte de memoria únicamente surte efecto cuando el rango de direcciones que se intenta desasignar no tiene referencias activas, es decir, cuando no existen páginas de metadatos todavía en uso dentro de ese rango. Por tanto, es más efectivo en sistemas donde hay periodos de actividad variable o picos muy marcados seguidos de fases de menor carga.

La recomendación inicial de Microsoft es establecer el valor RefsNumberOfChunksToTrim en 4 (decimal), aunque se admite su incremento a valores más altos como 8, 16 o 32 para hacer que el recorte de memoria sea más agresivo. Cuanto mayor sea este valor, más memoria podrá liberarse en cada ciclo, pero también puede aumentar el impacto sobre el rendimiento si se fuerza un recorte demasiado intenso.

En la práctica, conviene comenzar con el valor sugerido y, si no se obtienen resultados satisfactorios, realizar ajustes progresivos vigilando atentamente el consumo de memoria y el rendimiento general de los volúmenes ReFS durante las cargas de trabajo habituales.

RefsEnableInlineTrim

El parámetro RefsEnableInlineTrim lleva el recorte de memoria un paso más allá, ya que hace que ReFS envíe peticiones de liberación de memoria de manera en línea mientras desasigna páginas de metadatos. Es decir, el recorte se realiza simultáneamente con las operaciones normales relacionadas con el sistema de archivos, en lugar de concentrarse solo en puntos de control o ciclos específicos.

Esta opción se considera la más agresiva de todas las relacionadas con la gestión de memoria, porque puede provocar una regresión de rendimiento si se utiliza en medios de alto rendimiento como SSD o NVMe, donde la latencia de las operaciones de almacenamiento es muy baja y cualquier sobrecarga adicional se nota enseguida.

Para activarla, se debe añadir o modificar el valor RefsEnableInlineTrim en la clave de sistema de archivos, con tipo REG_DWORD y dato 1. Una vez reiniciado el servidor, ReFS empezará a efectuar estos recortes en línea durante sus operaciones regulares.

En entornos donde se hayan probado previamente ajustes como RefsEnableLargeWorkingSetTrim o RefsNumberOfChunksToTrim sin obtener mejoras suficientes, puede ser interesante evaluar esta opción, siempre con monitorización detallada del impacto en el rendimiento y preferiblemente en volúmenes que no se apoyen en hardware de almacenamiento ultrarrápido.

Microsoft sugiere probar diferentes combinaciones de estas opciones, ajustando especialmente RefsNumberOfChunksToTrim a valores como 8, 16 o 32 si se requiere un recorte más agresivo y observando el efecto global sobre el conjunto de trabajo de ReFS y la estabilidad del sistema.

RefsDisableCachedPins

Otra de las causas identificadas para el incremento notable del conjunto de trabajo de ReFS en algunos entornos es la presencia de «cached pins», estructuras internas que permanecen en memoria para acelerar determinadas operaciones. El parámetro RefsDisableCachedPins permite desactivar este mecanismo de almacenamiento en caché.

Al deshabilitar los pins almacenados en caché, ReFS reduce una de las principales contribuciones al crecimiento del conjunto de trabajo activo, lo que puede ser especialmente beneficioso en servidores con memoria limitada o en configuraciones donde el sistema de archivos compite por recursos con aplicaciones muy exigentes.

Para aplicar este cambio, se define el valor RefsDisableCachedPins en la ruta de sistema de archivos, de tipo REG_DWORD y con dato 1. Tras reiniciar, el sistema dejará de utilizar esta capa de caché específica, con el potencial de disminuir el consumo de memoria a costa, en algunos casos, de un pequeño impacto en el rendimiento de ciertas operaciones.

Esta opción suele considerarse cuando otros ajustes orientados al recorte de memoria no han sido suficientes para evitar que el conjunto de trabajo de ReFS crezca por encima de lo deseable, especialmente en servidores de copias de seguridad o de almacenamiento masivo donde la prioridad es la estabilidad.

RefsProcessedDeleteQueueEntryCountThreshold

El parámetro RefsProcessedDeleteQueueEntryCountThreshold introduce una heurística adicional en la lógica de puntos de control de ReFS relacionada con la cola de eliminaciones. Cuando esta cola alcanza un tamaño concreto, el sistema fuerza la ejecución de un punto de control para procesar dichas entradas.

Sin este mecanismo, es posible que la cola de objetos pendientes de eliminar crezca demasiado, provocando situaciones en las que las operaciones de entrada/salida (IO) se quedan bloqueadas mientras ReFS intenta procesar esa cola en bloque durante un punto de control estándar, lo que puede traducirse en bloqueos aparentes o pérdida de capacidad de respuesta del volumen.

La recomendación inicial es fijar el valor RefsProcessedDeleteQueueEntryCountThreshold en 2048 (decimal). Si aún así se observan problemas de bloqueo o tiempos de respuesta muy elevados, se puede reducir este número a 1024 e incluso a 512, haciendo que ReFS ejecute puntos de control con mayor frecuencia, pero sobre colas más pequeñas y manejables.

Este ajuste se orienta sobre todo a entornos donde se producen grandes cantidades de operaciones de borrado, como repositorios de copias de seguridad rotativas, volúmenes de pruebas automatizadas o sistemas donde se mueven y eliminan archivos masivamente como parte del flujo de trabajo.

Configurando correctamente este umbral, se puede conseguir un equilibrio razonable entre la frecuencia de puntos de control y la estabilidad del sistema, evitando picos de trabajo desproporcionados al procesar colas de eliminación gigantescas de una sola vez.

Parámetros específicos para Microsoft Data Protection Manager

En escenarios donde se utiliza Microsoft Data Protection Manager (DPM) para gestionar copias de seguridad, se identificó otro cuello de botella relacionado con las llamadas «duplicate extent» de gran tamaño. Estas operaciones, cuando abarcan bloques muy grandes, pueden introducir latencia apreciable en el sistema, ya que otras tareas deben esperar a que terminen estos procesos de larga duración.

Para mitigar este problema, se introdujo el parámetro DuplicateExtentBatchSizeinMB, que ajusta el tamaño de la extensión duplicada utilizada en estas llamadas. Este valor se encuentra en la clave de registro específica de DPM: HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Data Protection Manager\Configuration\DiskStorage, de tipo REG_DWORD.

El valor predeterminado de DuplicateExtentBatchSizeinMB es de 2000 MB (2 GB), pero la recomendación es reducirlo a 100 MB (decimal) para evitar que cada operación de duplicación se convierta en una tarea extremadamente pesada. DPM adoptará este cambio de clave como configuración por defecto a partir de la actualización UR4, simplificando así la vida de los administradores que desplieguen esa versión o posteriores.

Se acepta cualquier valor comprendido entre 1 y 4095 MB, de modo que cada organización puede afinar el tamaño de estas operaciones en función de sus necesidades y de la capacidad de su infraestructura de almacenamiento. En general, un tamaño menor reduce la latencia individual de cada operación a costa de incrementar el número total de llamadas necesarias para completar el mismo trabajo.

Ajuste del parámetro TimeOutValue del servicio de disco

Otro parámetro relevante, aunque no específico de ReFS, es TimeOutValue, que se encuentra en la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk. Este valor determina el tiempo de espera que el sistema asigna a determinadas operaciones de disco antes de considerarlas fallidas.

En entornos con volúmenes muy grandes, operaciones de copia intensivas o sistemas de almacenamiento algo más lentos, puede resultar conveniente aumentar este tiempo de espera para evitar que operaciones legítimas se marquen como fallidas por tardar más de lo previsto. El valor por defecto suele ser 0x41 en hexadecimal, es decir, 65 en decimal.

La recomendación para mejorar la tolerancia a retrasos es establecer TimeOutValue en 0x78 (hexadecimal), que se traduce en 120 en decimal. De este modo, el sistema concederá un margen de tiempo mayor a las operaciones de disco, reduciendo la probabilidad de errores por timeout en situaciones de carga elevada.

Como siempre que se tocan parámetros de este nivel, conviene comprobar el comportamiento del sistema tras el cambio, asegurando que no se ocultan problemas más profundos de rendimiento o de hardware al simplemente ampliar el tiempo de espera de las operaciones.

ReFS en entornos de usuario avanzado y copias de seguridad

Aunque la mayoría de las novedades en torno al soporte de arranque ReFS se centran en Windows Server, también se han visto intentos de arrancar versiones preliminares de Windows 11 desde unidades ReFS en equipos físicos. En algunos de estos experimentos, se ha recurrido a unidades de sistema formateadas en NTFS y unidades de datos en ReFS, o directamente a instalaciones sobre ReFS en entornos no soportados oficialmente.

Las experiencias de estos usuarios suelen ser mixtas. Por un lado, demuestran que es técnicamente posible ejecutar Windows desde ReFS; por otro, reflejan ciertas desventajas prácticas como operaciones de lectura y escritura algo más lentas en tareas concretas o incompatibilidades puntuales con aplicaciones de la Microsoft Store, como la propia herramienta de recortes, que se niegan a instalar o presentar fallos de ejecución.

En paralelo, el debate sobre el almacenamiento fiable y las copias de seguridad en otros ecosistemas, como Linux, pone de relieve la importancia de disponer de funcionalidades equivalentes a Volume Shadow Copy (VSS) de Windows, que permite capturar instantáneas coherentes incluso cuando el sistema está en uso.

En el mundo Linux, a menudo las estrategias de respaldo se apoyan en herramientas como borg o borgbackup, que ofrecen deduplicación de datos y snapshots lógicos independientes. Aunque estas soluciones no siempre garantizan la misma coherencia interna sin recurrir a mecanismos adicionales (como LVM snapshots o integraciones con sistemas de archivos específicos), ayudan a reducir de forma drástica el espacio ocupado por múltiples puntos de recuperación.

Borg, por ejemplo, aplica deduplicación de manera que cada snapshot independiente puede parecer un espejo completo del sistema de archivos en un momento dado, pero en realidad solo almacena los bloques nuevos o modificados, compartiendo el resto con snapshots anteriores. Esto permite mantener un historial amplio sin necesidad de disponer de capacidad de almacenamiento casi infinita, algo crítico cuando se quiere defenderse de amenazas como el ransomware o los errores humanos.

Recuperación de datos en volúmenes ReFS

Una preocupación recurrente al adoptar un sistema de archivos relativamente nuevo como ReFS es la disponibilidad de herramientas de recuperación de datos en caso de fallos, corrupción o errores humanos (borrados accidentales, formateos, etc.). Durante bastante tiempo, las opciones más sólidas para recuperar información de ReFS eran utilidades profesionales de alta gama, con un coste y una complejidad considerables.

La situación ha mejorado con las versiones recientes de suites como UFS Explorer, Recovery Explorer y Raise Data Recovery. A partir de la versión 8.14, todas las ediciones de estos programas, incluyendo las más asequibles, han incorporado soporte para procesar volúmenes ReFS, acercando la recuperación de datos de este sistema de archivos a un público mucho más amplio.

El funcionamiento general de estas herramientas con ReFS es similar al de otros sistemas de archivos. El usuario debe seleccionar el volumen ReFS afectado, iniciar un análisis o escaneo y, una vez completado, navegar por los datos encontrados para recuperar aquellos archivos o carpetas que necesite. Los programas permiten acceder a los datos aún presentes en el volumen, recuperar elementos eliminados o formateados, e incluso reconstruir particiones ReFS perdidas o dañadas.

Conviene tener en cuenta que, si el volumen ReFS tiene habilitada la funcionalidad de deduplicación de datos, solo la edición Professional de UFS Explorer está capacitada para procesarlo correctamente, debido a la complejidad extra que añade la deduplicación a la estructura de los datos almacenados.

Los programas actualizados con estas capacidades se pueden descargar desde los sitios web oficiales o desde la tienda de software de sysdevlabs.com, lo que facilita su obtención tanto para administradores profesionales como para usuarios avanzados que quieran maximizar sus opciones de recuperar datos valiosos de volúmenes ReFS en caso de incidente.

Con todo este contexto, el soporte de arranque ReFS en Windows Server se suma a una evolución más amplia: un sistema de archivos que empezó centrado en la resiliencia en servidores, que ha visto aparecer herramientas de recuperación más accesibles y que ahora se integra ya en el propio corazón del sistema operativo, consolidándose como alternativa moderna y robusta a NTFS en infraestructuras donde la integridad, la escalabilidad y la continuidad del servicio marcan la diferencia.