Cómo funciona la Instantánea de volúmenes (VSS) en la práctica — por qué es posible respaldar archivos en uso

«Intenté copiar un archivo que otra aplicación tenía abierto y me saltó el error de que el proceso no puede acceder al archivo», «me pidieron hacer copia de seguridad de la carpeta de datos sin detener el sistema central», «¿por qué el software de backup puede copiar tranquilamente un archivo de base de datos en uso?» — tanto en el desarrollo de aplicaciones empresariales como en la operación de servidores de archivos, tarde o temprano se topa uno con estas preguntas.

En el centro de la respuesta está el Servicio de instantáneas de volumen (VSS: Volume Shadow Copy Service). Es un mecanismo integrado en Windows desde hace más de veinte años, sobre el que se apoyan Windows Server Backup, la restauración del sistema y prácticamente todo el software de backup comercial.¹

Este artículo se dirige tanto a los desarrolladores de aplicaciones empresariales a quienes se les pide una «función para copiar archivos en uso» como al personal de sistemas que gestiona la copia de seguridad de servidores de archivos y PC de trabajo. Organizamos, con base en fuentes primarias vigentes a agosto de 2026, quiénes son los actores y cómo funciona VSS, la práctica operativa con vssadmin, y hasta dónde debería involucrarse un desarrollador con VSS. En la serie «Las profundidades de la E/S de Windows» hemos analizado el interior del administrador de caché y de NTFS; este artículo es su continuación y trata la capa de «instantánea» que se intercala justo por encima del volumen.

1. Conclusión inicial

• VSS es un conjunto de interfaces COM y un servicio de coordinación que permite «hacer copia de seguridad de un volumen mientras una aplicación sigue escribiendo en él». Está integrado desde Windows XP en adelante.²
• Hay tres roles más un rol coordinador. El servicio VSS hace de intermediario entre el solicitante que pide la instantánea (el software de backup), el escritor que garantiza la integridad de los datos del lado de la aplicación (SQL Server, etc.) y el proveedor que crea realmente la instantánea.¹
• El proveedor de sistema estándar de Windows usa el método copy-on-write. En lugar de duplicar todo el volumen, guarda en el área de diferencias (diff area), justo antes de reescribirlos, únicamente los bloques que se modifican después de tomar la instantánea. El área de diferencias debe estar en un volumen NTFS.¹
• El punto de quietud se crea con la secuencia «congelación de los escritores (máximo 60 segundos) → creación de la instantánea (menos de 10 segundos) → descongelación». Si se supera el tiempo límite, la creación se cancela y el solicitante debe intentarlo de nuevo.¹
• La calidad de la copia depende de si hay o no colaboración de los escritores. Una instantánea sin colaboración equivale al «disco en el instante en que se corta la energía» (consistencia ante fallos, crash consistent); con colaboración, los escritores rotan registros y vacían cachés de antemano, dejando un estado consistente que la propia aplicación garantiza como recuperable (consistencia de aplicación, application consistent).³¹
• La comprobación operativa se hace con vssadmin. Con list shadows, list writers y list shadowstorage se revisa el estado actual, y con resize shadowstorage se ajusta el límite del área de diferencias. Cuando el área de diferencias se agota, las instantáneas más antiguas se eliminan en silencio.⁴⁵¹
• Incorporar un solicitante de VSS a una aplicación propia es una tarea considerable. Es una API nativa basada en COM sin un envoltorio oficial para .NET. En la mayoría de los casos basta con reintentos, ajustar el modo de uso compartido o una parada breve; si de verdad se necesita VSS, la solución realista es un script de DiskShadow (solo en Windows Server).⁶⁷
• La instantánea no es en sí misma una copia de seguridad. Como la diferencia de copy-on-write depende de los bloques intactos del volumen original, no ofrece ninguna protección ante un fallo que haga perder el volumen original entero, como una avería de disco o un robo. Tampoco se puede confiar en ella frente al ransomware, porque el propio atacante puede eliminar las instantáneas (7.3) o agotar el área de diferencias con reescrituras masivas (7.4). Solo cobra sentido combinada con una copia de seguridad en otro medio.¹

