Las copias de seguridad tienden a parecer saludables. Los paneles permanecen en verde, los trabajos “suceden” y todos duermen tranquilos—hasta el día en que necesita
una restauración y descubre que ha estado acumulando costosa y bellamente comprimida decepción.
Una prueba de restauración real no es un ejercicio para marcar casillas. Es un simulacro repetible e instrumentado que demuestra que puede reconstruir lo que realmente ejecuta: inicios de sesión de dominio,
bases de datos, aplicaciones, permisos, certificados, cargadores de arranque y esa tarea programada rara que solo existe en un servidor porque “era urgente”.
Tabla de contenidos
- Qué falla realmente durante las restauraciones (y por qué no lo ves)
- Hechos interesantes y breve historia de las restauraciones en Windows
- Qué significa una “prueba de restauración real” en producción
- Guía de diagnóstico rápido (encuentra el cuello de botella rápido)
- Tareas prácticas: 12+ comandos, salidas y decisiones
- Tres microhistorias corporativas desde las trincheras de la restauración
- Errores comunes: síntoma → causa raíz → solución
- Listas de verificación / plan paso a paso que puede adoptar
- Preguntas frecuentes
- Conclusión: próximos pasos que cambian resultados
Qué falla realmente durante las restauraciones (y por qué no lo ves)
Los productos de backup son buenos informando si un trabajo terminó. Son mucho peores para decir si el sistema restaurado arrancará, si AD aceptará
inicios de sesión, si SQL montará la base de datos, si su aplicación podrá descifrar sus secretos o si los permisos de archivos seguirán coincidiendo con la realidad.
La mayoría de la “verificación de backups” solo verifica el archivo de copia, no su capacidad para ejecutar el servicio de nuevo.
Las restauraciones fallan en el peor momento porque las fallas son latentes. No aparecen cuando crea una copia. Aparecen cuando intenta
restaurar en un entorno nuevo, con controladores diferentes, almacenamiento distinto, modo de firmware distinto (UEFI vs BIOS), NICs distintos, DNS distinto y un
controlador de dominio que de repente es lo más antiguo de la sala.
Modos de fallo de restauración que se esconden detrás de marcas verdes
- “Éxito” de VSS con inconsistencia de la aplicación. VSS puede completarse mientras un escritor de la aplicación aún está volcándose, o el escritor está en estado fallido. Obtiene un blob consistente con crash cuando necesitaba una restauración consistente con la aplicación.
- Desajuste de configuración de arranque. Restaurar un sistema UEFI/GPT sobre un objetivo que espera BIOS/MBR (o viceversa) es clásico. No es glamoroso. Arruina fines de semana.
- Restauraciones dependientes de credenciales. Las copias cifradas requieren claves; los servidores unidos al dominio requieren servicios de dominio; las claves privadas de certificados deben existir donde la aplicación las espera.
- Colisiones de identidad. Restaurar un controlador de dominio, o un servidor con el mismo hostname/SID en una red activa, puede causar daños extraños y sutiles.
- Sorpresas de rendimiento de almacenamiento. La velocidad de restauración está limitada por IOPS de lectura del repo, IOPS de escritura en el objetivo, red y el motor de restauración. Su ventana de backup no midió ese camino.
- “Restaurado” pero datos inutilizables. La base de datos está presente pero no monta; los archivos están pero los permisos/ACLs son incorrectos; faltan shares; las tareas programadas no regresaron.
Una prueba de restauración debe validar el servicio y el plano de control (autenticación, DNS, hora, certificados) porque normalmente son lo primero que pierde.
Un montón de archivos no es un servicio.
Primera broma corta: Las copias de seguridad son como paracaídas—si solo las pruebas en teoría, tarde o temprano conocerás la gravedad en persona.
Hechos interesantes y breve historia de las restauraciones en Windows
No necesita trivia para restaurar un servidor, pero la historia explica por qué los ecosistemas de restauración de Windows se comportan como lo hacen. Aquí hay hechos concretos que importan en
operaciones reales:
- NTBackup (era Windows 2000/2003) popularizó el backup a nivel de archivos más el “System State” como concepto separado; enseñó a los administradores a tratar los metadatos del SO como especiales y frágiles.
- VSS (Volume Shadow Copy Service) llegó para coordinar snapshots consistentes entre aplicaciones; cuando funciona, es magia, y cuando no, falla de maneras que suenan como poesía escrita por un código de error.
- Las restauraciones de System State para Active Directory han tenido reglas estrictas (autoritativo vs no autoritativo). Malinterpretar esas reglas puede resucitar objetos eliminados o reintroducir contraseñas antiguas.
- USN rollback se volvió un modo de fallo notorio en AD al restaurar DCs desde snapshots incorrectamente; empujó a la industria hacia patrones de restauración de AD más seguros y mejor integración con virtualización.
- Windows Server Backup (wbadmin) construido alrededor de backup a nivel de bloques y VSS; es engañosamente capaz pero intolerante a diseños de almacenamiento desajustados y a entornos de recuperación faltantes.
- La adopción de UEFI cambió la mecánica de restauración: la partición EFI, Secure Boot y los layouts GPT hicieron que “simplemente copiar el disco” fuera más complicado.
- ReFS y dedup alteraron el diseño de repositorios: excelentes para la capacidad, ocasionalmente problemáticos para el rendimiento y cadenas de recuperación si su diseño depende demasiado de la optimización.
- Los checkpoints de Hyper-V no son backups, pero la gente sigue usándolos como si lo fueran. Esa confusión ha alimentado muchos incidentes de “pero ayer estaba ahí”.
- La era del ransomware obligó a que las pruebas de restauración incluyan supuestos de “sala limpia”: su servidor de backups podría estar comprometido y sus credenciales podrían ser inválidas.
Qué significa una “prueba de restauración real” en producción
Una prueba de restauración real es un simulacro repetible que restaura un conjunto representativo de sistemas y demuestra que puede proveer el servicio de nuevo dentro de un tiempo conocido.
No es una celebración única de “restauramos un archivo una vez”.
Defina su prueba como lo haría un SRE
- Alcance: qué capas se prueban (DC, servidor de archivos, SQL, servidor de aplicaciones, imágenes de estaciones críticas, hipervisores).
- Criterios de éxito: comprobaciones medibles, no sensaciones: “DC arranca y pasa salud de replicación”, “base de datos SQL se adjunta y pasa DBCC CHECKDB”, “la app responde a una transacción sintética”.
- Objetivos de tiempo: RTO (cuánto hasta servicio) y RPO (cuánta pérdida de datos). Si nunca mide el tiempo de restauración, no tiene un RTO; tiene un deseo.
- Modelo de aislamiento: red sandbox, laboratorio desconectado o VLAN aislada similar a producción. Las pruebas de restauración no deben colisionar con identidades de producción.
- Evidencia: logs, capturas de pantalla si hace falta, pero mejor: salidas de comandos capturadas en su repositorio de runbooks.
- Cadencia: mensual para sistemas críticos, trimestral para el resto y después de cambios importantes (nuevo repo de backup, nuevo cifrado, nuevo build del SO, nuevo hipervisor).
Tipos de pruebas de restauración (y qué prueban realmente)
- Prueba de restauración a nivel de archivos: demuestra que puede recuperar un archivo. No demuestra que pueda ejecutar el servicio.
- Restauración de ítem de aplicación (SQL/Exchange/objetos AD): demuestra procesamiento consciente de la app y permisos. Aun así puede no probar recuperación completa del servicio.
- Restauración de VM a red aislada: demuestra arranque y salud básica del servicio con menos drama de hardware.
- Restauración bare-metal (BMR): demuestra todo lo feo: modo de arranque, controladores, controlador de almacenamiento, NIC y medios de recuperación. Aquí vive la verdad.
- Prueba de réplica/failover: demuestra que puede levantar copias pre-staged, pero puede ocultar problemas de consistencia de datos si nunca valida las aplicaciones.
Una cita, porque sigue siendo la única mentalidad que funciona:
La esperanza no es una estrategia.
—General Gordon R. Sullivan
Guía de diagnóstico rápido (encuentra el cuello de botella rápido)
Cuando las restauraciones son lentas o fallan, puede perder horas debatiendo el producto de backup. No lo haga. Haga un triage del camino: origen (repo) → red → almacenamiento objetivo →
validación de arranque/so. Aquí está el orden que encuentra el cuello de botella más rápido.
Primero: ¿la cadena de backup y los metadatos están sanos?
- ¿El punto de restauración está realmente disponible y no ha expirado, sido podado o es sintético?
- ¿La clave/credencial de cifrado es accesible?
- Para backups app-aware: ¿los escritores VSS estaban saludables al momento del backup?
- ¿Alguna alarma de salud del repo (corrupción del filesystem, problemas de dedup, conflictos de retención u objeto bloqueado)?
Segundo: ¿puede leer lo suficientemente rápido desde el repositorio?
- Mida throughput de disco y latencia en el repo durante la restauración.
- Revise cuellos de botella de CPU por compresión/cifrado durante la restauración.
- Verifique que no esté restaurando desde una “capa de capacidad” o almacenamiento frío que olvidó que era lento.
Tercero: ¿puede escribir lo suficientemente rápido al objetivo?
- IOPS de almacenamiento objetivo y profundidad de cola: las restauraciones son grandes flujos secuenciales con picos de escrituras de metadatos.
- Los destinos thin-provisioned pueden quedarse bloqueados cuando alcanzan límites de asignación.
- Antivirus y EDR pueden castigar las restauraciones escaneando cada bloque al aterrizar.
Cuarto: si arranca, ¿está sano?
- Sincronización de tiempo, DNS, confianza de dominio, cuentas de servicio, certificados.
- Comprobaciones de consistencia de bases de datos y reproducción de logs.
- Pruebas de humo de la aplicación y transacciones sintéticas.
Quinto: solo entonces culpe al producto de backup
El software de backup puede tener bugs. Pero la mayoría del dolor de restauración es desajuste del entorno, prerequisitos faltantes o un camino de almacenamiento que nunca se probó bajo presión.
Tareas prácticas: 12+ comandos, salidas y decisiones
Estas son comprobaciones prácticas que puede ejecutar en un laboratorio de restauración o durante un incidente. Los comandos se muestran desde un host Linux jump porque así muchos equipos
automatizan la validación de restauración y recopilan evidencia. Las comprobaciones del lado Windows se ejecutan vía WinRM usando evil-winrm o PowerShell remoto; la
lógica es la misma si las ejecuta localmente.
Task 1: Confirmar que está restaurando la identidad correcta del host (evite colisiones)
cr0x@server:~$ evil-winrm -i 192.168.50.21 -u restorelab\\admin -p 'REDACTED' -s ./ps -c "hostname; whoami; (Get-ItemProperty 'HKLM:\\SOFTWARE\\Microsoft\\Cryptography').MachineGuid"
WIN-RESTORE-DC01
restorelab\admin
d1b7f2a1-3c9a-4c1e-9bde-1e2c7c0c9c6a
Qué significa la salida: Tiene el hostname, el contexto de seguridad y MachineGuid. Si esto coincide con producción para algo que debería estar aislado, deténgase.
Decisión: Si está restaurando un DC o cualquier servidor que se unirá a una red, cambie el hostname o aisle la VLAN antes del primer arranque.
Task 2: Comprobar salud de los escritores VSS (el éxito de restauración depende del estado en backup)
cr0x@server:~$ evil-winrm -i 192.168.50.22 -u restorelab\\admin -p 'REDACTED' -c "vssadmin list writers"
Writer name: 'SqlServerWriter'
State: [1] Stable
Last error: No error
Writer name: 'System Writer'
State: [1] Stable
Last error: No error
Qué significa la salida: Los writers están estables. Si ve “Retryable error” o “Non-retryable error”, su backup “exitoso” puede ser crash-consistent.
Decisión: Si los writers no están estables, arregle el sistema origen y ejecute de nuevo un backup app-aware antes de confiar en restauraciones para esa carga.
Task 3: Detectar si el sistema restaurado es UEFI o BIOS (el modo de arranque importa)
cr0x@server:~$ evil-winrm -i 192.168.50.22 -u restorelab\\admin -p 'REDACTED' -c "bcdedit | findstr /i path"
path \EFI\Microsoft\Boot\bootmgfw.efi
Qué significa la salida: Está arrancando UEFI. Si su objetivo BMR es solo BIOS, obtendrá fallos de arranque.
Decisión: Haga coincidir el modo de firmware en el objetivo de restauración. No “lo resolverá más tarde” a las 2 a.m.
Task 4: Verificar el esquema de particiones del disco (EFI, MSR, OS) después de la restauración
cr0x@server:~$ evil-winrm -i 192.168.50.22 -u restorelab\\admin -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-Disk | Get-Partition | Format-Table -AutoSize\""
DiskNumber PartitionNumber DriveLetter Offset Size Type
---------- --------------- ---------- ------ ---- ----
0 1 - 1MB 100MB System
0 2 - 101MB 16MB Reserved
0 3 C 117MB 200GB Basic
0 4 - 200GB 900MB Recovery
Qué significa la salida: La partición del sistema EFI existe, MSR existe, la partición OS existe. La ausencia de la partición “System” es una señal de alarma.
Decisión: Si falta EFI/System, repare la configuración de arranque antes de perder tiempo depurando “Windows no arranca”.
Task 5: Comprobar si el Entorno de Recuperación de Windows está presente (reparaciones futuras dependen de ello)
cr0x@server:~$ evil-winrm -i 192.168.50.22 -u restorelab\\admin -p 'REDACTED' -c "reagentc /info"
Windows Recovery Environment (Windows RE) and system reset configuration
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Qué significa la salida: WinRE está habilitado. Si está deshabilitado o falta, algunas rutas de recuperación se vuelven incómodas.
Decisión: Para imágenes gold y playbooks BMR, asegure que WinRE esté habilitado tras la restauración en su estándar de laboratorio.
Task 6: Confirmar sincronización de tiempo y sensatez del reloj (Kerberos castigará)
cr0x@server:~$ evil-winrm -i 192.168.50.21 -u restorelab\\admin -p 'REDACTED' -c "w32tm /query /status"
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Last Successful Sync Time: 2/4/2026 1:10:12 AM
Source: time.restorelab.local
Qué significa la salida: El DC (o servidor) está sincronizado y dentro de un stratum razonable. Un reloj incorrecto rompe la autenticación de dominio y TLS.
Decisión: Arregle la hora antes de depurar “login failed” y errores de “certificate not yet valid”.
Task 7: Validar resolución DNS dentro de la red de restauración (las apps asumen DNS)
cr0x@server:~$ evil-winrm -i 192.168.50.23 -u restorelab\\admin -p 'REDACTED' -c "nslookup dc01.restorelab.local"
Server: dc01.restorelab.local
Address: 192.168.50.21
Name: dc01.restorelab.local
Address: 192.168.50.21
Qué significa la salida: DNS funciona y apunta a su DC de laboratorio. Si apunta a producción, está a punto de tener un mal día.
Decisión: Bloquee la VLAN de restauración al DNS de laboratorio. Sin excepciones. El DNS split-brain es como invocar fantasmas.
Task 8: Comprobar salud de AD (validación de DC restaurado, no solo arranque)
cr0x@server:~$ evil-winrm -i 192.168.50.21 -u restorelab\\admin -p 'REDACTED' -c "dcdiag /q"
Qué significa la salida: Sin salida significa que dcdiag no encontró errores. La salida indica fallos (replicación, DNS, servicios).
Decisión: Si dcdiag reporta problemas, deténgase y arregle AD antes de restaurar servidores miembros que dependen de él.
Task 9: Validar SYSVOL y shares netlogon (los clientes los necesitan)
cr0x@server:~$ evil-winrm -i 192.168.50.21 -u restorelab\\admin -p 'REDACTED' -c "net share"
Share name Resource Remark
----------------------------------------------------
NETLOGON C:\Windows\SYSVOL\sysvol\restorelab.local\SCRIPTS
SYSVOL C:\Windows\SYSVOL\sysvol
Qué significa la salida: SYSVOL/NETLOGON existen. Las shares ausentes a menudo significan que SYSVOL no se inicializó o DFSR está roto.
Decisión: No proceda con afirmaciones de “dominio restaurado” hasta que estas existan y sean accesibles.
Task 10: Prueba de restauración de SQL: la base de datos se adjunta y es consistente
cr0x@server:~$ evil-winrm -i 192.168.50.30 -u restorelab\\admin -p 'REDACTED' -c "sqlcmd -S localhost -E -Q \"SELECT name,state_desc FROM sys.databases\""
name state_desc
master ONLINE
model ONLINE
msdb ONLINE
AppDB ONLINE
Qué significa la salida: La base de datos está online. Pero “online” aún puede significar “silenciosamente corrupta”.
Decisión: Ejecute una comprobación de consistencia para al menos una base representativa por cada simulacro de restauración.
cr0x@server:~$ evil-winrm -i 192.168.50.30 -u restorelab\\admin -p 'REDACTED' -c "sqlcmd -S localhost -E -Q \"DBCC CHECKDB('AppDB') WITH NO_INFOMSGS\""
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Qué significa la salida: No imprimir errores es lo que desea. Si hay errores, su backup puede ser inconsistente o la ruta de restauración rompió algo.
Decisión: Si CHECKDB falla, clasifíquelo como una prueba de restauración fallida, no como “un problema de SQL”.
Task 11: Validar servicios de Windows que importan (las restauraciones suelen olvidar dependencias)
cr0x@server:~$ evil-winrm -i 192.168.50.23 -u restorelab\\admin -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-Service -Name LanmanServer,W32Time,DFSR | Format-Table -AutoSize\""
Status Name DisplayName
------ ---- -----------
Running LanmanServer Server
Running W32Time Windows Time
Running DFSR DFS Replication
Qué significa la salida: Servicios clave están en ejecución. Si DFSR está detenido en un DC, la replicación de SYSVOL y la distribución de políticas pueden fallar.
Decisión: Trate el estado de servicios críticos como parte de la puerta de aceptación de la restauración.
Task 12: Revisar logs de eventos por los principales causantes de fallo en restauraciones (VSS, disco, NTFS, AD)
cr0x@server:~$ evil-winrm -i 192.168.50.22 -u restorelab\\admin -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddHours(-6)} | ? {$_.LevelDisplayName -in 'Error','Critical'} | Select -First 8 TimeCreated,Id,ProviderName,Message | Format-Table -Wrap\""
TimeCreated Id ProviderName Message
----------- -- ------------ -------
2/4/2026 12:41:10 AM 11 Disk The driver detected a controller error on \Device\Harddisk0\DR0.
2/4/2026 12:42:02 AM 55 Ntfs A corruption was discovered in the file system structure on volume C:.
Qué significa la salida: Errores de disco y NTFS tras la restauración usualmente significan desajuste de driver/controlador, presentación de disco virtual mala o problemas de almacenamiento subyacente.
Decisión: Deje de culpar al backup. Arregle el almacenamiento objetivo y vuelva a ejecutar la restauración. De lo contrario “probará” lo equivocado.
Task 13: Medir throughput de la ruta de restauración desde repo al objetivo (deje de adivinar)
cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (backup-repo01) 02/04/2026 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
22.1 0.0 8.3 18.7 0.0 50.9
Device r/s rkB/s rrqm/s %util await
nvme0n1 890.0 215000.0 0.0 98.2 9.40
Qué significa la salida: El disco del repo está en ~98% de utilización con iowait significativo. Las lecturas son el cuello de botella.
Decisión: Si el repo está saturado, su prueba de restauración debe fallar en el RTO aun cuando “funcione”. Mejore el almacenamiento del repo, separe cargas o cambie el staging de restauración.
Task 14: Validar que los shares SMB y ACLs sobrevivieron (los servidores de archivos fallan silenciosamente)
cr0x@server:~$ evil-winrm -i 192.168.50.40 -u restorelab\\admin -p 'REDACTED' -c "powershell -NoProfile -Command \"Get-SmbShare | Select Name,Path,EncryptData | Sort Name | Format-Table -AutoSize\""
Name Path EncryptData
---- ---- -----------
Finance D:\Shares\Finance False
HR D:\Shares\HR False
Qué significa la salida: Los shares existen. El siguiente paso es comprobar ACLs; las restauraciones a menudo traen datos pero no el modelo de permisos exacto que esperaba.
Decisión: Si faltan shares, su alcance de restauración es incorrecto (nivel archivo sin metadata de share) o la configuración del rol de servidor no fue incluida.
cr0x@server:~$ evil-winrm -i 192.168.50.40 -u restorelab\\admin -p 'REDACTED' -c "powershell -NoProfile -Command \"(Get-Acl 'D:\\Shares\\Finance').Access | Select -First 6 IdentityReference,FileSystemRights,AccessControlType | Format-Table -AutoSize\""
IdentityReference FileSystemRights AccessControlType
----------------- ---------------- -----------------
RESTORELAB\Domain Admins FullControl Allow
RESTORELAB\Finance-Users Modify, Synchronize Allow
Qué significa la salida: Las ACLs parecen plausibles. Si todo es propiedad de “Administrator” o “Unknown SID”, restauró archivos sin contexto de seguridad.
Decisión: Trate la integridad de ACL como criterio de aprobado/fallado para servicios de archivos. “Los datos existen” no es suficiente.
Tres microhistorias corporativas desde las trincheras de la restauración
Microhistoria 1: El incidente causado por una suposición equivocada
Una empresa mediana tenía lo que parecía una configuración madura: backups nocturnos de VM, fulls semanales y reportes mensuales. El equipo de operaciones creía tener un RTO limpio
porque restauraciones en el pasado “habían funcionado”. Su suposición era que restaurar una VM equivale a restaurar un servicio.
Entonces un incidente de almacenamiento corrompió un volumen SQL de producción. El equipo restauró la VM de SQL desde el último punto bueno en producción. La VM arrancó bien.
La gerencia recibió la buena noticia. Minutos después, la aplicación empezó a lanzar errores de autenticación y luego timeouts. La base de datos estaba online, pero la app
no podía conectarse de forma fiable.
La pieza faltante no era SQL. Era DNS y hora. La VM restaurada arrancó con una configuración NIC más vieja, un sufijo DNS distinto y una deriva de tiempo que no importó en una prueba aislada
pero sí importó bajo Kerberos y TLS. La capa de la aplicación estaba resolviendo al hostname equivocado y las cuentas de servicio fallaban porque el skew del reloj excedía la tolerancia.
El postmortem fue franco: habían probado “¿podemos arrancar una VM?”, no “¿podemos ejecutar el servicio?”. Añadieron dos comprobaciones de aceptación a su simulacro de restauración:
(1) validar resolución DNS para nombres críticos, y (2) validar sincronización de tiempo y validez de certificados. Pruebas baratas. Gran retorno.
Microhistoria 2: La optimización que salió mal
Otra organización decidió “ser seria” respecto al coste del almacenamiento de backups. Consolidaron backups de decenas de servidores Windows en un único repositorio con fuerte
deduplicación y compresión agresiva. Se veía genial en una diapositiva: ahorro de capacidad, menos discos, menos servidores, menos dolores de cabeza.
Las restauraciones iban bien en periodos de calma. Luego hicieron un ejercicio DR anual donde varias restauraciones ocurrieron a la vez: un DC, dos servidores de archivos y un SQL.
Todo se volvió una tortuga. La CPU del servidor repo se saturó, el iowait subió y los ETAs de restauración crecieron de forma que hace que la gente empiece a negociar con la física.
El problema subyacente no era “la herramienta de backup es lenta”. El diseño del repo creó un hot spot de descompresión+dedup. Muchas restauraciones simultáneas desencadenaron lecturas aleatorias
a través del store deduplicado, y la CPU se convirtió en cuello de botella por cifrado y compresión. La “optimización” había convertido lecturas secuenciales baratas en lecturas dispersas costosas más consumo de CPU.
Su solución fue ingeniería aburrida: separar el repo en capas, reservar almacenamiento rápido para puntos de restauración recientes y limitar la concurrencia según el comportamiento medido del repo.
Los costes de capacidad aumentaron. La predictibilidad de las restauraciones regresó. En DR, la predictibilidad es la característica premium.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Una empresa regulada tenía una regla que nadie amaba: cada mes, restaurar un controlador de dominio, un servidor SQL y un servidor de archivos en una red de laboratorio aislada,
y ejecutar un script de validación estándar. Tomaba una mañana. También producía evidencia que los auditores adoraban, lo cual no es despreciable.
Un trimestre, la restauración de laboratorio de un servidor de archivos falló en una validación de ACL. Los datos se restauraron, pero los permisos estaban mal. El equipo trazó el problema a un cambio de configuración:
habían cambiado de restauraciones a nivel de imagen a restauraciones a nivel de archivo para ese servidor porque “ahorraba tiempo” y reducía uso de repo.
Revirtieron el cambio, actualizaron el runbook y añadieron un guardrail: los servicios de archivos deben incluir la configuración de shares y descriptores de seguridad en el alcance de restauración, verificado por script.
Nunca llevaron ese patrón roto a un incidente real.
Meses después, un evento de ransomware forzó restauraciones de emergencia. El equipo ya tenía procedimientos probados, un diseño de red de laboratorio funcional y un método conocido para
esa clase de servidor de archivos. Restauraron servicios mientras otros equipos aún discutían si los backups estaban “intactos”. El simulacro aburrido pagó la renta.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: El trabajo de restauración “tiene éxito” pero la app está rota
Causa raíz: Validó infraestructura (arranque, archivos presentes) pero no el comportamiento de la aplicación. A menudo DNS, hora, certificados o secretos de cuentas de servicio.
Solución: Añada pruebas de aceptación postrestauración: comprobaciones de resolución DNS, sincronización de tiempo y al menos una transacción sintética por cada app crítica.
2) Síntoma: La base de datos SQL restaurada está “online” pero los usuarios ven errores
Causa raíz: Backup crash-consistent, logs faltantes o corrupción introducida por problemas de almacenamiento subyacente.
Solución: Requiera CHECKDB (o equivalente) en el simulacro de restauración. Investigue la salud del escritor VSS al tiempo del backup; asegure que SqlServerWriter esté estable.
3) Síntoma: La restauración bare-metal no arranca (no se encuentra OS, bucle de arranque)
Causa raíz: Desajuste UEFI/BIOS, partición EFI faltante, BCD roto, problemas de controladores con Secure Boot.
Solución: Haga coincidir modo de firmware y esquema de partición. Verifique el layout de particiones tras la restauración. Mantenga WinRE habilitado y probado.
4) Síntoma: El DC restaurado arranca, pero la replicación o SYSVOL está rota
Causa raíz: Procedimiento de restauración de DC incorrecto, comportamiento de rollback de snapshots, DFSR no saludable o problemas relacionados con USN en entornos mixtos.
Solución: Use el método correcto para restaurar AD (reglas de System State, autoritativo cuando sea necesario). Valide con dcdiag y comprobaciones de SYSVOL/NETLOGON antes de unir miembros.
5) Síntoma: Los datos del servidor de archivos están presentes pero los usuarios no pueden acceder a los shares
Causa raíz: No se restauraron los shares, se perdieron ACLs o los SIDs no mapean (restauración fuera del contexto de dominio original).
Solución: Pruebe la enumeración de shares y muestreo de ACLs. Para migraciones de dominio o laboratorios aislados, proporcione mapeo de identidades o restaure en el mismo contexto de dominio.
6) Síntoma: Las restauraciones son impredeciblemente lentas
Causa raíz: Cuello de botella en disco del repo, CPU por compresión/cifrado, contención de red, saturación del almacenamiento objetivo o sobrecarga de escaneo de seguridad.
Solución: Mida cada segmento: iostat/perf del repo, throughput de red, latencia del objetivo y impacto de AV/EDR. Luego limite la concurrencia y nivele el almacenamiento.
7) Síntoma: “Acceso denegado” durante o después de la restauración
Causa raíz: Claves de cifrado faltantes, bóveda de credenciales perdida, contraseñas de cuentas de servicio cambiadas o sistemas restaurados perdiendo la relación de confianza.
Solución: Trate la gestión de claves como parte del DR. Almacene claves fuera de banda. Pruebe procedimientos de reparación de confianza en el laboratorio.
Segunda broma corta: Si su plan de restauración depende de “la única persona que conoce la contraseña”, felicidades—ha implementado recuperación ante desastres artesanal.
Listas de verificación / plan paso a paso que puede adoptar
Paso 0: Elija los objetivos de restauración que expondrán la realidad
- Un controlador de dominio (o al menos validación de System State si no va a restaurar un DC).
- Una instancia de SQL Server con una base de datos representativa.
- Un servidor de archivos con complejidad real de ACLs y shares.
- Un servidor “duro”: driver legado, particionado raro o un sistema con dependencia en HSM/certificado.
Paso 1: Construya el entorno de restauración aislado
- VLAN dedicada o switch virtual sin ruta a redes de producción.
- DNS y DHCP de laboratorio (o direccionamiento estático), con sufijo de dominio claramente separado (p. ej., restorelab.local).
- Fuente de tiempo controlada en el laboratorio; evite relojes en libre ejecución.
- Sumidero de logs: un lugar central para almacenar salidas, marcas de tiempo y artefactos de restauración.
Paso 2: Defina puertas de aceptación por workload
- Puerta de arranque Windows: arranca sin errores de disco/NTFS; estado de WinRE conocido; layout de particiones correcto.
- Puerta AD: dcdiag limpio; SYSVOL y NETLOGON compartidos existen; DNS saludable.
- Puerta SQL: base de datos online; CHECKDB pasa para al menos una BD crítica; inicio de sesión de aplicación funciona.
- Puerta servicios de archivos: shares existen; comprobaciones de muestra de ACL pasan; un usuario de prueba puede leer/escribir donde corresponde.
- Medición RTO: registre inicio/fin de restauración y tiempo hasta servir una transacción sintética.
Paso 3: Automatice la recopilación de evidencia
- Capture salidas de comandos (dcdiag, vssadmin, filtros de event log, comprobaciones SQL) en archivos con marca de tiempo.
- Registre IDs de puntos de restauración, estado de cifrado y ubicación del repositorio.
- Guarde el runbook en control de versiones. Si no está versionado, es folclore.
Paso 4: Practique los pasos “romper el vidrio” deliberadamente
- Recupere la clave de cifrado desde el mismo lugar que usaría durante un incidente.
- Restaure usando el mismo modelo de credenciales (MFA/acceso privilegiado) usado en producción.
- Simule pérdida de acceso a estación de admin: ¿puede hacerlo desde una máquina limpia?
Paso 5: Haga que la prueba de restauración duela un poco (de forma segura)
- Limite la red para simular restauraciones por WAN si ese es su plan.
- Restaure dos sistemas a la vez para probar concurrencia en el repo.
- Ejecute con las herramientas de seguridad habilitadas para ver el costo real de write-amplification.
Paso 6: Convierta los resultados en decisiones
- Si no se cumple el RTO: añada una capa de repo más rápida, reduzca compresión, añada controles de concurrencia o traslade sistemas críticos a réplicas.
- Si fallan puertas de app: repare la salud de VSS writer, añada scripts pre-backup, ajuste el quiescing o cambie el método de backup para esa carga.
- Si fallan puertas AD: refine la estrategia de restauración de AD; deje de tratar la restauración de DC como “una VM más”.
Preguntas frecuentes
1) “Nuestros trabajos de backup son exitosos. ¿Por qué fallarían las restauraciones?”
Porque el éxito del trabajo suele significar “los datos se leyeron y escribieron en algún sitio”. No garantiza consistencia de la aplicación, arrancabilidad, corrección de identidades ni
que pueda cumplir su RTO bajo carga.
2) ¿Con qué frecuencia deberíamos ejecutar pruebas de restauración?
Para servicios críticos: mensual. Para todo lo demás: trimestral. También después de cambios significativos—nuevo repo de backup, nuevo cifrado, upgrades de OS, migración de almacenamiento,
upgrade de hipervisor o versión principal de una aplicación.
3) ¿Realmente necesitamos probar restauraciones bare-metal si todo es virtual?
Puede salirse con la suya con pruebas solo en VM hasta que no pueda: los desajustes de modo de firmware, bootloaders corruptos, problemas de drivers y medios de recuperación aún importan.
Como mínimo, pruebe una ruta BMR por cada build de Windows y clase de hardware que aún opere.
4) ¿Cuál es la validación mínima de “servicio” para una prueba de restauración?
Arranque + escaneo de event log por errores críticos + sincronización de tiempo + resolución DNS + una comprobación específica de la carga:
dcdiag para AD, CHECKDB para SQL, validación de ACL+shares para servidores de archivos y una transacción sintética para aplicaciones.
5) No podemos restaurar un controlador de dominio en un laboratorio sin riesgo. ¿Qué hacemos?
Use una red totalmente aislada sin enrutamiento a producción, rangos IP únicos y sufijo DNS único. Si eso todavía no es aceptable, pruebe mecánicas de restauración de System State
y comprobaciones de salud de AD en un bosque no productivo diseñado para simulacros de restauración.
6) ¿Por qué importan los problemas de escritores VSS si el backup dice “application-aware succeeded”?
VSS tiene writers, providers y requestors. Un writer puede estar en estado degradado y aun así producir un snapshot que no es verdaderamente consistente con la aplicación. Su prueba de restauración
debe incluir la comprobación del estado del writer y validar la integridad a nivel de aplicación tras la restauración.
7) ¿Cómo medimos el RTO correctamente?
Mida desde “inicio de restauración” hasta “el servicio pasa una transacción sintética”. No desde “VM encendida”. No desde “aparece la pantalla de login”. A los usuarios no les importa que Windows
haya arrancado; les importa que la aplicación funcione.
8) ¿Cuál es la causa principal de restauraciones lentas?
Cuellos de botella en el repositorio (disco y CPU), seguido por latencia de escritura del objetivo y luego la sobrecarga de escaneo de seguridad. La red puede ser el cuello de botella también,
pero a menudo se la culpa prematuramente.
9) ¿Necesitamos deshabilitar antivirus/EDR durante las restauraciones?
No por defecto. Pero debe probar con ello habilitado, porque esa es la realidad de producción. Si aplasta el RTO, negocie exclusiones para las rutas de restauración y valide esas exclusiones en el laboratorio.
10) ¿Qué debemos almacenar como evidencia de las pruebas de restauración?
Identificadores de puntos de restauración, marcas de tiempo, salidas de comandos para las puertas de aceptación y notas sobre desviaciones. La evidencia debe almacenarse fuera del sistema de backup
para que sobreviva a un compromiso de la infraestructura de backup.
Conclusión: próximos pasos que cambian resultados
Si solo extrae una lección operativa de las restauraciones de copias de seguridad en Windows, tome esta: un informe verde de backup no es una capacidad de restauración. Necesita un simulacro
diseñado que demuestre que el servicio puede reconstruirse en un entorno controlado, dentro de un tiempo medido, usando las mismas restricciones que tendrá durante un apagón real.
Pasos prácticos siguientes:
- Levante una red de restauración aislada y escriba las reglas (sin enrutamiento a producción, DNS controlado, tiempo controlado).
- Elija tres sistemas para un simulacro mensual: DC, SQL, servidor de archivos. Rote el resto trimestralmente.
- Adopte puertas de aceptación (arranque, VSS, logs de eventos, salud AD, CHECKDB de SQL, validación de share+ACL, transacción sintética).
- Instrumente la ruta de restauración: iowait del repo, CPU, latencia del objetivo y comportamiento de concurrencia. Convierta “lento” en un número.
- Controle la versión del runbook y almacene evidencia fuera de banda. Hágalo repetible por alguien que no sea usted.
Haga eso y la próxima vez que ocurra algo feo, estará ejecutando un procedimiento practicado en lugar de realizar arqueología en vivo sobre su propia infraestructura.