Puntos de restauración ausentes: la configuración que Windows sigue desactivando

Qué ocurre realmente cuando los puntos de restauración “desaparecen”

Los puntos de restauración de Windows se basan en el Servicio de Copias Shadow de Volumen (VSS). Restaurar sistema (la función con la que interactúas) es básicamente un consumidor de instantáneas VSS más un conjunto de seguimiento del estado del sistema: colmenas del registro, ciertos archivos del sistema, controladores y metadatos de configuración. No es una copia completa del sistema, no es una “imagen de disco” y definitivamente no es una máquina del tiempo que se burla del ransomware.

Entonces, ¿por qué desaparecen los puntos de restauración?

• Protección del sistema está realmente desactivada para la unidad del sistema, a menudo tras una actualización del SO, la aplicación de una política o una “optimización”.
• La cuota de espacio en disco es demasiado pequeña. Los puntos de restauración se almacenan en el área de “shadow storage”. Cuando se llena, Windows elimina puntos antiguos. Si la cuota es ridículamente pequeña, obtienes una puerta giratoria: se crean puntos y se expulsan al instante.
• VSS está enfermo (escritores atascados, servicios deshabilitados, errores de proveedor). Los puntos de restauración fallan silenciosamente o no dejan nada utilizable.
• Herramientas de limpieza los purgan: Liberador de espacio en disco, Storage Sense, “limpiadores” de terceros, algunas suites de mantenimiento OEM.
• Las copias shadow se eliminan por acciones administrativas (incluidos scripts), o por ciertos flujos de trabajo de actualización/upgrade de funciones.

Lo que hace esto tan frustrante es que Windows puede parecer correcto hasta que necesites revertir. Los puntos de restauración son como los extintores: nadie presupuestó para ellos hasta que la cocina está en llamas.

Una cita para mantenernos honestos: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. La gente de operaciones no inventó la frase, pero nos la tatuamos en el alma.

Además, aquí va tu primer chiste: System Restore es el paracaídas que solo notas después de haber saltado.

Datos interesantes y contexto histórico (sí, importa)

1. System Restore debutó en Windows ME (2000) y luego se popularizó en Windows XP. Fue controvertido porque las versiones tempranas podían inflar el uso de disco y a veces restauraban malware junto con el sistema.
2. VSS llegó en la era Windows XP/Server 2003 como una infraestructura estándar y se convirtió en la capa base para copias de seguridad, puntos de restauración y “Versiones anteriores”.
3. Los puntos de restauración no son lo mismo que “Versiones anteriores”, aunque ambos usan copias shadow. Versiones anteriores depende de que existan copias shadow para archivos; System Restore depende de que la protección esté activada y de que el SO decida qué rastrear.
4. Las actualizaciones de función de Windows (saltos de versión) suelen restablecer o desactivar la protección en algunos sistemas, especialmente cuando cambian los diseños de disco o la identificación del volumen “sistema” se vuelve ambigua.
5. El shadow storage es por volumen, y puede ubicarse en un volumen distinto. Eso es poderoso—y también fuente de confusión cuando “lo activé en C: ¿por qué las instantáneas desaparecieron?”.
6. VSS usa “writers” (componentes que preparan datos para la instantánea). Cuando los writers se atascan, puedes tener una PC funcional que se niega a crear instantáneas de forma fiable.
7. Algunas imágenes empresariales desactivan intencionalmente System Restore para reducir la variabilidad de soporte o porque confían en imágenes/MDM completos. Si esa política se filtra a máquinas no gestionadas, te llevas una sorpresa.
8. El Liberador de espacio históricamente ofrecía opciones que pueden eliminar puntos de restauración (dejando solo el más reciente). La gente pulsa “Limpiar archivos del sistema” como si fuera dinero gratis.
9. System Restore no protege archivos de usuario como muchos suponen. Está pensado para recuperar el estado del sistema, no para recuperar tu informe que sobrescribiste a las 2 a. m.

Guía rápida de diagnóstico

Esta es la secuencia “no te vuelvas loco”. Síguela en orden. Encuentra el cuello de botella rápido y evita perseguir fantasmas.

1) Confirma el estado de Protección del sistema para el volumen del SO

Si está Desactivada, todo lo demás es una misión secundaria. Actívala y pon una cuota sensata.