2. Planteamiento del problema — por qué no se puede copiar un archivo en uso de forma normal

El punto de partida es el modo de uso compartido de archivos de Windows. Al abrir un archivo (CreateFile), Windows declara, mediante el modo de uso compartido (dwShareMode), «qué se permite a otros procesos mientras el propio proceso lo tiene abierto». Mientras haya un proceso que lo abrió sin permitir el uso compartido de lectura, cualquier proceso que intente abrirlo después para lectura fallará con una violación de uso compartido (ERROR_SHARING_VIOLATION, error 32).⁸ En .NET es el conocido error que aparece como IOException («El proceso no tiene acceso al archivo porque está siendo utilizado por otro proceso»).

Lo importante es que esto no es un fallo, sino un mecanismo correcto para proteger los datos. Si se lee un archivo mientras se está escribiendo, quien lo lee acaba obteniendo «un estado a medio escribir». El diseño del control de exclusión, tratado en detalle en «Fundamentos del control de exclusión en la integración de archivos», es la base de la integración entre aplicaciones.

Sin embargo, este mecanismo correcto entra en conflicto de raíz con la copia de seguridad.

• La barrera de la violación de uso compartido: un archivo que una base de datos o una aplicación empresarial mantiene abierto de forma permanente puede que, directamente, no se pueda abrir como origen de la copia.
• La barrera de la integridad: incluso si se puede abrir (porque el uso compartido de lectura está permitido), copiar lleva tiempo. Como la aplicación sigue escribiendo mientras se copia, la primera mitad y la segunda mitad del archivo pueden acabar reflejando momentos distintos, o puede dejar de haber coherencia entre varios archivos (los datos y su registro, por ejemplo). Además, como vimos en la entrega sobre el «administrador de caché», la escritura primero pasa por la caché en memoria, así que mirar solo el archivo en disco no garantiza ver la versión más reciente.
• La barrera operativa: «entonces basta con detener la aplicación y copiar» es un argumento correcto, pero en sistemas empresariales o servidores de archivos que funcionan las 24 horas no es aceptable.

En definitiva, el requisito es «sin detener la aplicación, obtener una copia consistente de un instante concreto». Resolverlo por su cuenta es demasiada carga para cada aplicación individual, y VSS es el mecanismo preparado a nivel de sistema operativo para ello. VSS se ofrece como un marco de trabajo basado en interfaces COM que permite hacer copia de seguridad de un volumen incluso mientras la aplicación sigue escribiendo en él.²

3. Los actores de VSS — solicitante, escritor y proveedor

La arquitectura de VSS se organiza en tres roles y un servicio que actúa de intermediario entre ellos.¹

Lo elegante de este reparto de roles es que permite coordinar productos que no se conocen entre sí. El software de backup (el solicitante) no conoce la estructura interna de SQL Server, pero el escritor de SQL Server declara como metadatos «el conjunto de archivos que se debe respaldar (los componentes)» y ordena sus propios datos justo antes y después de crear el punto de quietud, de modo que al solicitante le basta con seguir esas indicaciones para obtener una copia consistente.¹⁹ Prácticamente todo el software de backup de terceros que funciona en Windows es un solicitante de VSS.¹

En la práctica de sistemas, el momento en el que estos tres roles cobran importancia es la resolución de incidencias. Según si el fallo del software de backup es un problema del solicitante (el propio software), de un escritor concreto (el lado de la aplicación) o del proveedor y el área de diferencias (la infraestructura), el lugar donde hay que investigar cambia por completo (capítulos 5 y 7).

4. Cómo funciona la instantánea — copy-on-write y el “punto de quietud”

4.1. Copy-on-write — guardar “ese instante” sin duplicar el volumen

