Cómo probar un respaldo antes de necesitarlo: guía para pymes

El aviso de «respaldo completado» deja una pregunta pendiente: ¿podría tu equipo recuperar lo necesario para trabajar? La respuesta requiere abrir una copia, revisar su contenido y comprobar que la aplicación o actividad elegida funciona en las condiciones previstas.

Esta guía propone una primera prueba de restauración para dueños, administración y responsables de TI. Puedes empezar con un proceso acotado, como consultar los documentos de una operación o abrir un reporte administrativo. El resultado será un registro de lo que se recuperó, cuánto tardó y qué falta resolver.

1. Elige una actividad y define qué significa recuperarla

Antes de seleccionar archivos, elige la actividad que vas a comprobar: consultar expedientes, preparar cotizaciones o revisar cuentas por cobrar. Identifica al responsable técnico y a una persona del área que pueda validar el resultado. NIST recomienda definir las responsabilidades de recuperación y ordenar las acciones según las necesidades del negocio. [1]

Escribe un criterio observable. Por ejemplo: «La persona autorizada abre la aplicación de prueba, consulta tres registros elegidos previamente y obtiene un reporte de un periodo conocido». Define también qué queda fuera: emisión de documentos reales, conexiones con terceros o recuperación de otras áreas. Una prueba pequeña da evidencia sobre su alcance; no demuestra que toda la empresa pueda recuperarse.

2. Acuerda dos objetivos: tiempo y antigüedad de los datos

El tiempo objetivo de recuperación, conocido como RTO, expresa cuánto tiempo puede permanecer el sistema en recuperación antes de afectar los procesos del negocio. Para el ejercicio, acuerda desde qué momento se cuenta y qué resultado marcará el final. [2]

El punto objetivo de recuperación, o RPO, indica hasta qué momento necesitas recuperar los datos después de una interrupción. Tradúcelo a una pregunta del área: ¿cuánto trabajo reciente podríamos aceptar reconstruir? Registra el objetivo antes de elegir la copia. [3]

Ejemplo hipotético: una empresa fija dos horas para recuperar la consulta de pedidos y acepta reconstruir como máximo una hora de cambios. Al simular una interrupción a las 11:00, la última información recuperable corresponde a las 08:00. La recuperación y la validación de la consulta acordada terminan en 40 minutos, pero quedan tres horas de cambios fuera del punto recuperado. La prueba cumple el tiempo propuesto, pero incumple el RPO de una hora.

Estos valores son un ejemplo para razonar, no una recomendación universal ni un compromiso de Myndaros. Dirección y operaciones deben decidir sus objetivos según las actividades, alternativas y consecuencias reales de una interrupción.

3. Reúne las dependencias antes de restaurar

Pide a TI que identifique qué necesita el proceso además de los archivos: aplicación y versión, base de datos, permisos, configuración, capacidad disponible y acceso autorizado a los mecanismos de descifrado. NIST incluye las configuraciones, claves, software y servicios dependientes entre los elementos que deben considerarse para una recuperación completa. [4]

En una ficha de preparación anota dónde está la copia elegida, qué fecha de información contiene, quién puede recuperarla y dónde está el procedimiento. Si requiere varias copias relacionadas, el responsable técnico debe confirmar que dispone del conjunto necesario. Conserva contraseñas, claves y certificados en su resguardo autorizado, fuera de esa ficha.

Confirma también que la aplicación puede utilizarse en el entorno de prueba conforme a sus condiciones. Si trabajas con Aspel, CONTPAQi u otro sistema administrativo, pide el procedimiento de respaldo y restauración correspondiente a tu producto y versión. No asumas que un mismo método sirve para todas las aplicaciones.

4. Prepara un entorno que no afecte el trabajo diario

Antes de restaurar, confirma con TI la procedencia y el resguardo de la copia. Si se desconocen o hay indicios de manipulación, detén el ejercicio y solicita una revisión especializada. Microsoft advierte que restaurar una base de origen no confiable puede comprometer el equipo o la instancia antes de ejecutar comprobaciones. [7]

La persona técnica debe definir un destino separado y comprobar que la restauración no sobrescribirá archivos, bases de datos ni configuraciones en uso. En SQL Server, Microsoft explica que restaurar en otro equipo puede requerir ajustar rutas y nombres, además de recrear elementos como inicios de sesión o trabajos programados. Por eso conviene revisar el destino antes de ejecutar. [5]

Para una prueba de un sistema administrativo, proponemos un control adicional: impedir que la copia envíe correos, timbre documentos, ejecute cobros o sincronice cambios con la operación real. El responsable técnico debe identificar esas salidas y confirmar el aislamiento antes de abrir la aplicación. Si no puede comprobarlo, se detiene la prueba hasta resolverlo.