2) Revisa la cuota y el uso del shadow storage

Si el tamaño máximo es pequeño o está en 0/“sin límite pero efectivamente hambriento”, los puntos de restauración van a rotar o desaparecer.

3) Comprueba la salud de VSS (writers + servicios)

Writers en estado de error o servicios deshabilitados significan que no se crearán instantáneas aunque la interfaz diga que debería funcionar.

4) Busca comportamientos de eliminación: limpieza, políticas, scripts

Storage Sense, tareas de limpieza, herramientas “optimizadoras” y algunos scripts empresariales borran rutinariamente las copias shadow para recuperar espacio.

5) Correlaciona con eventos

VSS y System Restore registran sus quejas. El registro de eventos es donde Windows admite lo que hizo.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto. Cada una incluye: comando, salida de ejemplo, qué significa y qué hacer a continuación.

Task 1 — Listar puntos de restauración existentes (si los hay)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerRestorePoint | Select-Object SequenceNumber, Description, CreationTime | Format-Table -Auto"
SequenceNumber Description                     CreationTime
-------------- -----------                     ------------
           132 Windows Update                  1/31/2026 2:14:07 AM
           131 Installed NVIDIA Graphics Driver 1/30/2026 6:02:33 PM

Qué significa: Si esto devuelve filas, System Restore tiene al menos algo de metadatos. Si da error (“Cannot find path” o “System Restore is disabled”), eso es una pista.

Decisión: ¿No hay puntos listados? Pasa a las comprobaciones de Protección del sistema y VSS. Algunos sistemas tienen instantáneas VSS sin puntos de restauración de SR; no asumas que son equivalentes.

Task 2 — Comprobar si System Restore está deshabilitado por claves de registro de política

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore' -ErrorAction SilentlyContinue | Format-List"
DisableConfig : 1
DisableSR     : 1
PSPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore

Qué significa: DisableSR=1 indica que System Restore está deshabilitado por política. Esto es común en entornos unidos a dominio o después de scripts de “endurecimiento”.

Decisión: Si existen estas claves, no lo “arreglas” desde la interfaz. Corrige la política (GPO/MDM/baseline) o elimina la clave si procede y está autorizado.

Task 3 — Comprobar la configuración de System Protection vía WMI (revisión rápida)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root/default -ClassName SystemRestoreConfig | Select-Object -Property * | Format-List"
RPLifeInterval : 7776000
DiskPercent    : 3
PSComputerName :

Qué significa: Esto muestra la configuración de System Restore, como el porcentaje de disco reservado. DiskPercent muy bajo es una señal de alarma en sistemas modernos.

Decisión: Si DiskPercent es 1–3% en una estación de trabajo ocupada, súbelo. Si la clase no devuelve datos, SR puede estar deshabilitado o roto.

Task 4 — Listar copias shadow presentes (instantáneas VSS)

cr0x@server:~$ vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Contents of shadow copy set ID: {6f5d1fe9-8d8d-4f1c-9b3a-6efaf7fadc1b}
   Contained 1 shadow copies at creation time: 2/3/2026 9:12:21 AM
      Shadow Copy ID: {c5e65b1e-0cbd-4f2d-96c2-4a0b9a3d6d62}
         Original Volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12
         Originating Machine: DESKTOP-OPS1
         Service Machine: DESKTOP-OPS1
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessible
         Attributes: Persistent, Client-accessible, No auto release, Differential

Qué significa: Si existen shadows pero no hay puntos de restauración, puede que VSS esté siendo usado por backups/Versiones anteriores pero System Restore esté deshabilitado. O la metadata de puntos de restauración falta.

Decisión: Si no hay sombras en absoluto, no las estás creando, se están eliminando o VSS está fallando. Prosigue con comprobaciones de cuota/almacenamiento y writers de VSS.

Task 5 — Inspeccionar uso y cuota del shadow storage (esto explica “desaparición”)

cr0x@server:~$ vssadmin list shadowstorage
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Shadow Copy Storage volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Used Shadow Copy Storage space: 1.421 GB (1%)
   Allocated Shadow Copy Storage space: 1.500 GB (1%)
   Maximum Shadow Copy Storage space: 1.500 GB (1%)

Qué significa: El tamaño máximo es 1.5GB. Eso es nada en una instalación moderna de Windows. Una sola actualización puede agotar eso.

