Cómo comprobar que tus copias de seguridad se pueden restaurar

Para comprobar que una copia de seguridad se puede restaurar, no basta con ver un archivo ZIP o el mensaje «backup completado». Haz una restauración periódica en un entorno aislado, verifica datos y funciones, y documenta cuánto tardó. La prueba debe proteger la producción: nunca importes una base antigua sobre una tienda con pedidos nuevos para «ver si funciona».

Define qué significa recuperada

Antes del ensayo, anota fecha de la copia, componentes incluidos y el punto de recuperación esperado. Reúne archivos, base de datos, medios y parámetros que no deban guardarse en público. Define pruebas mínimas: portada, páginas internas, acceso administrativo, imágenes, formularios, correo y, si aplica, catálogo y pedidos. Calcula el tiempo máximo que el negocio toleraría fuera de servicio y compáralo con la duración real del ensayo; no inventes un objetivo universal.

Ensaya en un destino separado

1. Prepara staging con acceso restringido, URL no indexable y pasarelas/correos reales desactivados. Asegúrate de que no puede sobrescribir datos de producción ni enviar avisos a clientes.
2. Restaura archivos y base de datos de la misma copia siguiendo el método documentado. Ajusta la configuración al entorno de prueba sin exponer secretos. Comprueba que no falten tablas, medios, enlaces ni permisos.
3. Compara recuentos y muestras verificables: entradas, usuarios, productos y pedidos hasta la fecha de la copia. Si faltan datos anteriores a ella, la copia puede estar incompleta; si faltan posteriores, eso refleja el punto de recuperación, no necesariamente un fallo.
4. Prueba el recorrido de usuario y registra errores, duración, pasos manuales y dependencias externas que no se restauraron. Deja constancia de quién realizó y revisó el ensayo.

La documentación de WordPress sobre respaldos subraya la importancia de archivos y base de datos. Repite la prueba cuando cambien plugin de copias, proveedor o arquitectura. Una restauración que funcionó hace un año no certifica las copias actuales.

Resuelve el desfase de datos vivos

En producción, analiza qué datos se generaron después de la copia: formularios, clientes, pagos, pedidos y existencias. Decide cómo conciliarlos antes de sustituir una base. La guía para preservar pedidos explica por qué una recuperación de tienda exige más que pulsar «restaurar». Consulta también cuándo necesitas una copia fuera del servidor. Si el ensayo falla, conserva el respaldo original y corrige el procedimiento; no declares recuperable una copia no probada.

Anota el resultado del ensayo, el responsable y la frecuencia en tu plan de continuidad de la web; así la prueba se convierte en un procedimiento utilizable.

Prueba sin tocar producción

Aísla red, cuentas, correo saliente, cron y pasarelas del entorno de ensayo; no basta cambiar la URL. Usa una copia de un punto identificado, conserva intacta la web viva y registra cada ajuste que hizo falta para arrancar. Comprueba que un segundo operador autorizado puede obtener la clave y seguir el procedimiento escrito. No uses datos de clientes reales en un staging abierto o indexable.

Ejemplo: la restauración muestra la portada, pero el formulario no envía porque el destino de prueba tiene bloqueado SMTP. Registra ese bloqueo previsto como parte del ensayo y verifica el flujo con un buzón de prueba; no envíes mensajes a clientes para «comprobar». En una tienda, concilia recuentos de pedidos hasta la fecha de la copia y prueba la compra solo en sandbox. Si la prueba revela ficheros ausentes o una clave inaccesible, sigue las señales de copias defectuosas y corrige la política antes de darla por válida.