Los datos recuperados conservan su sensibilidad. Limita el acceso a las personas autorizadas y acuerda cuánto tiempo se conservará el entorno. La salvaguarda 11.3 de CIS pide proteger los datos de recuperación con controles equivalentes a los originales. [6] Si sospechas que ocurrió un incidente de seguridad, coordina la recuperación con su responsable: una restauración por sí sola no aclara la causa ni demuestra que el entorno sea seguro.

5. Ejecuta la prueba y registra el tiempo completo

Anota la hora de inicio desde la solicitud de recuperación. Registra por separado cuánto toma localizar la copia, obtener los accesos autorizados, preparar el destino, recuperar los datos y validar el resultado. Así podrás distinguir una transferencia lenta de una espera por permisos o por la persona que conoce el procedimiento.

Una propuesta sencilla de secuencia es: confirmar autorización y destino; identificar la copia y su punto de recuperación; restaurarla con el procedimiento aprobado; revisar los mensajes y errores; validar el contenido con el área; y registrar el cierre. Si alguna etapa queda pendiente, conserva ese estado en el informe.

Algunas preparaciones pueden hacerse antes del cronómetro, como disponer de un equipo de prueba. Debes declararlo. Un ejercicio con infraestructura preparada sirve para aprender, pero su tiempo no incluye conseguir o configurar un reemplazo durante una interrupción real. Anota también lo que no pudiste simular, como la pérdida total de internet o la ausencia del administrador habitual.

6. Comprueba archivos, aplicación y resultado de negocio

Archivos. Abre una muestra definida previamente y confirma que corresponde al periodo y contenido esperado. Incluye distintos tipos de documento y verifica que los puede consultar quien necesita trabajar con ellos. Registrar que una carpeta existe deja sin comprobar su contenido y acceso.

Base de datos. Si utilizas SQL Server, pide que la revisión siga su procedimiento específico. Microsoft recomienda restaurar en un sistema de prueba y comprobar la consistencia de la base recuperada con DBCC CHECKDB. El alcance técnico y su ejecución corresponden al administrador. [7]

Hay un matiz importante: RESTORE VERIFYONLY comprueba que el conjunto de respaldo esté completo y sea legible, pero no realiza la restauración ni intenta verificar la estructura de los datos contenidos. Un resultado satisfactorio de esa comprobación debe registrarse como tal, sin presentarlo como una prueba completa de recuperación. [8]

Aplicación y trabajo. Pide a la persona del área que ejecute las consultas acordadas, revise el reporte y confirme el punto de información recuperado. Una base disponible puede necesitar todavía permisos, configuración o componentes para funcionar con su aplicación. Guarda una evidencia suficiente, evitando capturas con información personal o comercial innecesaria.

7. Cierra con un resultado verificable y pendientes concretos

Proponemos cuatro estados: aprobado, aprobado con observaciones no críticas, incompleto o fallido. Los dos primeros requieren cumplir los criterios acordados; una observación no crítica no puede ocultar un incumplimiento de tiempo o datos. Si faltó validar la aplicación, el ejercicio queda incompleto. Si se comprobó que no cumple un criterio, registra el fallo. Una prueba parcial no acredita la continuidad de toda la empresa.

La ficha de cierre puede tener ocho campos: actividad probada; copia y punto de datos recuperado; responsables; entorno y preparaciones previas; objetivos acordados; tiempos observados por etapa; evidencias y resultado; y pendientes con responsable y fecha de repetición. Guarda la ficha donde el equipo autorizado pueda encontrarla si falta su encargado habitual.

Un pendiente útil describe el siguiente paso. «El reporte no abre por un permiso faltante; TI revisará la cuenta de prueba y operaciones repetirá la validación» permite continuar. «Revisar respaldos» deja demasiadas decisiones abiertas. Al terminar, aplica la política acordada de conservación o eliminación del entorno y verifica que la programación habitual de respaldos siga como estaba prevista.

8. Decide cuándo repetir y qué probar después

Como referencia, la salvaguarda 11.5 de CIS plantea pruebas trimestrales o más frecuentes sobre una muestra de activos; está incluida en sus grupos de implementación 2 y 3. Es una referencia técnica que debe ajustarse al contexto, no una periodicidad legal universal para cualquier pyme. [6]

Después del primer ejercicio, programa el siguiente según la criticidad y los cambios del sistema. Un cambio de aplicación, proveedor, responsables o procedimiento puede justificar una nueva validación. Amplía la cobertura de forma explícita: otra carpeta, otra base, otra ubicación o la sustitución de un equipo. Conserva el historial para saber qué se ha probado y qué sigue sin evidencia.

¿Qué necesitarías recuperar primero?

Para iniciar una conversación útil, cuéntanos qué aplicación detendría una actividad importante de tu empresa y cuándo probaron recuperarla por última vez. Con ese contexto podemos conversar sobre el alcance que tendría sentido evaluar con Myndaros Enterprise. No necesitas enviar respaldos, contraseñas ni documentos de clientes.