Decisión: Aumenta la cuota. Si no puedes preservar espacio en C:, considera mover el shadow storage a otro volumen (con precaución).

Task 6 — Aumentar la cuota del shadow storage a un valor sensato

cr0x@server:~$ vssadmin resize shadowstorage /for=C: /on=C: /maxsize=15GB
Successfully resized the shadow copy storage association.

Qué significa: Has dado a VSS espacio para mantener múltiples puntos de restauración.

Decisión: Si el disco es pequeño (por ejemplo, 128GB), elige proporcionalmente (8–12GB). Si los endpoints son grandes y dependes de SR, 15–30GB es razonable.

Task 7 — Verificar que los servicios VSS estén en ejecución y no deshabilitados

cr0x@server:~$ powershell -NoProfile -Command "Get-Service VSS,swprv | Select-Object Name,Status,StartType | Format-Table -Auto"
Name  Status  StartType
----  ------  ---------
VSS   Running Manual
swprv Stopped Manual

Qué significa: VSS está en ejecución. El proveedor Microsoft Software Shadow Copy (swprv) está en Manual y detenido, lo cual es normal hasta que se necesita.

Decisión: Si alguno está Disabled, eso es un problema. Pónlo en Manual, inicia VSS y prueba de nuevo la creación de puntos de restauración.

Task 8 — Comprobar la salud de los writers de VSS (el detector de “¿por qué falla?”)

cr0x@server:~$ vssadmin list writers
Writer name: 'System Writer'
   Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Instance Id: {5d1aa4f8-8b6c-4a35-8571-34a13b2bfc4d}
   State: [1] Stable
   Last error: No error

Writer name: 'WMI Writer'
   Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
   Writer Instance Id: {0d54d70a-7f44-4af6-8a0f-778a85b54d1c}
   State: [9] Failed
   Last error: Timed out

Qué significa: Un writer ha fallado. Los puntos de restauración pueden fallar o quedar incompletos cuando writers críticos están rotos.

Decisión: Arregla el servicio subyacente de ese writer (a menudo problemas del repositorio WMI, timeouts de proveedor o servicios dependientes). Como mínimo, reinicia servicios y vuelve a comprobar. Si sigue fallando, no has “terminado” solo porque la interfaz diga “Activado”.

Task 9 — Revisar eventos de System Restore y VSS (deja de adivinar)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'; StartTime=(Get-Date).AddDays(-7)} | Select-Object TimeCreated,Id,LevelDisplayName,Message | Select-Object -First 5 | Format-List"
TimeCreated      : 1/31/2026 2:14:10 AM
Id               : 8193
LevelDisplayName : Error
Message          : Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance.  Error: [0x80040154]

TimeCreated      : 1/31/2026 2:14:08 AM
Id               : 12289
LevelDisplayName : Error
Message          : Volume Shadow Copy Service error: Error calling a routine on a Shadow Copy Provider.

Qué significa: 0x80040154 es “Clase no registrada” en términos COM. Eso suele apuntar a una registración de proveedor rota o componentes corruptos.

Decisión: Si ves errores repetidos de proveedor VSS, no solo amplíes cuotas. Repara la pila VSS (comprobaciones del almacén de componentes, limpieza de proveedores) y considera eliminar proveedores de terceros si existen.

Task 10 — Crear un punto de restauración manualmente y observar errores

cr0x@server:~$ powershell -NoProfile -Command "Checkpoint-Computer -Description 'Manual restore point for testing' -RestorePointType 'MODIFY_SETTINGS'"

Qué significa: La ausencia de salida suele indicar éxito. Si lanza una excepción (“System Restore is disabled” o “The restore point could not be created”), tienes una señal directa de fallo.

Decisión: Si la creación manual falla, estás ante un problema de configuración/política/salud de VSS, no de “Windows lo olvidó”. Vuelve a writers, servicios y claves de política.

Task 11 — Revisar tareas programadas que influyen en la creación de puntos

cr0x@server:~$ schtasks /Query /TN "\Microsoft\Windows\SystemRestore\SR" /V /FO LIST
Folder: \Microsoft\Windows\SystemRestore
HostName:                             DESKTOP-OPS1
TaskName:                             \Microsoft\Windows\SystemRestore\SR
Next Run Time:                        2/4/2026 12:00:00 AM
Status:                               Ready
Logon Mode:                           Interactive/Background
Last Run Time:                        2/3/2026 12:00:00 AM
Last Result:                          0x0
Author:                               Microsoft Corporation
Task To Run:                          %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation

