Casi todas las webs en WordPress tienen algún plugin de copias de seguridad. Pocas veces alguien comprobó que esas copias sirven para recuperar la web. Y la mayoría de la gente se entera de que no servían el día que las necesita: después de una actualización que rompió todo, un hackeo o un error del hosting.
Un aviso de «copia completada» dice que se generó un archivo. No dice que ese archivo tenga todo lo necesario, ni que se pueda restaurar. La única forma de saberlo es probarlo. Esta guía explica cómo hacerlo sin tocar tu web real.
- Una copia completa tiene dos partes: los archivos de la web y la base de datos. Sin cualquiera de las dos, no hay forma de recuperar el sitio entero.
- La prueba de verdad es restaurar la copia en un lugar aparte, nunca encima de la web que funciona, y revisar que todo esté.
- Anota qué se recuperó, qué faltó y cuánto tardó. Ese tiempo es lo que tu web estaría caída si hoy pasara algo.
Qué tiene que tener una copia completa
WordPress guarda tu web en dos lugares distintos. Los archivos están en el servidor: el tema, los plugins, las imágenes que subiste y la configuración. El contenido y los ajustes están en una base de datos aparte: las páginas, las entradas, los usuarios, los pedidos. La documentación oficial es clara: hacen falta las dos para recuperar un sitio típico completo.
Los archivos del propio WordPress no hace falta copiarlos: según la documentación, se pueden reemplazar con una descarga nueva. Lo que es tuyo es lo de la tabla.
Una confusión frecuente: la opción Herramientas → Exportar del panel no es una copia de seguridad. Exporta el contenido (entradas, páginas, comentarios) para llevarlo a otro WordPress, pero no incluye el tema, los plugins ni sus ajustes.
Revisa la copia antes de abrirla
Antes de restaurar nada, hay cuatro cosas que se ven desde el panel del plugin o del hosting:
- La fecha. ¿La última copia es de ayer o de hace tres meses? Una copia programada puede dejar de ejecutarse sin avisar.
- Qué incluye. Muchos plugins dejan elegir entre base de datos, archivos o ambos. Comprueba que estén las dos partes.
- El tamaño. Si la copia de hoy pesa mucho menos que las anteriores, algo se quedó fuera.
- Dónde está guardada. Una copia que vive solo en el mismo servidor que la web se pierde junto con la web. La documentación de WordPress recomienda guardar varias copias recientes en lugares distintos: el hosting, un servicio en la nube y una computadora propia.
Sobre la frecuencia, la misma guía da una referencia: semanal para un sitio que cambia poco, diaria si hay mucha actividad (una tienda, un sitio con formularios o publicaciones frecuentes), y siempre antes de actualizar.
Ensaya la restauración en un lugar aparte
Esta es la parte que casi nadie hace, y la única que prueba algo. La regla es simple: nunca ensayes encima de la web real. Restaurar reemplaza lo que hay. Si la copia está mal, te quedas sin la copia y sin la web.
Opciones para hacerlo aparte, de la más cómoda a la más técnica:
- El entorno de pruebas del hosting (a veces llamado staging), si tu plan lo incluye. Es una copia de la web en otra dirección.
- Un subdominio o una carpeta en el mismo hosting, con una base de datos nueva.
- Una instalación en tu computadora, con alguna herramienta para correr WordPress en local.
Antes de restaurar: que la copia no actúe como la web real
Una copia restaurada es una web que funciona. Puede enviar correos, procesar pagos y aparecer en Google. Antes de abrirla:
El orden y la dirección
La documentación de WordPress indica restaurar primero los archivos y después la base de datos, y ajustar wp-config.php si los datos de conexión de la base nueva son distintos.
Hay un detalle que confunde la primera vez: la base de datos guarda la dirección de tu web. Si restauras en otra dirección, la copia intentará llevarte a la web real. Para una prueba, WordPress explica que hay que cambiar temporalmente siteurl y home en la tabla de opciones. Si además hace falta reemplazar la dirección vieja en el contenido, la misma guía advierte que un buscar y reemplazar hecho a mano puede romper datos de temas y widgets, y recomienda herramientas pensadas para eso.
Qué revisar en la copia restaurada
Que la portada cargue no alcanza. Recorre la copia como lo haría un cliente y como lo harías tú en el panel:
Si algo falla, la copia no es fiable aunque el plugin diga lo contrario. Las causas típicas son que falte una de las dos partes o que la copia se corte por tamaño. Corrige la configuración, genera una copia nueva y vuelve a probar.
Anota el resultado
Basta una línea en una hoja de cálculo por cada prueba:
- Fecha de la prueba y fecha de la copia usada.
- Dónde se restauró y quién lo hizo.
- Qué se recuperó bien y qué faltó.
- Cuánto tardó, desde que empezaste hasta tener la copia funcionando.
Ese último dato es el más útil. Es, más o menos, el tiempo que tu web estaría caída si hoy tuvieras que recuperarla. Si son cuatro horas y vendes por la web, ya sabes cuánto vale tener la copia bien hecha.
¿Cada cuánto repetir la prueba? No hay una regla oficial. Nuestro criterio: siempre que cambies de plugin de copias o de hosting, después de un cambio grande en la web, y de forma periódica, por ejemplo una vez por trimestre.
Si un día tienes que restaurar de verdad
Restaurar la web real reemplaza todo lo que pasó después de la fecha de la copia. En una tienda o un sitio con formularios, eso son pedidos y consultas que se pierden. Antes de restaurar:
- Guarda lo que hay ahora, aunque esté roto: una copia del estado actual te permite recuperar después los datos recientes.
- Exporta lo que entró desde la fecha de la copia: pedidos, consultas, nuevos usuarios. Si no se puede, anota al menos cuáles fueron.
- Elige la copia más reciente que funcione, no la más reciente a secas. Si el problema empezó hace una semana, la copia de ayer puede traerlo consigo.
Si el problema es que los formularios dejaron de llegar después de restaurar, en el formulario de WordPress dice «enviado», pero el correo no llega está el recorrido para encontrar dónde se corta.
Cómo lo hacemos nosotros
En las webs que mantenemos, las copias se guardan fuera del servidor y la restauración se prueba, no se da por hecha: verificar las copias es parte de la rutina mensual. Y si estás por hacer una web nueva, lo hablamos desde el principio en desarrollo WordPress.
Una copia que nunca se restauró es una suposición. Probarla es la diferencia entre recuperar la web o empezar de cero.