Al oír «instantánea» se imagina uno la duplicación de todo el volumen, pero el proveedor de sistema estándar de Windows usa el método copy-on-write. En el momento de crear la instantánea prácticamente no se copia nada. Después, cuando se reescribe un bloque del volumen original, antes de que termine la reescritura se traslada el bloque previo al área de diferencias (diff area, el almacenamiento de instantáneas) y solo entonces se deja pasar la escritura.¹ El traslado solo hace falta la primera vez que se reescribe cada bloque; sobrescribir un bloque ya trasladado no incrementa el área de diferencias.

Para leer «el volumen en aquel instante», los bloques que no cambiaron se leen del volumen original y los bloques que cambiaron se leen del área de diferencias, y se combinan. Como solo se copia lo que cambió, la creación es instantánea y el espacio que consume es únicamente la diferencia. Dicho de otro modo, cuanto más se escribe en un volumen, más rápido se consume su área de diferencias (esto anticipa el capítulo 7), y el área de diferencias se ubica en un volumen NTFS de la misma máquina que los datos originales.¹ Lo que sostiene este mecanismo es swprv.dll, el archivo de componentes del proveedor de sistema, y volsnap.sys, el controlador que se intercala en la E/S del volumen.¹ Si le interesa «cómo interceptar» la pila de E/S, también puede consultar «Controladores de filtro y minifiltros».

Existen además otros métodos: la copia completa, que separa un espejo, y redirect-on-write, que escribe los cambios en otro volumen; los proveedores de hardware usan, del lado del dispositivo de almacenamiento, el método que mejor les conviene.¹

4.2. El proceso de creación del punto de quietud — congelación de 60 segundos, creación de 10

Si copy-on-write responde a «cómo se guarda», la verdadera aportación de VSS está en «el estado de qué momento se guarda», es decir, cómo se crea el punto de quietud. La creación de una instantánea sigue el siguiente proceso.¹

flowchart TB
    R["El solicitante pide la creación<br/>Enumera los escritores y recopila metadatos"] --> M["Cada escritor declara en XML<br/>los objetos de respaldo (componentes)"]
    M --> P["Cada escritor prepara sus datos<br/>rota registros, vacía cachés, etc.<br/>y los deja en un estado consistente y recuperable"]
    P --> F["Se congela la E/S de escritura de los escritores<br/>(la lectura sigue disponible; máximo 60 segundos)"]
    F --> FS["VSS vacía los búferes del sistema de archivos<br/>y congela el sistema de archivos"]
    FS --> C["El proveedor crea la instantánea<br/>(en menos de 10 segundos; la E/S de escritura sigue congelada)"]
    C --> T["Se libera el sistema de archivos → se descongelan (thaw) los escritores<br/>la aplicación reanuda la escritura"]
    T --> B["El solicitante realiza el backup<br/>desde la instantánea, con el tiempo que necesite"]

Figura 1: Proceso de creación de una instantánea. La aplicación solo se detiene unos segundos o decenas de segundos, y el backup propiamente dicho se ejecuta contra la instantánea.

Hay tres puntos clave.

1. La aplicación solo se detiene durante el instante en que se crea el punto de quietud. La congelación está limitada a 60 segundos y la creación (commit) por el proveedor a 10 segundos; si se superan, la creación se cancela y el solicitante vuelve a intentarlo.¹ El backup propiamente dicho, que puede tardar horas, se ejecuta contra la instantánea de solo lectura ya creada, con la aplicación funcionando con normalidad.
2. Durante la congelación la lectura sigue siendo posible. Solo se detiene la E/S de escritura.¹
3. El propio sistema de archivos también se congela. Como VSS vacía los búferes del sistema de archivos antes de congelarlo, las escrituras que estaban en caché y los metadatos del sistema de archivos quedan reflejados en la instantánea en un orden consistente.¹

4.3. Consistencia ante fallos y consistencia de aplicación

Aquí aparece una distinción importante que determina la calidad de la copia de seguridad.

