Una base de datos puede dejar de estar disponible por un fallo de hardware, un error humano, una actualización defectuosa o un ataque. En cualquiera de estos casos, disponer de archivos de copia no garantiza que la empresa pueda recuperar la información a tiempo. La protección real exige decidir qué se copia, con qué frecuencia, dónde se conserva y cómo se restaura.
El plan debe adaptarse a la importancia de cada sistema. No necesita la misma protección una base histórica que apenas cambia que la aplicación desde la que se gestionan pedidos, facturas o incidencias durante toda la jornada. La prioridad es relacionar cada medida técnica con el impacto que tendría perder datos o mantener el servicio detenido.
1. Definir cuántos datos y cuánto tiempo puede perder la empresa
Antes de elegir herramientas o calendarios conviene fijar dos objetivos. El RPO u objetivo de punto de recuperación indica la pérdida máxima de datos que la empresa considera asumible. Si se establece en una hora, las copias deben permitir volver a un estado con una antigüedad máxima aproximada de una hora.
El RTO u objetivo de tiempo de recuperación marca cuánto puede tardar el servicio en volver a funcionar. No depende solo de la velocidad de copia: también influyen el tamaño de la base, la disponibilidad del servidor, las credenciales, las aplicaciones relacionadas y el procedimiento que debe seguir el responsable.
Por ejemplo, una empresa podría aceptar perder como máximo 30 minutos de pedidos y necesitar recuperar el software-a-
2. Combinar los tipos de copia adecuados
Una copia completa contiene la base de datos necesaria para iniciar la recuperación. Es sencilla de comprender, pero puede exigir más tiempo y espacio a medida que crece la información. Por eso suele combinarse con otros tipos de copia.
En SQL Server, una copia diferencial guarda los cambios realizados desde la última copia completa. Una copia del registro de transacciones conserva la secuencia de operaciones y, con el modelo de recuperación apropiado, permite acercar la restauración a un momento concreto. La estrategia debe mantener una cadena coherente: una copia diferencial o del registro no sustituye a la base completa de la que depende.
En una solución basada en Microsoft Access también deben protegerse el archivo de datos y los elementos necesarios para volver a trabajar, como la aplicación, la configuración y las conexiones. Copiar únicamente el archivo que el usuario ve puede dejar fuera componentes imprescindibles para reconstruir el servicio.
3. Ajustar la periodicidad y la conservación
La frecuencia debe derivarse del RPO y del ritmo de cambios. Una base crítica y muy activa puede requerir copias del registro durante el día, además de copias completas y diferenciales. Un repositorio estable puede admitir intervalos mayores. La programación debe tener en cuenta las horas de carga, el espacio disponible y el tiempo que exigiría restaurar toda la secuencia.
La política de conservación determina cuánto tiempo se guardan las versiones diarias, semanales o mensuales. Conservar solo la última copia es arriesgado: una corrupción o un borrado puede pasar inadvertido y propagarse a las siguientes. La retención debe permitir regresar a un punto anterior suficiente para investigar y recuperar, sin acumular archivos sin control.
También hay que vigilar el resultado de cada ejecución. Un proceso programado que falla durante varios días puede seguir dando una falsa sensación de seguridad si nadie revisa sus avisos.
4. Mantener copias separadas y protegidas
Guardar la copia en el mismo servidor o unidad que la base original no protege frente a la avería de ese equipo. Al menos una versión debe residir en una infraestructura separada. Para reducir el impacto del ransomware o de unas credenciales comprometidas, conviene disponer además de una copia sin conexión o inmutable, que no pueda modificarse durante su periodo de conservación.
La separación debe incluir el control de acceso. Si la misma cuenta puede administrar producción y borrar todas las copias, un único incidente puede afectar a ambos entornos. El cifrado protege la información almacenada, pero las claves y credenciales de recuperación también deben conservarse de forma segura y accesible para las personas autorizadas.
5. Asignar responsables y dejar evidencias
El plan necesita propietarios concretos. Una persona o proveedor debe supervisar las ejecuciones, resolver alertas y comprobar la capacidad disponible. Otra responsabilidad esencial es autorizar y coordinar una restauración, sobre todo cuando intervienen aplicaciones, servidores o servicios externos.
La documentación debe indicar:
• qué bases de datos y componentes se protegen;
• qué tipos de copia se realizan y con qué calendario;
• dónde se almacenan y cuánto tiempo se conservan;
• quién recibe los avisos y en qué plazo debe actuar;
• cómo se solicita, ejecuta y valida una restauración.
Un registro de ejecuciones y pruebas aporta evidencias para detectar fallos repetidos y conocer la última recuperación verificada.
6. Probar la restauración, no solo el archivo
Una tarea que termina sin errores demuestra que se ha creado un archivo, pero no que la empresa pueda recuperar su actividad. Una copia no es fiable hasta que se ha restaurado y verificado. La prueba debe realizarse en un entorno aislado para evitar sobrescribir la base de producción.
Durante el ensayo hay que comprobar la integridad de la base, abrir la aplicación, ejecutar operaciones representativas y confirmar que usuarios, permisos y conexiones funcionan. También conviene medir el tiempo total, anotar las incidencias y compararlo con el RTO. Si el resultado no cumple el objetivo, debe ajustarse el proceso, la infraestructura o la propia expectativa de recuperación.
Las pruebas han de repetirse con una periodicidad definida y siempre que cambien de forma relevante la base, la aplicación, el servidor o el sistema de copias. Variar las versiones restauradas ayuda a comprobar que la conservación histórica también funciona.
7. Convertir la estrategia en un plan operativo
Un plan útil puede implantarse de forma ordenada:
• inventariar las bases de datos y sus dependencias;
• clasificar su criticidad y acordar RPO y RTO;
• definir tipos de copia, frecuencia y retención;
• separar y proteger al menos una copia;
• automatizar avisos y asignar responsables;
• ejecutar restauraciones de prueba y registrar los resultados.
Este recorrido permite priorizar. Si una empresa descubre que su sistema más crítico no puede restaurarse dentro del tiempo previsto, puede actuar sobre ese riesgo antes de ampliar medidas menos urgentes.
Conclusión
Una estrategia de copias de seguridad no se reduce a programar una tarea nocturna. Debe responder a la criticidad de los datos, combinar copias compatibles, conservar versiones suficientes y mantener al menos una copia separada y protegida. Los responsables y los procedimientos completan la parte técnica.
La prueba de restauración convierte esas medidas en una capacidad demostrable. Solo al recuperar la base, validar su funcionamiento y medir el tiempo empleado puede saberse si el RPO y el RTO son realistas.
En GS Programadores podemos ayudar a revisar la arquitectura de bases de datos, definir y automatizar planes de copia y preparar procedimientos de restauración para soluciones con Microsoft Access y SQL Server, ajustándolos a las necesidades operativas de cada empresa.