Qué significa: La tarea existe y el último resultado es 0x0 (éxito). Si falta o falla, la creación automática puede no ocurrir.

Decisión: Si falta, aún puedes crear puntos manualmente, pero el comportamiento automático está roto. Si falla, investiga el historial de la tarea y los registros de eventos para saber por qué.

Task 12 — Comprobar espacio libre y si C: está bajo presión

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive C | Select-Object Name,Free,Used | Format-List"
Name : C
Free : 6829434880
Used : 243915735040

Qué significa: Unos 6.8GB libres. Eso es “una actualización acumulativa de Windows lejos de un mal día.” El espacio libre bajo dispara limpiezas agresivas y expulsión de instantáneas.

Decisión: Si el espacio libre es escaso, arréglalo primero: amplía la partición, desinstala bloatware, mueve datos o cambia la estrategia de retención. Sin espacio, no hay instantáneas.

Task 13 — Identificar proveedores VSS de terceros (fuente frecuente de rarezas)

cr0x@server:~$ vssadmin list providers
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Provider name: 'Microsoft Software Shadow Copy provider 1.0'
   Provider type: Software
   Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
   Version: 1.0.0.7

Qué significa: Solo está presente el proveedor de Microsoft. Bien. Si ves proveedores adicionales (agentes de backup, herramientas de almacenamiento), pueden romper VSS o cambiar la semántica de retención.

Decisión: Si hay un proveedor de terceros y ves errores VSS, coordina con el responsable de ese software. No lo arranques a ciegas en una flota de producción.

Task 14 — Revisar configuraciones de Storage Sense que pueden desencadenar limpieza

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy' -ErrorAction SilentlyContinue | Format-List"
01 : 1
04 : 1
08 : 1

Qué significa: Storage Sense está habilitado (01) y configurado para ciertos comportamientos de limpieza. Esto no dice directamente “eliminar puntos de restauración”, pero se correlaciona con una reclamación agresiva de espacio en sistemas con poca capacidad.

Decisión: Si los puntos de restauración desaparecen en “días de limpieza”, revisa Storage Sense y cualquier baseline empresarial de limpieza. Asegúrate de no barrer la red de seguridad para ahorrar unos gigabytes.

Causas raíz que hacen que Windows lo apague (o actúe como si lo hiciera)

1) Las actualizaciones de función restablecen el estado de protección

Las actualizaciones importantes de Windows no son gentiles. Reorganizan archivos del sistema, reescriben la configuración de arranque y a veces reinterpretan qué volumen es “sistema”. En ese proceso, System Protection puede quedar Off, o sus ajustes pueden volver a valores predeterminados. Si gestionas flotas, asume que esto ocurre ocasionalmente y verifica tras oleadas de actualización.

2) Group Policy / MDM baselines lo deshabilitan

Las empresas suelen desactivar System Restore porque prefieren imágenes estandarizadas y porque los puntos de restauración pueden complicar scripts de soporte. Eso puede ser racional—siempre que tengas una alternativa de rollback. El modo de fallo aparece cuando la política desactiva la función en máquinas que no tienen alternativa, como portátiles de ejecutivos o dispositivos de campo.

3) Las rutinas de “optimización” y limpieza eliminan copias shadow

Algunos trabajos de limpieza tratan las copias shadow como caché. No lo son. Son estado. Eliminarlas no es “mantenimiento”; es quitar la palanca de retroceso. Liberador de espacio y herramientas de terceros pueden eliminar todos los puntos de restauración salvo el más reciente, o borrar copias shadow por completo.

4) La presión de espacio en disco fuerza la expulsión

VSS tiene una cuota. Cuando la alcanzas, las instantáneas más antiguas se eliminan. Si tu cuota es pequeña, en la práctica tienes “puntos de restauración” por unos minutos. Si el disco está casi lleno, Windows también tomará decisiones despiadadas. Le importa más que el SO siga funcionando que los sentimientos de tu yo futuro.

5) Fallos de writers/proveedores VSS