Una instantánea creada sin la colaboración de los escritores está en lo que Microsoft llama estado de consistencia ante fallos (crash consistent). La definición oficial lo describe como «un estado del disco equivalente al que se encontraría tras un fallo catastrófico que provoca un apagado repentino del sistema», y restaurar desde ahí equivale a «reiniciar tras un apagado repentino».³ Como sistema de archivos no está dañado, pero desde el punto de vista de la aplicación es «el instante en que se desenchufó la corriente en mitad de una escritura». Muchas bases de datos con mecanismos de recuperación basados en el registro de transacciones pueden recuperarse a partir de ahí, pero eso presupone ejecutar ese proceso de recuperación.

Con la colaboración de los escritores, justo antes del punto de quietud cada escritor rota su registro de transacciones y vacía sus cachés, dejando un estado consistente que la propia aplicación garantiza como «recuperable correctamente a partir de aquí».¹ Esto es la consistencia de aplicación, y es la razón de ser del mecanismo de los escritores. Conviene tener presente que lo que garantiza un escritor es «un estado de aplicación consistente y recuperable», y no que las transacciones en curso se confirmen (commit) por su cuenta y queden completadas. El trabajo no confirmado se revierte (rollback) al restaurar, igual que en la recuperación normal de una base de datos. El escritor logra esta garantía de calidad sin detener la aplicación, con solo unas decenas de segundos de congelación.

Que las opciones de configuración del software de backup incluyan cosas como «usar VSS» o «garantizar la consistencia de la aplicación» es un reflejo de esta distinción. Para un conjunto de archivos corrientes en un servidor de archivos, la consistencia ante fallos apenas supone un problema, pero en servidores que alojan bases de datos o almacenes de correo, que el escritor correspondiente funcione correctamente es, en sí mismo, la calidad de la copia de seguridad.

5. La práctica operativa con vssadmin y las “versiones anteriores”

La herramienta con la que, en la práctica de sistemas, se comprueba el estado de VSS es vssadmin (se ejecuta en una consola de comandos con privilegios de administrador). La referencia de comandos vigente indica que list shadows, list writers, delete shadows y resize shadowstorage están disponibles tanto en cliente como en servidor.⁴ La referencia orientada a Windows Server añade además create shadow, list shadowstorage, list providers, entre otros.⁵ Cabe señalar que vssadmin solo puede administrar las instantáneas creadas por el proveedor de sistema.¹

Si el resultado de list writers muestra un escritor en estado de error, lo que hay que sospechar no es el propio VSS, sino la aplicación que proporciona ese escritor. Se debe comprobar el estado del servicio de la aplicación responsable y el visor de eventos de aplicación o de sistema (capítulo 7).

El parámetro /maxsize de resize shadowstorage permite indicar el límite con unidades como KB/MB/GB; si no se especifica, queda sin límite. Hay que tener presente que se advierte explícitamente que el propio cambio del límite del almacenamiento (en especial, reducirlo) puede provocar la pérdida de instantáneas.¹⁰ No conviene reducir a la ligera el límite de un volumen del que se quieren conservar varias generaciones.

5.1. La relación con las “versiones anteriores”

Al habilitar en un servidor de archivos «Instantáneas de carpetas compartidas» (Shadow Copies of Shared Folders), se conserva periódicamente una copia de los archivos del recurso compartido en un momento dado, y el usuario puede restaurar sin ayuda del administrador, desde «Versiones anteriores», un archivo que borró o sobrescribió por error.¹ Es la aplicación de VSS más cercana al día a día, y reduce de forma clara la carga de la mesa de ayuda.

Sin embargo, hay límites. Las instantáneas del proveedor de sistema llegan hasta un máximo de 512 por volumen, y de ellas, la función de instantáneas de carpetas compartidas mantiene por defecto hasta 64 (modificable mediante el valor de registro MaxShadowCopies).¹ Y, como se explica en los capítulos siguientes, si el área de diferencias no alcanza, las generaciones más antiguas se eliminan automáticamente. Lo más prudente es entender que «cuántas generaciones quedan» no lo determina el número de generaciones configurado, sino el volumen de escritura y el tamaño del área de diferencias.

6. El papel del desarrollador — ¿necesita VSS una aplicación propia?

