Los archivos pueden restaurarse bien mientras wp-config.php apunta a una base antigua, vacía o de otra web. El sitio puede mostrar el instalador, contenido desactualizado o «Error establishing a database connection» aunque plugins y subidas parezcan recientes.
No ejecutes el instalador: crearía tablas nuevas en la base equivocada y complicaría el análisis.
Conserva el estado actual
Crea desde cPanel una copia o snapshot de los archivos y de cada base candidata antes de importar de nuevo. Anota hora, nombre del backup, origen y errores.
Impide escrituras nuevas o activa un mantenimiento adecuado mientras identificas el conjunto correcto. Nunca sobrescribas la única copia anterior al incidente.
Lee la configuración sin exponer secretos
Revisa DB_NAME, DB_USER, DB_HOST y $table_prefix, pero no publiques contraseñas.
define( 'DB_NAME', 'example_database' );
$table_prefix = 'wp_';
Busca definiciones duplicadas o sustituciones por entorno y confirma el document root activo. Unos archivos restaurados desde otra web pueden incluir su configuración. Rota credenciales que hayan quedado expuestas.
Inventaría las bases de cPanel
Lista nombres, tamaños, usuarios y permisos. En phpMyAdmin, inspecciona prefijos y fechas recientes mediante consultas de solo lectura.
SELECT ID, post_date, post_title
FROM wp_posts
WHERE post_type IN ('post','page')
ORDER BY ID DESC
LIMIT 10;
Usa el prefijo real y no difundas títulos privados.
Relaciona las fechas de los backups
La copia de archivos y el volcado SQL pueden haberse creado en momentos distintos. Compara fechas de uploads, versiones de plugins y contenido más reciente.
Identifica el SQL por siteurl, home, prefijo y contenido, no únicamente por el nombre. La base más grande tampoco tiene que ser la correcta: cachés y logs pueden dominar el tamaño.
Restablece usuarios y permisos
cPanel puede importar una base sin asociarle el usuario de WordPress. Desde MySQL Databases, crea o vincula un usuario con los permisos mínimos necesarios.
Evita privilegios globales y no dejes la contraseña en el historial. Conserva temporalmente el usuario anterior hasta validar y revoca después accesos sin uso.
Importa en un destino separado
Crea una base nueva e importa allí el volcado seleccionado mediante cPanel o el cliente MySQL. Guarda errores y compara tablas y recuentos.
No importes repetidamente sobre un destino medio poblado: aparecerán claves duplicadas y fechas mezcladas. Comprueba charset, collation y límites para archivos grandes.
Cambia la conexión de forma atómica
Actualiza juntos nombre, usuario y contraseña en wp-config.php, manteniendo sintaxis y permisos. Limpia la caché de objetos persistente para no mostrar opciones antiguas.
No cambies URLs hasta confirmar que la base pertenece al dominio. Después usa herramientas compatibles con serialización. Guarda la configuración de rollback fuera de la raíz pública.
Reconcilia datos posteriores
Lista contenido, usuarios, comentarios, formularios y operaciones creados después del volcado elegido. Compara IDs y fechas con las bases actuales.
No copies filas arbitrarias: los IDs y metadatos relacionados pueden colisionar. Usa exportaciones o API de la aplicación y ensaya en staging. Los adjuntos deben trasladarse junto con sus archivos.
Los efectos externos de correos y pagos se reconcilian mediante las referencias del proveedor, no copiando filas.
Revisa opciones serializadas y de entorno
Un volcado de staging puede contener constructores serializados, prefijos de caché, cron y URLs absolutas. Ejecuta simulaciones con WP-CLI y usa herramientas de migración del plugin.
No copies wp_options completo desde otra base. Revisa individualmente siteurl, home, plugins, tema, roles, cron e integraciones.
Verifica la restauración
Prueba web pública, login, editor, guardado, medios, plugins, cron y registros recientes. Compara cantidades y fechas con la copia elegida.
Comprueba sistemas externos por eventos posteriores que deban recuperarse. Una restauración real de WordPress siempre empareja archivos, base de datos, hora y dominio.