Copias de seguridad de WordPress: cómo hacerlas y comprobar que sirven

Cuando administras entre 5 y 30 sitios de clientes, la copia de seguridad de WordPress no es una casilla que se tilda una vez y se olvida: es el motivo por el que un desastre —una actualización que rompe el sitio, un hackeo, un error humano al borrar lo que no debía— se resuelve con un trámite en lugar de convertirse en una noche perdida y una llamada incómoda al cliente.
El problema casi nunca es la falta de copias.
Es que nadie las comprobó nunca: se generan, se guardan y se dan por buenas hasta el día en que hacen falta de verdad.

Esa es la idea central de esta guía: una copia de seguridad que nunca restauraste no está comprobada, es una suposición.
Guardar el archivo es la mitad del trabajo.
Vamos por la otra mitad: qué debe incluir una copia completa, cada cuánto conviene hacerla, dónde guardarla, cómo comprobar que sirve y cómo restaurarla cuando hace falta de verdad.

Qué es una copia de seguridad de WordPress

Es una copia de los archivos del sitio y de su base de datos, guardada fuera del servidor, que permite volver a un estado anterior.
Ninguna de las dos piezas sirve sola: los archivos no tienen el contenido y la base de datos no tiene los temas ni los plugins.

En la práctica son tres pasos:

1. Hacer la copia de los archivos y de la base de datos.
2. Guardarla en un lugar distinto del servidor del sitio.
3. Restaurarla una vez en un entorno de prueba, para comprobar que funciona.

Cada paso tiene su sección más abajo.

Qué incluye una copia de seguridad completa de WordPress

Un sitio WordPress no es un bloque único de datos: son dos piezas separadas que hay que respaldar juntas, y ninguna sirve sin la otra, según explica la documentación oficial de WordPress sobre copias de seguridad.

• Los archivos: el núcleo de WordPress, los temas, todos los plugins, la carpeta wp-content/uploads con las imágenes y archivos subidos, y dos archivos de configuración que casi nadie mira: wp-config.php y .htaccess.
• La base de datos: contenido, usuarios, comentarios, opciones del sitio y la configuración de los plugins.
  Vive en un motor MySQL o MariaDB, separado del sistema de archivos, así que copiar la carpeta del sitio por FTP no es una copia de seguridad completa.

Si guardas solo los archivos, puedes reinstalar WordPress y los plugins, pero pierdes el contenido.
Si guardas solo la base de datos, tienes el contenido pero no las imágenes ni la configuración que depende de archivos en disco.
Necesitas las dos cosas, generadas en el mismo momento.

Cada cuánto conviene hacerla

No hay una frecuencia única para todos los sitios que administras.
La documentación de WordPress da esta referencia: semanal para sitios de bajo movimiento, diaria para sitios de alta actividad —tiendas, sitios con publicaciones frecuentes o muchos usuarios registrados— y siempre antes de una actualización, sin excepción.

Con sitios de distintos clientes bajo gestión, eso se traduce en definir la cadencia por sitio, no por costumbre.
Un sitio corporativo que se actualiza una vez al mes no necesita copia diaria; una tienda con pedidos constantes sí.
Lo que no cambia es el "antes de actualizar": el núcleo, un tema o un plugin es el momento de mayor riesgo, y es cuando más rápido necesitas poder volver atrás si algo rompe.

Dónde guardarla: la regla 3-2-1

La regla 3-2-1 es la forma más simple de no quedarte sin copia de seguridad de WordPress justo cuando la necesitas: al menos 3 copias, en 2 soportes o proveedores distintos, con 1 de ellas fuera del servidor donde vive el sitio.

Ese último punto es el que más se salta.
Si la única copia de un sitio queda guardada en el mismo hosting, un problema del servidor —una caída, un hackeo, una cuenta suspendida— se lleva puesta la copia junto con el sitio.
La documentación oficial de WordPress lo plantea en términos parecidos: conservar entre 3 y 5 copias recientes, repartidas en ubicaciones distintas —por ejemplo el propio servidor, un almacenamiento en la nube (Google Drive, Dropbox) y una copia local— para no depender de un único punto de falla.

Con varios sitios de clientes distintos, la regla 3-2-1 solo funciona si es igual en todos: mismo destino externo, mismo criterio de cuántas copias conservar.
Un destino distinto por sitio, porque "cada cliente ya tenía algo configurado", es la forma más fácil de terminar sin saber, en el momento en que hace falta, dónde quedó la última copia de un sitio en particular.

Cómo comprobar que una copia sirve