A partir de aquí adoptamos el punto de vista del desarrollador. Cuando le piden «añadir una función de backup que también pueda copiar archivos en uso», ¿cómo debería relacionarse con VSS?

6.1. Crear un solicitante propio es una tarea considerable

La API de VSS se ofrece, tanto para el solicitante como para el escritor, como interfaces de COM y C++ (el núcleo del solicitante es IVssBackupComponents).⁶ No existe un envoltorio oficial para .NET, y hay que implementar correctamente desde la recolección de metadatos de los escritores hasta la gestión del conjunto de instantáneas y la limpieza en caso de error, así que no es algo que se pueda incorporar a la ligera como una función más de una aplicación empresarial. En nuestros presupuestos de desarrollo por encargo, «crear un solicitante de VSS propio» lo tratamos como una partida de desarrollo independiente.

Hay dos soluciones realistas. La primera, dejarlo en manos de software de backup existente compatible con VSS. La segunda, si se trata de Windows Server, usar DiskShadow desde un script. DiskShadow es un solicitante de VSS incluido en el sistema operativo que, además del modo interactivo, tiene un modo de script (diskshadow /s script.txt) con el que se puede escribir en un solo script todo el proceso: crear la instantánea, exponerla como letra de unidad (expose), ejecutar el lote que realiza la copia (exec) y hacer la limpieza final.⁷¹ Con esto se puede montar el flujo «crear la instantánea → extraer los archivos con un proceso de copia propio → eliminarla» sin escribir ni una línea de COM. Ahora bien, DiskShadow es exclusivo de Windows Server y no está incluido en los sistemas operativos cliente.¹ Si el requisito también incluye PC cliente, en ese punto la balanza se inclina hacia adoptar software de backup existente.

6.2. ¿Realmente hace falta VSS? — tabla de decisión

Según nuestra experiencia, la mayoría de las consultas sobre «copiar archivos en uso» se resuelven sin VSS. Conviene determinar primero el nivel real del requisito y elegir la herramienta después.

6.3. ¿Debería una aplicación propia registrar un escritor?

Conviene ordenar también la pregunta en sentido contrario: «¿debería una aplicación empresarial propia ofrecer un escritor de VSS?». Si se escribe un escritor, sin importar qué software de backup use el cliente, los datos de la aplicación propia se podrán respaldar con consistencia de aplicación. Existe además un mecanismo más simple que un escritor normal, el escritor exprés (express writer, IVssExpressWriter), pero este solo registra la declaración de metadatos sobre qué archivos incluir o excluir.⁶ Como no recibe notificaciones de congelación/descongelación, no puede detener la escritura de la aplicación en coordinación con la creación de la instantánea. El escritor exprés solo conviene usarlo junto con un diseño de guardado que no se rompa aunque se capture a medio escribir (que le baste la consistencia ante fallos); si hace falta coordinación en el punto de quietud, es necesario implementar un escritor normal.

Aun así, el criterio para decidir es sencillo.

• Si los datos están en una base de datos como SQL Server, no hace falta. El escritor de la propia base de datos garantiza la integridad.¹
• Si es un simple guardado de archivos, primero se resuelve con el diseño del propio proceso de guardado. Si se guarda de forma atómica —escribir por completo en un archivo temporal y sustituirlo mediante un renombrado—, ni siquiera una instantánea con consistencia ante fallos deja «un archivo guardado corrupto».
• Vale la pena plantearse registrar un escritor únicamente en el caso de aplicaciones que tienen un almacén de datos propio repartido en varios archivos y necesitan que todos sean mutuamente consistentes en el punto de quietud. Puede que, antes que nada, convenga replantearse si tiene sentido mantener datos de ese volumen en un formato propio.

7. Trampas — cuatro que importan de verdad en la operación

7.1. VSS no es en sí mismo una copia de seguridad

