El panel indica que la copia de seguridad terminó, el archivo aparece en el almacenamiento y la rutina continúa. Es un buen comienzo. Sin embargo, para saber si la tienda podría volver a operar, falta responder una pregunta práctica: ¿alguien ha restaurado esa copia y comprobado el resultado?
La recuperación implica algo más que abrir la página de inicio. Productos, imágenes, pedidos, configuraciones e integraciones deben formar un conjunto coherente. Una prueba planificada muestra qué está protegido, qué depende de otro proveedor y cuánto trabajo queda hasta la reanudación.
Entiende qué contiene realmente la copia
En PrestaShop, la copia de seguridad debe contemplar archivos y base de datos. Las imágenes, los temas y los módulos forman parte de los archivos; conservar solo la base de datos deja fuera componentes de la tienda. La documentación oficial describe ambas partes. Guía de copias de seguridad de PrestaShop.
Prepara un inventario de tu operación. Incluye la base de datos, archivos subidos, personalizaciones, configuraciones y recursos almacenados fuera del servidor principal. Confirma que la estrategia produce un estado coherente entre la base de datos y los archivos, incluso si la tienda recibe cambios durante la copia. Identifica también lo que administra el alojamiento o los servicios externos.
Conserva un registro de las versiones y dependencias necesarias para reconstruir el entorno. Documenta dónde están las configuraciones del dominio, los certificados, las tareas programadas y las integraciones. No todo debe estar dentro del mismo archivo, pero cada componente necesario debe tener un responsable y una vía de recuperación conocida.
Define cuánto puedes perder y cuánto puedes esperar
Dos siglas ayudan a convertir una intención general en objetivos:
- RPO es la ventana máxima de pérdida de datos que acepta la operación.
- RTO es el tiempo máximo aceptable de interrupción hasta recuperar el servicio.
Estos objetivos deben reflejar el impacto en el negocio, no solo la frecuencia disponible en la herramienta. Definiciones en AWS Well-Architected Framework.
Imagina, como ejemplo hipotético, un fallo a las 15:00 con el último punto recuperable a las 12:00. Hay una ventana de tres horas de cambios que evaluar. Esto no significa automáticamente tres horas de pérdida definitiva: otros registros pueden ayudar en la conciliación, pero ese trabajo debe estar previsto.
El tiempo de recuperación incluye localizar la copia, obtener acceso, preparar el entorno, restaurar, validar y decidir la reapertura. Cronometra todo el ensayo. Medir solo la importación de la base de datos oculta etapas que también consumen tiempo.
Protege la copia y el acceso a ella
Una copia de seguridad puede concentrar datos personales e información comercial. Restringe los permisos a las personas y los procesos que realmente la necesitan. Evita archivos en directorios públicos, enlaces abiertos y credenciales compartidas en mensajes.
Planifica copias protegidas frente a la pérdida o el compromiso del entorno principal. CISA recomienda copias cifradas, mantenidas fuera de línea, y pruebas regulares de disponibilidad e integridad. La implementación debe considerar la estructura de la operación. Guía StopRansomware de CISA.
Comprueba también quién puede recuperar las claves de cifrado y los accesos cuando sea necesario. Documenta el procedimiento sin incluir secretos en las propias instrucciones. Una copia protegida, pero inaccesible para el equipo autorizado durante el incidente, no resuelve la recuperación.
Restaura en un entorno aislado
La primera prueba no debe sustituir a la tienda pública. Prepara un entorno separado, con base de datos y almacenamiento propios, acceso restringido e identificación clara de que se trata de un ensayo.
Antes de iniciar la aplicación restaurada, bloquea los efectos externos. Desactiva las tareas programadas y los consumidores de colas; impide el envío de mensajes y las llamadas a servicios de producción. Sustituye las credenciales por equivalentes de prueba cuando el escenario requiera una integración.
Revisa especialmente pagos, webhooks, ERP, emisión de documentos fiscales y transportistas. Una base restaurada puede contener pedidos pendientes y colas antiguas. Ejecutarlos sin aislamiento puede repetir acciones que ya ocurrieron.
Utiliza datos ficticios o anonimizados en las comprobaciones. Cuando sean indispensables datos reales, limita el acceso y la retención a lo necesario. La prueba debe demostrar la recuperación sin crear una segunda exposición de la base de clientes.
Valida la operación recuperada
Empieza por la integridad técnica: ¿la restauración terminó sin errores? ¿Están presentes los componentes esperados? ¿La aplicación utiliza la base de datos correcta? ¿Las versiones y los permisos son adecuados?
Después, revisa muestras representativas de productos, imágenes, clientes y pedidos hasta el punto de recuperación elegido. Compara valores, estados y relaciones entre registros. Los recuentos ayudan, pero por sí solos no demuestran que el contenido sea correcto.
Recorre la búsqueda, el carrito, el inicio de sesión y la administración. Para el checkout y los pagos, utiliza solo sandbox y medios de prueba, sin compras reales. Evalúa las integraciones en entornos específicos de pruebas o con respuestas simuladas, manteniendo los bloqueos de producción.
Registra también lo que quedó fuera del ensayo. Una dependencia no probada debe aparecer como pendiente, con responsable y siguiente paso, en lugar de desaparecer bajo la etiqueta “copia validada”.
Convierte la prueba en un procedimiento utilizable
Guarda la fecha de la copia, su alcance, el resultado de la prueba, los tiempos observados y los ajustes necesarios. Mantén las instrucciones disponibles fuera de la infraestructura que pretenden recuperar.
Repite el ensayo según el riesgo de la operación y después de cambios relevantes, como migraciones o nuevas integraciones. Comprueba las alertas de fallo, la retención y la capacidad de almacenamiento: una rutina silenciosa puede dejar de producir copias útiles.
En una recuperación real, preserva evidencias y planifica la conciliación de los cambios posteriores al punto restaurado. Cualquier sustitución de producción exige una decisión explícita y un procedimiento propio, no una secuencia improvisada de eliminaciones.
Si todavía no puedes describir ese camino, habla con AGTI sobre la revisión del proceso de copias de seguridad y recuperación de tu tienda. El objetivo es pasar de confiar en un archivo a una recuperación que el equipo sepa ejecutar y verificar.