Copias de seguridad de tu software: qué pedir antes de contratar
Qué pedir sobre copias de seguridad de tu software: datos incluidos, tiempos de recuperación, retención y pruebas antes de contratar el desarrollo.
Las copias de seguridad de tu software no deberían depender de una frase en la cotización. "El hosting ya incluye respaldos" puede ser cierto y aun así dejar preguntas importantes sin responder. ¿Qué información cubren? ¿Hasta qué momento puedes recuperarla? ¿Quién vuelve a poner el sistema a trabajar?
Si vas a contratar una aplicación para operar pedidos, expedientes o inventario, conviene resolverlo antes del lanzamiento. Tener un archivo guardado no demuestra que puedas abrir el negocio mañana.
Empieza por cuánto puedes perder
Imagina una distribuidora que registra pedidos durante todo el día. Si su única copia se genera de madrugada, una falla por la tarde podría obligarla a reconstruir las operaciones posteriores a ese respaldo. El problema no se resuelve diciendo que la copia es "diaria".
Necesitas definir cuánto trabajo podrías reconstruir sin poner en riesgo la operación. Esa tolerancia se expresa como RPO, el objetivo de punto de recuperación. En términos prácticos, indica hasta qué punto del pasado necesitas poder recuperar los datos.
El RTO, u objetivo de tiempo de recuperación, responde otra pregunta. ¿Cuánto tiempo puedes pasar sin el sistema antes de que la interrupción sea inaceptable? Recuperar información reciente no sirve de mucho si volver a operar toma más de lo que tu negocio aguanta.
La guía de recuperación ante desastres de AWS recomienda fijar estos objetivos según las necesidades del negocio. No necesitas contratar infraestructura de multinacional. Necesitas explicar qué interrupción puedes tolerar y pedir una solución proporcional.
Aclara qué incluye la copia
Una aplicación suele guardar información en varios lugares. Los pedidos pueden estar en una base de datos y sus comprobantes en un servicio de archivos. Restaurar únicamente la base podría dejarte con registros que apuntan a documentos inexistentes.
Pide que las copias de seguridad de tu software cubran los componentes necesarios para recuperar los flujos acordados. También debe existir una forma de reconstruir la configuración y desplegar una versión compatible del código. Las credenciales necesitan custodia segura, no una carpeta compartida sin control.
Pregunta dónde se guardan las copias y quién puede borrarlas. Si el mismo incidente elimina producción y todos los respaldos, tener varios archivos no te ayudó. La separación de cuentas, accesos o ubicaciones debe responder al riesgo concreto, no a una colección de logos en la propuesta.
Retener versiones también importa
Una copia reciente puede contener un error antiguo. Si alguien elimina información el lunes y lo descubre el viernes, quizá los respaldos nuevos ya reflejen esa eliminación.
Por eso debes acordar cuánto tiempo se conservan las versiones y cómo se elige el punto que se va a restaurar. Más retención cuesta almacenamiento y exige cuidar los datos sensibles durante más tiempo. Menos retención reduce tus opciones. Ninguna de las dos decisiones debería quedar escondida en la configuración por defecto.
Sincronizar archivos o replicar una base tampoco garantiza conservar una versión anterior útil. Esas herramientas pueden copiar el error con mucha eficiencia. Pregunta por la recuperación de un borrado, además de la recuperación de un servidor caído.
Pide una restauración de prueba
La evidencia útil es levantar el sistema en un ambiente aislado y comprobar una operación representativa. Por ejemplo, abrir un pedido de prueba y consultar su comprobante. No hace falta provocar una caída en producción para ensayar.
El ejercicio debe registrar qué copia se usó, qué datos recuperó y cuánto tardó hasta que el flujo quedó utilizable. Descargar un respaldo es apenas un paso. Todavía puede faltar restaurar archivos, ajustar configuración y validar que la aplicación funcione.
Cuida el propio ensayo. Restringe el acceso a los datos restaurados y evita que el ambiente de prueba envíe correos, cobre pagos o dispare integraciones reales. Acuerda también cómo se eliminará esa copia temporal.
Esto complementa la entrega de software. El cierre entrega accesos y documentación; el ensayo comprueba una capacidad específica de recuperación. Repetirlo después de cambios importantes ayuda a detectar instrucciones que ya no corresponden al sistema actual.
Deja responsables y costos por escrito
¿Quién recibe una alerta si falla el respaldo? ¿Quién autoriza restaurar? ¿El servicio incluye atención fuera de horario o solamente almacenamiento? Una copia automática no contrata por sí sola a alguien para responder el domingo.
La propuesta debe distinguir la configuración inicial del trabajo recurrente. También aclarar el costo de los ensayos y qué ocurre con los movimientos posteriores al punto recuperado. Restaurar una versión anterior no reconstruye automáticamente pedidos nuevos ni revierte cobros externos.
Antes de contratar, lleva estas preguntas a la conversación sobre copias de seguridad de tu software. En DevAces preferimos conocer qué proceso no puedes detener antes de recomendar un plan. Cuéntanos qué sistema necesitas y qué pasaría si dejara de funcionar. Podemos empezar sin contraseñas ni datos reales de tus clientes.