Es la trampa más importante. La instantánea del proveedor de sistema es una diferencia que vive en el disco de la misma máquina que los datos originales. Si se pierde el área de diferencias, ya no se puede recomponer nada, así que no ofrece ninguna protección frente a una avería de disco, el robo o extravío del equipo, o el cifrado de todo el volumen. La propia documentación de Microsoft distingue con claridad entre instantánea y copia de seguridad: «lo que se copia de la instantánea a un medio como una cinta es la copia de seguridad, y una vez copiado se puede eliminar la instantánea».¹ La instantánea es un punto de quietud y un medio de restauración rápida ante errores; no sustituye a una copia de seguridad en otro medio y en otra ubicación.

7.2. Los errores de un escritor son un problema de la aplicación

Cuando el software de backup falla con un «error de VSS», lo primero es identificar con vssadmin list writers qué escritor está fallando. Como el escritor es, en realidad, un componente del lado de la aplicación (o de un componente de Windows)¹, el terreno principal de la investigación es el estado del servicio de la aplicación responsable y su visor de eventos. Dejarse llevar por la apariencia de «error del software de backup» e investigar solo ese lado acaba siendo un rodeo. La forma general de acotar el problema sigue el mismo patrón tratado en «Mantenimiento de un sistema sin código fuente ni documentación»: acotar a los sospechosos a partir de los hechos observables.

7.3. El ransomware viene a borrar las instantáneas

Es un hecho que conviene conocer desde el lado defensivo. Es tentador pensar que, si se puede volver atrás con «Versiones anteriores», también se podría revertir un cifrado por ransomware, pero es ampliamente conocido que buena parte del ransomware elimina las instantáneas antes o después de cifrar, precisamente para cortar esta vía de recuperación. Eliminar instantáneas se puede hacer con comandos legítimos con solo tener privilegios de administrador, así que no es la última línea de defensa capaz de frenar a un atacante que ya ha entrado. Por eso el eje de las medidas debe ser: (1) situar la instantánea no como «parte del plan de recuperación», sino como algo «rápido si está disponible»; (2) mantener aparte una copia de seguridad fuera de línea y en otra ubicación a la que el atacante no pueda llegar; y (3) no otorgar privilegios de administrador a las cuentas de uso diario. Para la defensa del ciclo de vida del PC, incluyendo backup, cifrado y baja del equipo, consulte también «Guía práctica de BitLocker» y la «Lista de comprobación para dar de baja un PC».

7.4. Cuando se agota el área de diferencias, las versiones más antiguas desaparecen en silencio

Como vimos en el capítulo 4, el copy-on-write consume área de diferencias cuando cada bloque se reescribe por primera vez después de tomar la instantánea. Sobrescribir cualquier número de veces un bloque ya trasladado no aumenta el consumo, así que la cantidad consumida no la determina «el número de escrituras», sino la amplitud del rango de bloques reescritos desde la instantánea que se conserva. Y cuando el área de diferencias llega a su límite, las instantáneas de ese volumen se eliminan en orden, empezando por las más antiguas.¹ Como no se notifica nada al usuario, suele descubrirse solo cuando «se supone que se podía volver a la versión de la semana pasada» y ya no es posible. Ahora bien, no es del todo silencioso: en el registro del sistema quedan eventos con origen volsnap (el 25 cuando se elimina una instantánea por no poder reservar área de diferencias, o el 35/36 cuando se cancela una ampliación fallida o se llega al límite, entre otros). Además de las comprobaciones periódicas, incluir estos eventos de volsnap en la supervisión y las alertas permite detectar la pérdida de inmediato. El motivo por el que procesos que «recorren ampliamente el volumen» —una actualización masiva de archivos, una conversión por lotes, una desfragmentación— pueden devorar el área de diferencias de golpe es precisamente esta propiedad de que el consumo lo determina el rango reescrito. Revise periódicamente el uso con vssadmin list shadowstorage para comprobar si las generaciones conservadas cumplen el requisito del negocio («¿en cuántos días, como máximo, se detecta un borrado por error?»), y amplíe el límite si hace falta.⁵¹⁰

8. Resumen

