Tener una copia de seguridad no significa necesariamente poder recuperar una web cuando algo falla. El backup puede estar incompleto, puede no incluir la base de datos correcta, puede no contener los archivos recientes o puede depender de un sistema que nadie ha probado restaurar.
El problema no suele aparecer mientras las copias se generan cada noche. Aparece cuando una actualización deja de funcionar, el servidor falla o hay que recuperar una tienda con pedidos recientes. En ese momento no sirve saber que existe una carpeta llamada “backups”: hay que saber qué se puede restaurar, cuánto se perdería y cuánto tarda el proceso.
La forma razonable de comprobarlo no es restaurar sin más sobre la web pública. Es repetir el proceso en un entorno aislado y documentar el resultado.
Índice
- Antes de probar: define qué debería recuperar esa copia.
- Prepara un entorno de pruebas separado.
- Restaura archivos y base de datos como si fuera una recuperación real.
- Comprueba la integridad de los archivos restaurados.
- Comprueba la base de datos más allá de que el administrador permita entrar.
- Prueba los recorridos que sostienen la actividad de la web.
- Comprueba los correos sin provocar envíos reales.
- No olvides DNS, SSL y configuraciones que viven fuera de WordPress.
- Define cada cuánto debes hacer esta prueba.
- Convierte la prueba en un procedimiento, no en una intuición.
Antes de probar: define qué debería recuperar esa copia
Una restauración no es correcta solo porque WordPress carga. Antes de empezar, anota qué partes de la web son críticas para el negocio. Así podrás validar algo más útil que una pantalla de inicio aparentemente normal.
Como mínimo, identifica:
- La Fecha y hora exactas de la copia.
- Los Archivos incluidos, especialmente
wp-content/uploads, plugins, tema activo y ficheros de configuración que formen parte del backup. - La Base de datos incluida y el nombre de la instalación a la que pertenece.
- Los Datos que pueden cambiar entre copia y restauración, como pedidos, formularios, reservas, usuarios, comentarios o contenidos nuevos.
- Los Servicios externos que dependen de esa web, como correo SMTP, pagos, mapas, APIs, analítica o pasarelas de envío.
- El Procedimiento de recuperación disponible y quién puede ejecutarlo si hace falta.
Una copia de archivos sin base de datos puede dejar una instalación incoherente. Una copia de base de datos sin uploads puede recuperar páginas que apuntan a imágenes inexistentes. Y una copia completa pero demasiado antigua puede implicar una pérdida de datos que hay que conocer antes de una incidencia.
Prepara un entorno de pruebas separado
La prueba debe hacerse en un staging, en un subdominio no indexable o en una instancia temporal separada. Nunca conviene utilizar el dominio público como laboratorio.
El entorno de pruebas debería cumplir estas condiciones:
- No Recibir tráfico real ni indexarse en buscadores.
- No Enviar correos a clientes o suscriptores. Configura un buzón de pruebas, desactiva envíos o usa un interceptor de correo.
- No Cobrar pagos ni llamar a sistemas de producción. Desactiva o sustituye las claves de pasarelas, ERP y APIs sensibles.
- No Usar el mismo directorio ni la misma base de datos que la web pública.
- Tener Protección de acceso mientras dure la revisión.
Si la copia se restaura desde un panel de hosting, revisa con cuidado el destino seleccionado. En una restauración manual, importa la base de datos en un esquema distinto y utiliza una copia de los archivos en otra ruta. Es un paso lento, pero evita que una comprobación se convierta en una incidencia.
Restaura archivos y base de datos como si fuera una recuperación real
La prueba solo aporta confianza si se parece al proceso que usarías en una emergencia. No basta con descargar un ZIP y comprobar que se puede abrir.
Restaura ambos componentes y registra estos datos:
- La Hora de inicio y fin.
- El Tamaño de los archivos restaurados.
- El Tamaño y la fecha del volcado de base de datos.
- Los Errores devueltos por el panel, el importador o la consola.
- Las Acciones manuales necesarias para que la web vuelva a funcionar.
Este último punto es especialmente importante. Si una recuperación requiere editar wp-config.php, cambiar URLs, ajustar permisos o regenerar una configuración de caché, debe estar documentado. En una emergencia no quieres descubrir pasos ocultos ni depender de que una única persona recuerde cómo se hizo la última vez.
Comprueba la integridad de los archivos restaurados
Cuando el staging esté disponible, verifica que la restauración contiene lo que esperabas. No se trata solo de abrir la portada.
Revisa al menos:
- El Tema activo y sus personalizaciones.
- Los Plugins necesarios y su estado de activación.
- La Biblioteca multimedia, con imágenes antiguas y recientes.
- Los Archivos de configuración necesarios para la instalación.
- Los Directorios personalizados que puedan usar formularios, integraciones o importaciones.
- Los Permisos y el propietario de los archivos, si el entorno depende de una configuración concreta del servidor.
Si tienes acceso por línea de comandos, puedes añadir comprobaciones de integridad del núcleo y extensiones cuando el proveedor del componente publique checksums. Su resultado no sustituye a una revisión funcional, pero ayuda a detectar que la copia está incompleta o que se han mezclado archivos de otro estado.
Comprueba la base de datos más allá de que el administrador permita entrar
La base de datos concentra buena parte de lo que no se ve al mirar una página pública: usuarios, ajustes, pedidos, formularios, enlaces internos, contenidos y configuraciones de plugins.
Después de restaurarla, confirma:
- Que Puedes iniciar sesión con una cuenta de prueba o una cuenta administradora autorizada.
- Que Los usuarios esperados existen y conservan sus roles.
- Que Las páginas y entradas relevantes se muestran sin contenido roto.
- Que Los ajustes principales se han recuperado, incluidos enlaces permanentes, idioma, zona horaria y configuración del tema.
- Que Los formularios, reservas o pedidos históricos aparecen según corresponda al tipo de web.
- Que Las URLs internas no siguen apuntando al dominio de producción cuando la prueba usa staging.
No conviene cambiar contraseñas de usuarios reales durante una restauración de prueba. Si necesitas entrar, crea una cuenta temporal en el staging o usa una cuenta de pruebas creada expresamente para estas revisiones.
Prueba los recorridos que sostienen la actividad de la web
Una portada correcta no demuestra que la recuperación sea válida. La lista de pruebas debe ajustarse al tipo de proyecto, pero hay recorridos que conviene comprobar siempre.
Para una web corporativa:
- La Navegación principal y las páginas de servicio.
- El Formulario de contacto, con recepción controlada en un buzón de pruebas.
- Las Páginas legales y los avisos de cookies.
- La Búsqueda interna, si se utiliza.
Para una tienda WooCommerce:
- El Catálogo, las variaciones y el stock visible.
- El Carrito y el checkout, sin procesar cobros reales.
- Los Correos transaccionales en modo seguro.
- El Área de cliente y los pedidos recuperados.
Para una web con reservas o membresías:
- El Flujo de reserva o acceso.
- La Disponibilidad, calendarios y zonas horarias.
- Las Integraciones externas necesarias.
- Los Permisos de cada tipo de usuario.
El objetivo no es probar todas las pantallas cada vez, sino identificar las funciones cuya caída tendría un impacto real y revisarlas de forma repetible.
Comprueba los correos sin provocar envíos reales
La restauración puede devolver a la vida una configuración SMTP antigua, una automatización o una cola de correos. Antes de probar formularios, revisa dónde se enviarán los mensajes.
Puedes utilizar un destinatario controlado, una herramienta de captura de correo en staging o desactivar temporalmente el envío saliente. Después, verifica que:
- El Formulario entrega el mensaje esperado.
- El Remitente y la respuesta no exponen datos incorrectos.
- No Se envían avisos a clientes, suscriptores o administradores de producción.
- Las Integraciones de marketing no añaden contactos reales durante la prueba.
Esta precaución evita una situación habitual: una restauración técnicamente correcta que genera correos masivos o datos duplicados en una plataforma externa.
No olvides DNS, SSL y configuraciones que viven fuera de WordPress
No todo lo necesario para recuperar una web está dentro del backup. El DNS, los certificados, reglas de CDN, redirecciones, cron del servidor y algunas claves de API pueden estar fuera de la instalación.
En la prueba, documenta si para una recuperación completa necesitas revisar:
- Los Registros DNS y el TTL previo a un cambio.
- El Certificado SSL y la renovación automática.
- Las Reglas de Cloudflare o de otro CDN.
- Las Redirecciones 301 del servidor.
- Las Tareas cron externas y los webhooks.
- Las Credenciales de pasarelas, SMTP, analítica o APIs.
No hace falta cambiar el DNS público para validar una restauración. Puedes usar un subdominio de staging o una resolución local controlada. Lo importante es saber qué dependencias externas tendrías que recuperar si el servidor original dejara de estar disponible.
Define cada cuánto debes hacer esta prueba
La frecuencia no depende solo de cuánto se generan las copias. Depende de cuánto puede cambiar el negocio y de cuánto daño provocaría una recuperación incompleta.
Como referencia:
- Una Web corporativa estable puede probar una restauración completa cada seis o doce meses, además de verificar periódicamente que las copias se están generando.
- Una Web con formularios, contenido frecuente o varias integraciones debería probarla al menos cada tres o seis meses.
- Una Tienda online, plataforma de reservas o membresía debería hacer pruebas trimestrales o tras cambios relevantes de infraestructura, pagos o plugins críticos.
- Una Web que ha sufrido una incidencia, una migración o un cambio de servidor debería validar una copia antes y después de la intervención.
También conviene repetir la prueba cuando cambias de proveedor de hosting, sistema de backup, versión mayor de PHP, arquitectura del servidor o herramienta de comercio electrónico.
Convierte la prueba en un procedimiento, no en una intuición
Al terminar, guarda un registro simple: fecha de la copia, fecha de la prueba, entorno usado, duración, componentes comprobados, errores encontrados y acciones necesarias para resolverlos.
Ese documento te permite responder con datos a preguntas importantes: cuál es la última copia comprobada, cuánto tarda una recuperación y qué datos se podrían perder. También evita que el procedimiento se pierda cuando cambia el proveedor o la persona que mantiene la web.
Si prefieres que esta validación forme parte de una rutina técnica, el servicio de mantenimiento WordPress incluye gestión de copias, actualizaciones seguras y comprobaciones operativas. Puedes complementarlo con la guía sobre qué se revisa cada mes en WordPress para entender el resto de controles preventivos.
Una copia de seguridad no es una garantía hasta que se ha restaurado y comprobado. Probarla antes de necesitarla convierte un archivo almacenado en un plan de recuperación real.
—