Este es el paso que casi nadie hace, y es el que separa una copia de seguridad real de un archivo con el nombre "backup" guardado en una carpeta.
Un respaldo puede fallar por motivos que no se ven hasta que lo necesitas: una descarga que se cortó a la mitad, una base de datos exportada con tablas incompletas, un plugin de copias que llevaba meses fallando en silencio sin que nadie revisara el registro.

Comprobar que sirve significa una sola cosa: restaurarla, al menos una vez, en un sitio que no sea el de producción.
Un entorno de pruebas o una copia de staging alcanza.
No hace falta hacerlo cada semana con cada sitio, pero sí de forma periódica y rotativa: si administras veinte sitios, prueba restaurar uno o dos por mes hasta haber pasado por todos los sitios bajo gestión.
Si el archivo se descomprime, la base de datos se importa sin errores y el sitio restaurado carga con el contenido esperado, la copia está comprobada.
Si no, mejor descubrirlo en una prueba tranquila que en medio de una emergencia con el cliente esperando.

Una copia que nunca se restauró no está comprobada: es, en el mejor de los casos, una copia probablemente buena.
La diferencia entre esas dos frases es la que decide si un desastre te cuesta un trámite o una noche entera.

Cómo restaurar una copia de seguridad de WordPress

La restauración con UpdraftPlus se hace siempre desde el wp-admin del propio sitio, no desde un panel externo: en Ajustes → UpdraftPlus Backups, en la sección de copias existentes, seleccionas la fecha que quieres restaurar y pulsas el botón de restaurar, según describe el blog de UpdraftPlus.
El plugin abre un cuadro de diálogo para elegir qué restaurar antes de confirmar, y al terminar muestra un aviso de que la restauración se completó.

Antes de lanzar una restauración real, conviene revisar tres cosas que la propia documentación de UpdraftPlus sobre qué saber antes de restaurar señala como causas frecuentes de restauraciones que se cuelgan a mitad de camino:

• Recursos del servidor: un memory_limit de al menos 512 MB y un max_execution_time de 900 segundos.
  Con hostings más ajustados, la restauración se puede cortar antes de terminar.
• Espacio en disco: al menos un 50% libre en el servidor, porque UpdraftPlus usa espacio temporal antes de mover los archivos a su ubicación final.
• Proxies como Cloudflare: conviene desactivarlos mientras dura la restauración, porque sus tiempos de espera suelen ser más cortos que los del hosting y pueden cortar el proceso a mitad de camino.

En sitios grandes, restaurar todo de una vez tiene más probabilidades de fallar por tiempo de espera: conviene restaurar cada componente por separado, dejando la base de datos para el final.

Errores frecuentes

• Confiar en la copia del hosting sin comprobarla.
  Cada proveedor decide qué incluye, cuánto la conserva y si se puede descargar completa.
  Sin verificarlo, es una suposición más.
• Guardar la única copia en el mismo servidor que el sitio.
  Rompe la regla 3-2-1 en el punto que más importa: si el servidor falla, se lleva la copia con él.
• No restaurar nunca, ni siquiera una vez, para comprobar que el archivo funciona.
  Es el error central de esta guía: sin esa prueba, no hay forma de saber si la copia sirve hasta que ya es tarde.
• No respaldar antes de actualizar.
  El momento de mayor riesgo es también el que más se salta, casi siempre por apuro.
• Perder de vista qué sitio tiene qué frecuencia y qué destino.
  Con 5 sitios se puede llevar en la cabeza.
  Con 20 o 30, sin un panel centralizado que muestre el estado de cada uno, la respuesta a "¿este sitio tiene copia de esta semana?" pasa a ser "no lo sé con certeza".

Cómo lo resuelve TutorWP

TutorWP no reemplaza a UpdraftPlus ni restaura copias de seguridad de forma automática: eso sigue siendo un paso manual, desde el wp-admin de cada sitio, con UpdraftPlus.
Lo que hace TutorWP es centralizar el estado de las copias de todos tus sitios en un solo panel —cuándo se hizo la última, si está al día o atrasada— y permitirte dispararlas cuando lo necesites, sin entrar sitio por sitio.
El archivo de la copia nunca pasa por los servidores de TutorWP: viaja directo desde cada sitio al destino que ya tengas configurado.

Si administras varios sitios de clientes, la parte que más tiempo saca no es hacer la copia: es acordarte de revisar que cada una salió bien.
Por eso construimos TutorWP, para ver ese estado de un vistazo en todos los sitios a la vez.
Si quieres saber quiénes estamos detrás, conoce al equipo.