• Que no se pueda copiar normalmente un archivo en uso se debe a la violación de uso compartido y a los problemas de integridad, y ese es un mecanismo correcto para proteger los datos. VSS es la respuesta a nivel de sistema operativo a «se quiere una copia consistente sin detener nada».
• VSS es un marco en el que el servicio VSS media entre tres roles —el solicitante (que pide), el escritor (que garantiza la integridad) y el proveedor (que crea)—, lo que permite coordinar software de backup y aplicaciones empresariales que no se conocen entre sí.
• El proveedor de sistema usa el método copy-on-write, y el punto de quietud se crea con «congelación de los escritores (máximo 60 segundos) → creación (menos de 10 segundos) → descongelación». Sin la colaboración de los escritores se obtiene consistencia ante fallos; con ella, consistencia de aplicación.
• La comprobación operativa se hace con vssadmin (list shadows / list writers / list shadowstorage). Ante un error de un escritor, sospeche de la aplicación, y revise periódicamente el uso del área de diferencias.
• El desarrollador debe comprobar primero, con la tabla de decisión, si el problema se resuelve con reintentos, modo de uso compartido, una parada o un diseño de integración, y recurrir a VSS solo cuando de verdad haga falta. Antes que una implementación propia, la solución realista es un script de DiskShadow (solo en Server) o software ya existente.
• La instantánea no es una copia de seguridad. No es más que una diferencia que depende de los bloques intactos del volumen original: no ofrece ninguna protección ante la pérdida del volumen original, como una avería de disco, y tampoco se puede confiar en ella frente al ransomware, por la eliminación de instantáneas o el agotamiento del área de diferencias. Combínela con una copia de seguridad fuera de línea y en otra ubicación.

Artículos relacionados

• Fundamentos del control de exclusión en la integración de archivos - Mejores prácticas de bloqueo de archivos y claim atómico
• Las profundidades de la E/S de Windows (4.ª entrega) — Administrador de caché: ¿cuándo llega su WriteFile al disco?
• Las profundidades de la E/S de Windows (5.ª entrega) — Estructura interna de NTFS: entender el sistema de archivos a partir de la MFT
• Cuando hereda un sistema sin código fuente ni especificaciones — Procedimiento práctico para operarlo y mantenerlo sin detenerlo
• Guía práctica de BitLocker — Cifrado de unidades empezando por la gestión de la clave de recuperación
• Qué hacer antes de dar de baja un PC con Windows — Lista de comprobación práctica de borrado de datos, baja de cuentas y copia de seguridad

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del diseño y desarrollo de aplicaciones empresariales que incluyen funciones de «copia y backup de archivos en uso», de la investigación de violaciones de uso compartido en la integración de archivos y de fallos de backup (errores de escritor de VSS), y de la organización operativa del backup y la gestión de generaciones en servidores de archivos. Puede empezar simplemente por determinar si el requisito realmente necesita VSS.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Si existen instantáneas (shadow copies), ya no hace falta hacer copias de seguridad?

No deja de hacer falta. Las instantáneas que crea el proveedor de sistema estándar de Windows son diferencias generadas con el método copy-on-write: no existe en ningún otro lugar «una copia completa de ese momento», sino que dependen de los bloques del volumen original que aún no se han reescrito. Aunque se coloque el área de diferencias (diff area) en otro volumen, si se pierde el volumen original tampoco será posible restaurar nada, de modo que ante un fallo de disco o el robo o extravío del equipo, que hacen perder el volumen original entero, la instantánea no ofrece ninguna protección. Con el ransomware ocurre algo parecido: la propia escritura de cifrado sí traslada al área de diferencias los bloques previos a la reescritura, pero en los ataques reales la instantánea suele perderse porque se elimina directamente o porque el área de diferencias se agota por la enorme cantidad de reescrituras, así que tampoco se puede confiar en ella. La propia documentación de Microsoft distingue ambos conceptos: la copia de seguridad es lo que se copia desde la instantánea a un medio como una cinta, y una vez hecha esa copia la instantánea en sí puede eliminarse. La instantánea es «un punto de quietud para tomar una copia de seguridad» y «un medio de restauración rápida ante errores menores», no un sustituto de la copia de seguridad en otro medio y en otra ubicación.