La creación de puntos de restauración depende de una cadena de componentes: servicios, registraciones COM, writers y proveedores. Un writer roto puede atascar toda la operación de instantánea o crear puntos de restauración poco fiables que no se aplican.

Segundo (y último) chiste: Los errores de VSS son la forma que tiene Windows de decir “Lo intenté” mientras en realidad no lo intentó en absoluto.

Tres micro-historias corporativas desde el terreno

Micro-historia #1: El incidente causado por una suposición errónea

El entorno: una flota mixta de portátiles Windows 10 y Windows 11, más un puñado de estaciones de trabajo para CAD. Un equipo desplegó una actualización de controlador para una estación de acoplamiento. No era maliciosa. Solo… ambiciosa.

Al mediodía, los tickets de soporte se dispararon: monitores externos en negro, dispositivos USB desconectándose, máquinas congelándose intermitentemente. El ingeniero de guardia hizo lo que hace cualquier persona sensata: “No pasa nada, revertimos con puntos de restauración.” Excepto que los puntos de restauración faltaban en una gran parte de los equipos.

La suposición fue sutil: “Windows siempre mantiene puntos de restauración.” En realidad, System Protection se había desactivado meses antes en una baseline de “estandarización” pensada para máquinas de laboratorio que se reimaginaban semanalmente. Esa baseline se reutilizó luego para portátiles. Nadie lo notó porque todo funcionaba—hasta que no funcionó.

La solución no fue heroica. Revirtieron la política para la OU de portátiles, reactivaron la protección, establecieron una cuota que sobreviviera dos actualizaciones acumulativas y añadieron un paso de verificación posterior al cambio: confirmar que exista al menos un punto de restauración fresco en dispositivos de prueba antes del despliegue. La lección fue humillante: si un mecanismo de seguridad no se monitoriza explícitamente, no existe.

Micro-historia #2: La optimización que salió mal

Otra empresa, otra “necesidad de recuperar almacenamiento”. Los SSD se llenaban y alguien decidió desplegar un script de limpieza agresivo. Eliminó temporales, caches del navegador, descargas de actualizaciones antiguas y—porque parecía razonable en ese momento—copias shadow.

El script funcionó de maravilla. Los gráficos de espacio en disco subieron y todos aplaudieron. Dos semanas después, una mala actualización de Windows provocó problemas de arranque en un subconjunto de máquinas. Las opciones de recuperación se estrecharon rápido: las claves de BitLocker estaban disponibles, sí, pero los puntos de restauración hubieran sido el rollback más limpio para muchos sistemas.

Ya no estaban, porque el script las había estado borrando periódicamente. Peor aún, el script corría justo después del Patch Tuesday, que es cuando más necesitas que existan puntos de restauración. La optimización logró la métrica (espacio libre) saboteando el resultado (recuperación rápida).

La corrección fue tratar las copias shadow como capacidad protegida. Rediseñaron la política de limpieza para apuntar a áreas seguras conocidas y fijaron umbrales mínimos de espacio libre, pero nunca borrar copias shadow en masa. La falla no fue técnica. Fue una mala priorización.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Una organización financiera tenía una práctica anticuada: antes del cierre mensual, ejecutaban una “lista de comprobación de estabilidad” en estaciones críticas. Un ítem era dolorosamente aburrido: verificar que System Protection esté Activada para C: y que exista al menos un punto de restauración creado en los últimos siete días.

Durante una semana de cierre, una actualización de una aplicación de negocio llegó con un controlador de kernel. Provocó BSOD intermitentes en máquinas con cierto firmware de controlador de almacenamiento. No todas—solo las suficientes para ser costosas.

Como existían puntos de restauración y tenían suficiente cuota para sobrevivir la rotación, el equipo de escritorio revirtió los sistemas rápidamente, estabilizó operaciones y luego arregló la causa raíz (combinación firmware + controlador). No hubo una oleada de reimágenes de emergencia. No “envíes el portátil a TI y espera tres días.” Simple higiene que dio dividendos.

Si buscas una moraleja: la respuesta a incidentes llamativa es un impuesto. La preparación silenciosa es un dividendo.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “No se han creado puntos de restauración”

Causa raíz: Protección del sistema desactivada para C: (o el volumen del SO).

Solución: Activa Protección del sistema para el volumen correcto y crea un punto de restauración de prueba. Confirma que aparece con Get-ComputerRestorePoint.

