Una notificación de backup correcto demuestra que se ejecutó un proceso, no que la web pueda recuperarse. Una prueba real reconstruye el sitio en aislamiento, mide el trabajo y registra defectos antes de que una emergencia los convierta en urgentes.
Define el objetivo de recuperación
Elige la fecha exacta y especifica qué debe volver: archivos, base, uploads, configuración y dependencias externas. Define un tiempo objetivo y los recorridos críticos del negocio.
No uses producción como destino. Prepara un hostname de staging restringido o un entorno local no indexable.
Inventaría el conjunto
Lista archivos, SQL y volúmenes multipartes con tamaño y fecha. Confirma que claves de cifrado, credenciales del almacenamiento y software de restauración están disponibles para personas autorizadas.
sha256sum wordpress-files.tar.gz wordpress.sql.gzEl hash detecta daños en la transferencia, pero no demuestra que el contenido sea completo.
Prepara un destino aislado
Usa un document root y base vacíos. Iguala inicialmente PHP y extensiones, con suficiente disco, inodos y cuota MySQL. Bloquea acceso público y correo transaccional saliente.
Añade noindex como segunda precaución, no como única barrera para una copia con datos personales.
Restringe también el acceso por autenticación.
Restaura sin depender del origen
Actúa como si producción no estuviera disponible. Descarga desde la ubicación documentada, extrae e importa usando el procedimiento guardado.
Registra comandos, tiempo y errores. Si hace falta una contraseña o licencia no documentada, has encontrado un defecto de recuperación aunque alguien termine localizándola.
Reconfigura el entorno con seguridad
Crea credenciales de staging y ajusta wp-config.php. Sustituye dominios con una herramienta compatible con serialización. Desactiva pagos, CRM, webhooks y SMTP reales para no contactar clientes.
Revisa rutas absolutas y ajustes propios del servidor. Regenera cachés solo cuando los datos de origen sean correctos.
Verifica la integridad de los datos
Compara tablas, filas seleccionadas, últimas entradas y registros de negocio con la hora prevista. Abre medios antiguos y recientes y comprueba que el fichero existe, no solo su referencia.
Revisa usuarios y roles sin exponer contraseñas. Nunca envíes por email una lista de usuarios restaurada.
Ejercita las funciones de WordPress
Prueba login, generación de restablecimiento sin entrega, guardado del editor, upload, enlaces permanentes, búsqueda, REST y cron. Para formularios o comercio usa endpoints sandbox y registros claramente marcados.
Revisa logs PHP, web y WordPress. Una portada visualmente correcta puede esconder trabajos en segundo plano fallidos.
Mide el rendimiento de recuperación
Registra el tiempo para obtener acceso, descargar, restaurar, configurar y validar. Anota pasos manuales y mayor demora. Compáralo con los objetivos de recuperación y punto de datos.
Si la importación domina, mejora el método de servidor en lugar de elevar timeouts del navegador.
Prueba también las rutas de fallo
Confirma qué hacer si falta un volumen, el almacenamiento rechaza acceso o el destino no tiene espacio. Simula con copias de prueba, nunca dañando el único conjunto.
El procedimiento debe indicar cuándo parar, quién autoriza otra fecha y cómo preservar el error. Así una decisión improvisada se convierte en una rama controlada.
Limpia la prueba responsablemente
Guarda el informe no secreto y elimina entorno y archivos temporales según la política. Revoca credenciales y confirma que DNS y reglas de acceso ya no exponen datos.
Conserva la copia original hasta que expire la retención.
Repite con una frecuencia útil
Prueba después de cambios importantes de hosting, PHP, herramienta o arquitectura y periódicamente. Rota las fechas para no seleccionar siempre la misma copia conocida.
El mantenimiento recurrente debe seguir éxito, duración y defectos pendientes. El resultado buscado es evidencia de recuperación, no otro panel verde.