Quiero que mi aplicación empresarial propia copie archivos en uso: ¿debería usar VSS?

Lo realista es buscar primero una vía que no necesite VSS. El solicitante de VSS hay que escribirlo con la API nativa basada en COM (como IVssBackupComponents), y como no existe un envoltorio oficial para .NET, incorporarlo a una aplicación propia supone una tarea considerable. Si el requisito es solo «poder leer, en algún momento, un archivo que otro proceso está escribiendo», basta con reintentos; si es «el uso compartido de lectura está permitido», basta con abrir con el mismo modo de uso compartido. Si la aplicación se puede detener un momento, copiar en una ventana de mantenimiento es lo más seguro. VSS solo entra en juego cuando el requisito es «duplicar en un estado consistente todo el conjunto de datos de una aplicación que no se puede detener», y aun en ese caso conviene evaluar antes un software de backup compatible con VSS o un script de DiskShadow, antes que una implementación propia.

En vssadmin list writers un escritor aparece en estado de error. ¿Qué debo hacer?

Lo básico es investigarlo como un problema de la aplicación responsable de ese escritor. vssadmin list writers muestra la lista de escritores registrados junto con su estado, así que primero hay que identificar cuál está fallando. Como los escritores los proporcionan aplicaciones como SQL Server o componentes de Windows (como el registro), la causa del error casi siempre está en el estado del servicio de la aplicación responsable o en los errores registrados en el visor de eventos de aplicación o de sistema, más que en el propio VSS. Conviene reiniciar el servicio correspondiente y acotar las condiciones de reproducción; si el problema no se resuelve, hay que consultar la información de soporte de esa aplicación. Este mismo procedimiento sirve como primer diagnóstico cuando el software de backup falla por un error de VSS.

Una instantánea desapareció sin que nadie se diera cuenta. ¿Por qué?

La causa más habitual es la falta de espacio en el área de diferencias (el almacenamiento de instantáneas). Con el método copy-on-write, la primera vez que se reescribe cada bloque después de tomar la instantánea se guarda el contenido previo en el área de diferencias, así que cuanto más amplio es el rango reescrito, más se consume esa área. Al llegar al límite asignado, Windows elimina las instantáneas más antiguas, en orden, para liberar espacio. Como no se notifica nada al usuario y la instantánea desaparece en silencio, es habitual descubrirlo cuando se cree que se puede volver a la versión de la semana pasada con «versiones anteriores» y resulta que ya no está (en el registro del sistema quedan eventos con origen volsnap, como el evento 25, así que vigilarlos permite darse cuenta a tiempo). Conviene revisar el uso y el límite con vssadmin list shadowstorage y, si hace falta, ampliar el límite con vssadmin resize shadowstorage. Eso sí, tenga en cuenta que cambiar el límite (en particular, reducirlo) puede provocar por sí mismo la pérdida de instantáneas.

¿Qué relación hay entre «Versiones anteriores» del Explorador de archivos y VSS?

«Versiones anteriores» es una de las puertas de entrada para recuperar archivos pasados que están dentro de las instantáneas creadas por VSS. En un servidor de archivos, al habilitar «Instantáneas de carpetas compartidas» (Shadow Copies of Shared Folders) se crean instantáneas periódicamente, y el usuario puede hacer clic con el botón derecho sobre un archivo de la carpeta compartida y restaurarlo por sí mismo desde «Versiones anteriores». La ventaja es poder corregir un borrado o una sobrescritura accidental sin necesidad de recurrir al administrador. Sin embargo, como en el fondo se trata de instantáneas, hay un límite de generaciones que se pueden conservar, y si el área de diferencias se queda corta, las generaciones más antiguas desaparecen. Como se explica en el cuerpo del artículo, «tener versiones anteriores» no equivale a «no necesitar copia de seguridad».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.