2) Síntoma: Los puntos existen brevemente y luego desaparecen en un día

Causa raíz: Tamaño máximo del shadow storage muy pequeño; VSS expulsa puntos antiguos de inmediato.

Solución: Aumenta la cuota (vssadmin resize shadowstorage). Asegura que el espacio libre apoye la cuota.

3) Síntoma: La interfaz muestra protección “Activada”, pero la creación falla

Causa raíz: Fallos de writers VSS, problemas con proveedores o servicios deshabilitados.

Solución: Comprueba vssadmin list writers, revisa logs de VSS, repara servicios/componentes subyacentes. Luego reintenta Checkpoint-Computer.

4) Síntoma: Los puntos desaparecieron justo después de ejecutar Liberador de espacio

Causa raíz: La limpieza eliminó puntos de restauración o redujo a solo el más reciente.

Solución: Ajusta la práctica de limpieza. Trata los puntos de restauración como capacidad protegida. Aumenta la cuota para que la operación normal no te obligue a jugar a la ruleta de limpieza.

5) Síntoma: Los puntos desaparecieron tras una actualización de función de Windows

Causa raíz: La actualización restableció ajustes de protección o invalidó instantáneas antiguas.

Solución: Verificación post-actualización: asegúrate de que la protección esté activada y crea un nuevo punto de restauración. No esperes que los antiguos sobrevivan a grandes actualizaciones.

6) Síntoma: En máquinas de dominio, la Protección del sistema se vuelve a desactivar

Causa raíz: Aplicación de políticas mediante claves de registro o GPO de dominio.

Solución: Corrige la baseline. Deja de luchar contra la política localmente; la política gana en cada ciclo de actualización.

7) Síntoma: Versiones anteriores funciona, pero System Restore no (o viceversa)

Causa raíz: Consumidores diferentes de VSS. Uno puede estar habilitado mientras el otro está efectivamente deshabilitado.

Solución: Comprueba ambos: lista de puntos de restauración y vssadmin list shadows. Configura explícitamente System Protection para el volumen del sistema.

8) Síntoma: Los puntos fallan en portátiles más que en sobremesas

Causa raíz: Poco espacio en disco, transiciones de energía frecuentes y políticas de limpieza agresivas afectan más a dispositivos móviles.

Solución: Aumenta la cuota, exige espacio libre mínimo y no programes limpiezas justo después de desplegar parches.

Listas de verificación / plan paso a paso

Checklist A — Una máquina, ahora mismo (15–30 minutos)

1. Confirma el volumen del SO: Normalmente C:, pero verifica si Windows está instalado en otro sitio.
2. Revisa la lista de puntos de restauración con Get-ComputerRestorePoint. Si está vacía, continúa.
3. Comprueba las claves de política bajo HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore.
4. Revisa la cuota del shadow storage usando vssadmin list shadowstorage.
5. Redimensiona la cuota a un número sensato (8–30GB dependiendo del tamaño del disco y la tasa de cambios).
6. Comprueba los writers de VSS con vssadmin list writers.
7. Revisa los logs de VSS de la última semana. Busca IDs repetidos como 8193, 12289, 13.
8. Crea un punto de restauración manual con Checkpoint-Computer.
9. Vuelve a listar los puntos de restauración. Si el nuevo existe, has restaurado la canalización.

Checklist B — Higiene de flota (lo que debes estandarizar)

1. Define una política de retención para puntos de restauración: objetivo de cuota y frescura mínima esperada (p. ej., al menos un punto en los últimos 7 días en endpoints que lo permitan).
2. Establece cuotas coherentes según tramos de tamaño de disco. Cuotas diminutas provocan rotación y falsa confianza.
3. Evita la eliminación de copias shadow en baselines de limpieza a menos que tengas un mecanismo de rollback mejor y estés seguro.
4. Verificación post-actualización: tras las actualizaciones de función, confirma que la protección está activada y crea un nuevo punto de restauración.
5. Monitoriza la salud de los writers VSS en máquinas representativas; un writer roto suele anticipar fallos de backup.
6. Educa los playbooks del helpdesk: “No hay puntos de restauración” es una condición diagnosable, no una maldición mística.

Checklist C — Cuando necesitas que los rollbacks funcionen sí o sí

