Un aviso de “respaldo completado” confirma una tarea. Para saber si el negocio podría volver a trabajar, hace falta comprobar qué se guardó y qué ocurre al recuperarlo. Esta guía ayuda a preparar esa revisión con quien administra el servidor.
1. Empieza por lo que necesita seguir funcionando
Anota los servicios que dependen del servidor: sitio, correo, archivos, aplicación o base de datos. Para cada uno, identifica la información y las configuraciones necesarias para volver a usarlo. Copiar los archivos visibles de una aplicación puede dejar fuera sus registros de clientes, permisos o configuración.
En WordPress, por ejemplo, la documentación distingue el respaldo de la base de datos del respaldo de los archivos y pide comprobar que las copias sean utilizables antes de actualizar. Ese detalle importa: tener las fotografías de un catálogo no equivale a conservar sus productos y descripciones. Documentación de actualización de WordPress.
La lista también debe indicar quién puede autorizar una recuperación y quién conserva los accesos necesarios. Guarda las credenciales mediante un mecanismo seguro; la ficha de respaldo no debe convertirse en una lista de contraseñas.
2. Decide cuánto trabajo puedes permitirte perder
La frecuencia debe responder al ritmo del negocio. Un catálogo que cambia una vez por semana y un sistema que recibe pedidos durante todo el día no tienen la misma necesidad. Pregunta: si hubiera que regresar a la última copia, ¿qué información tendríamos que reconstruir y de dónde saldría?
Ejemplo hipotético: una empresa guarda una copia cada noche y pierde su servidor a las cinco de la tarde. Aunque la copia nocturna funcione, podría faltar el trabajo posterior. Si no puede reconstruir esos movimientos, necesita revisar la frecuencia o el mecanismo de protección. El ejemplo no define una frecuencia adecuada para todos los sistemas.
Separa además dos decisiones: cuánto historial necesitas conservar y cuánto tiempo puede estar detenido el servicio. Conservar más versiones puede ayudar ante un error descubierto días después; no demuestra que la recuperación vaya a ser rápida.
3. Comprueba dónde quedan las copias y quién puede modificarlas
Pregunta si un fallo o una cuenta comprometida en el servidor también permitiría borrar las copias. CISA recomienda respaldos cifrados fuera de línea y pruebas periódicas de disponibilidad e integridad como parte de la preparación frente a ransomware. Guía de CISA contra ransomware.
Para revisar la propuesta de tu administrador, pide que describa el escenario que cubre: borrado accidental, fallo del servidor o acceso no autorizado. “Está en la nube” no responde por sí solo dónde está la copia, cuánto se conserva ni cómo se recupera. Tampoco basta con que el archivo tenga la fecha de hoy: hay que conocer si la tarea terminó y si incluyó lo esperado.
4. Prepara una recuperación de prueba
Acuerda con el responsable técnico qué copia se usará, dónde se recuperará y qué funciones se comprobarán. Nuestra recomendación es usar un entorno separado, con accesos controlados y sin conectar automáticamente cobros, correos o tareas que puedan actuar sobre datos reales.
El procedimiento depende del producto. Azure Backup, por ejemplo, distingue entre crear una nueva máquina, restaurar discos y reemplazar discos existentes, con requisitos diferentes. Por eso la instrucción “restaura el respaldo” necesita un destino y un método concretos. Opciones de restauración de máquinas virtuales en Azure Backup.
No hace falta interrumpir el servicio para convertir esta guía en una tarea. Primero prepara el plan; el administrador debe confirmar el entorno, permisos, costos de la prueba y procedimiento apropiado antes de ejecutarla.
5. Comprueba una tarea del negocio
Abrir un archivo o encender una máquina no demuestra que toda la aplicación funcione. Elige una operación representativa: localizar un registro conocido, abrir su documento asociado y comprobar los permisos que deberían permitir consultarlo. Evita usar una compra o un envío real como prueba.
| Campo | Qué anotar |
|---|---|
| Servicio y copia | Qué se recuperó y de qué fecha es la información. |
| Entorno | Dónde se probó y cómo se evitó afectar la operación. |
| Tarea comprobada | Operación concreta, resultado esperado y resultado obtenido. |
| Tiempo observado | Inicio, fin y esperas; no convertir una prueba en garantía contractual. |
| Pendientes | Datos faltantes, dependencias, responsable y siguiente revisión. |
6. Deja una revisión programada
Define quién revisará los avisos de error y cuándo se repetirá la comprobación. Conviene volver a evaluar el plan después de cambios relevantes, como agregar una base de datos o migrar la aplicación. Una prueba pasada aporta evidencia de aquel escenario; el sistema puede cambiar.
La primera conversación útil con el administrador puede ser muy concreta: “Muéstrame qué estamos respaldando, de qué fecha es la última copia utilizable y cuándo recuperamos una muestra por última vez”. Las respuestas permiten decidir si falta ajustar el servicio o simplemente documentar lo que ya se hace.
Para profundizar en las tareas relacionadas: Cómo comprobar las copias de seguridad de tu negocio; Cómo preparar la migración de un servidor.
¿Estás preparando el alojamiento de un sistema?
Cuéntanos qué información necesitas conservar y cómo trabaja el negocio. Podemos conversar sobre su alojamiento en Acinsoft y las opciones de respaldo que habría que contemplar.
Conocer el hosting administrado