La frecuencia responde a una sola pregunta
Una copia cada hora acota cuánto trabajo reciente podría perderse si hay que volver a un punto anterior. Si el último punto válido es de las 12:00 y el incidente ocurre a las 12:50, la ventana potencial de pérdida se acerca a una hora. Esa ventana es el RPO; debe acordarse según el proceso, no según una frase comercial.
Una empresa que registra pedidos durante todo el día puede necesitar más frecuencia que un archivo que cambia una vez por semana. Copiar más veces también aumenta retención, tráfico y coste. La política debe seguir el impacto del dato.
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.
AMBG revisa primero una carga real y define qué debe quedar funcionando. Después se elige la política y se prueba en un entorno controlado, sin convertir la prueba en un riesgo para producción.