1. No dependas solo de System Restore como red de seguridad. Combínalo con imaging o una estrategia de backups real cuando sea posible.
2. Antes de cambios riesgosos (despliegues de controladores, agentes de seguridad, componentes de kernel): crea un punto de restauración y verifica que exista.
3. Después de cambios riesgosos: confirma que todavía tienes puntos de restauración y que el shadow storage no está saturado.
4. Mantén margen de espacio libre. Si C: queda por debajo de 10–15GB libres en builds modernos, invitas al caos.

Preguntas frecuentes

1) ¿Por qué la Protección del sistema sigue desactivándose?

Lo más común: políticas (GPO/MDM), actualizaciones de función que restablecen ajustes o herramientas de “optimización” de terceros. A veces no está “desactivada”, está efectivamente inútil por una cuota minúscula.

2) ¿Son los puntos de restauración lo mismo que copias de seguridad?

No. Los puntos de restauración están diseñados para rollback del estado del sistema (controladores, registro, archivos del sistema). No son un método fiable para recuperar datos de usuario o un estado completo del disco.

3) ¿Cuánto espacio debería asignar para puntos de restauración?

Suficiente para sobrevivir la rotación normal: actualizaciones, instalaciones de controladores y cambios de aplicaciones. En una unidad de sistema de 256GB+, 15–30GB suele ser sensato para endpoints que dependen de SR. El número correcto depende de la tasa de cambios y del espacio libre.

4) ¿Por qué desaparecen los puntos de restauración tras una actualización de Windows?

Algunas actualizaciones crean puntos de restauración; otras desencadenan limpiezas o consumen tanto espacio shadow que se expulsan puntos antiguos. Las actualizaciones de función pueden invalidar o eliminar instantáneas antiguas por completo.

5) ¿Pueden Liberador de espacio o Storage Sense borrar puntos de restauración?

Sí. Liberador de espacio puede eliminar puntos de restauración (a menudo dejando solo el más reciente). Storage Sense y comportamientos por falta de espacio pueden causar expulsión indirecta al presionar el uso de disco.

6) Tengo sombras VSS, pero System Restore no muestra nada. ¿Por qué?

Las sombras VSS pueden ser creadas por backups o “Versiones anteriores” sin que System Restore esté habilitado. System Restore necesita que System Protection esté activado y mantiene metadata de puntos de restauración por separado.

7) ¿Es seguro mover el shadow storage a otra unidad?

Puedes, pero añade complejidad. Si el volumen secundario es extraíble, inestable o se usa intensamente, puedes trocar un modo de fallo por otro. Si lo haces, monitorízalo y documenta el cambio.

8) ¿Qué significa cuando los writers VSS están en estado “Failed”?

Significa que uno de los componentes que debe poner en pausa los datos para las instantáneas está poco saludable. Los puntos de restauración y las copias de seguridad pueden fallar o quedar incompletos. Repara el servicio/componente subyacente y vuelve a comprobar el estado del writer.

9) ¿Deben las empresas desactivar System Restore?

Sólo si tienen una historia de rollback mejor que funcione en endpoints reales bajo presión real. Desactivarlo sin alternativa es como quitar cinturones de seguridad porque prefieres airbags.

10) ¿Cuál es la mejor prueba para confirmar que funciona?

Crea un punto de restauración manual con Checkpoint-Computer, confirma que existe con Get-ComputerRestorePoint y verifica que el shadow storage tenga suficiente margen.

Siguientes pasos prácticos

Si faltan puntos de restauración, deja de tratarlo como mala suerte. Casi siempre es configuración, cuota o salud de VSS.

1. Comprueba Protección del sistema para el volumen del SO y confirma que la política no lo deshabilita.
2. Arregla la cuota del shadow storage para que los puntos de restauración sobrevivan la rotación normal de Windows.
3. Valida los writers VSS y los logs de eventos; una pila VSS rota sabotea puntos de restauración y backups por igual.
4. Investiga comportamientos de limpieza que eliminan copias shadow, especialmente justo después de parchear.
5. Institucionaliza una verificación aburrida: “¿Tenemos un punto de restauración reciente?” Inclúyela en tu playbook de cambios.

Los puntos de restauración no son glamorosos. Ni siquiera Windows los quiere mucho. Pero cuando los necesitas, los necesitas. Haz que sean aburridamente fiables.