La frecuencia responde a una sola pregunta
Una copia cada hora reduce la cantidad de trabajo reciente que podría perderse. Por ejemplo, si el último punto recuperable es de las 12:00 y la incidencia ocurre a las 12:50, podrían faltar esos cincuenta minutos de cambios. El RPO es el objetivo máximo de pérdida aceptable; no la pérdida observada en cada incidente.
Un sistema que registra pedidos durante todo el día quizá necesite más frecuencia que un archivo que apenas cambia. Aumentar esa frecuencia también puede afectar al tráfico, al almacenamiento y al coste, según la plataforma y la retención contratadas.
Un punto horario no siempre es una copia completa
Una plataforma puede crear snapshots, copias incrementales u otros puntos de recuperación sin duplicar cada hora todos los bloques del servidor. Eso no los hace menos útiles, pero sí obliga a describirlos con precisión. “Punto de recuperación horario” es una promesa verificable; “copia completa cada hora” puede no serlo.
También importa la consistencia de la aplicación. Una imagen del disco no garantiza por sí sola que la base de datos, los servicios y las transacciones hayan quedado en un estado recuperable. Las cargas críticas necesitan procedimientos compatibles con la aplicación.
Retención y aislamiento forman parte de la copia
La frecuencia sirve de poco si todos los puntos se sobrescriben enseguida o si un atacante puede borrar producción y copias con la misma cuenta. Conviene separar credenciales, conservar puntos diarios y semanales y mantener al menos una copia fuera del entorno principal.
Las copias horarias, diarias y semanales disponibles en algunos servicios cloud permiten combinar recuperación reciente e histórico. La política concreta debe quedar escrita: alcance, frecuencia, retención, ubicación y responsable.
Restaurar un archivo no recupera un ERP
Recuperar un documento demuestra que ese documento está disponible. No demuestra que el ERP arranque, que la red permita acceder, que los permisos funcionen o que una integración vuelva a procesar pedidos. La continuidad depende del conjunto de servicios.
Por eso backup y disaster recovery no son sinónimos. El backup protege datos. El plan de recuperación describe cómo volverán servidores, aplicaciones, redes, accesos y dependencias dentro de un tiempo objetivo.
La prueba mínima debe dejar evidencia
Una restauración útil tiene fecha, responsable, punto elegido, tiempo empleado, validaciones y resultado. Si falla, se registra la causa y se corrige el procedimiento. Sin esa evidencia solo sabemos que existe una tarea de copia; no sabemos si la empresa puede recuperar.
La revisión empieza por una aplicación concreta y por lo que tendría que seguir funcionando tras una incidencia. A partir de ahí se define la política de copia y se acuerda una prueba que no ponga en riesgo la producción.
