Cómo hacer una copia de seguridad de un sitio WordPress

Una copia de seguridad completa de WordPress es una copia de dos elementos capturados conjuntamente: tus archivos y tu base de datos MySQL. Si falta cualquiera de los dos, la restauración fallará. Esta guía cubre la forma fiable de hacerlo desde la línea de comandos — mysqldump, tar y un cron job que envía los archivos fuera del servidor — para que seas dueño de la copia de seguridad en lugar de depender de un plugin. También cubre las opciones de hosting y plugins de forma objetiva, y muestra los comandos de restauración que demuestran que una copia de seguridad realmente funciona.

¿Qué incluye una copia de seguridad completa de WordPress?

Un sitio WordPress consta de dos sistemas independientes, y una copia de seguridad debe capturar ambos. Los archivos son el núcleo de WordPress, todo lo que hay bajo wp-content — tus temas, plugins y la carpeta uploads (habitualmente la parte más grande) — más el archivo wp-config.php en la raíz. En Apache también conviene guardar .htaccess; en nginx o Caddy no hay ningún .htaccess que salvar, porque las reglas de reescritura viven en la configuración del servidor fuera del directorio web. La base de datos es una base de datos MySQL que contiene tus entradas, páginas, comentarios, usuarios, taxonomías y todas las configuraciones de plugins y temas.

El error más común entre principiantes es hacer una copia de seguridad de los archivos por FTP y olvidarse de la base de datos. Los temas y el núcleo pueden volver a descargarse; tu contenido, no. Si una “copia de seguridad” contiene solo archivos, el sitio restaurado cargará sin entradas ni configuraciones.

¿Cuáles son las tres formas de hacer una copia de seguridad de WordPress?

Existen tres enfoques prácticos, que intercambian comodidad por control.

Las copias del hosting son cómodas, pero no deberían ser tu única copia — los períodos de retención son cortos y, si el servidor se ve comprometido o falla, las copias almacenadas en él pueden perderse también. Los plugins como UpdraftPlus gestionan la programación y la subida a la nube desde el panel de administración, y son una opción razonable para usuarios no técnicos. La vía CLI es la que un desarrollador puede versionar, programar y auditar.

Hacer una copia de seguridad de WordPress desde la línea de comandos

La copia de seguridad por línea de comandos consta de tres pasos por SSH: volcar la base de datos, archivar los archivos y sacar ambos del servidor. Primero conéctate:

ssh user@example.com -p 2222

Luego archiva los archivos y vuelca la base de datos:

# Archivar los archivos del sitio desde el directorio superior a la raíz web
tar -zcf files.tar.gz public_html

# Volcar la base de datos con una instantánea consistente
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql

El flag --single-transaction es lo que hace que el volcado sea fiable en un sitio en producción. Solo las tablas InnoDB se vuelcan en un estado consistente; las tablas MyISAM o MEMORY pueden cambiar durante el volcado. Como WordPress utiliza InnoDB por defecto, --single-transaction es una opción mucho mejor que --lock-tables, ya que no necesita bloquear las tablas en absoluto — el sitio permanece activo mientras se ejecuta. Usa mysqldump, no mysqlpump — este último fue eliminado en MySQL 8.4, por lo que los scripts que lo llamen simplemente fallarán en servidores actuales.

Descarga ambos archivos con scp:

scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .

Un detalle que los tutoriales suelen omitir: scp usa -P en mayúscula para el puerto, mientras que ssh y mysqldump usan -p en minúscula (puerto y contraseña, respectivamente). Confundirlos es un error clásico que provoca fallos en los comandos.

Si tienes WP-CLI, wp db export es más limpio: ejecuta la utilidad mysqldump usando las credenciales DB_HOST, DB_NAME, DB_USER y DB_PASSWORD especificadas en wp-config.php, y acepta cualquier flag válido de mysqldump.

wp db export --single-transaction db.sql

En hostings gestionados y con cPanel, un mysqldump simple puede fallar con un error de privilegio PROCESS al volcar los tablespaces. WP-CLI ya gestiona esto: wp db export añade --no-tablespaces a mysqldump por defecto. Con mysqldump directamente en un hosting gestionado, añade --no-tablespaces manualmente.

Automatizar las copias de seguridad de WordPress con cron y rclone

Automatiza todo el proceso con un script de shell corto en un cron schedule que vuelque la base de datos, comprima wp-content con tar y envíe el archivo fuera del servidor. rclone — “rsync para almacenamiento en la nube” — es compatible con S3, Backblaze B2 y Google Drive, entre otros.

#!/usr/bin/env bash
set -euo pipefail

SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups"     # un remote configurado en rclone
STAMP="$(date +%F)"
WORK="$(mktemp -d)"

cd "$SITE_DIR"

# Base de datos — WP-CLI lee las credenciales de wp-config.php
wp db export --single-transaction "$WORK/db-$STAMP.sql"

# Archivos — temas, plugins, uploads y configuración
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php

# Enviar fuera del servidor
rclone copy "$WORK" "$DEST/$STAMP"

rm -rf "$WORK"

Prográmalo con una línea en crontab que se ejecute diariamente a las 03:15 y registre la salida:

15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Esa es la ventaja de tener el control total de tus copias de seguridad: sin panel de administración, sin plugin, sin pasos manuales. Si WP-CLI no está instalado, sustituye la línea de exportación por mysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql".

Almacenar las copias de seguridad con la regla 3-2-1

Sigue la regla 3-2-1: mantén al menos tres copias de tu sitio, en dos tipos de medios diferentes, con una copia fuera del sitio principal. Nunca dejes que la única copia de seguridad resida en el mismo servidor que el sitio — un ataque o un fallo de disco se lleva ambas a la vez. Por eso el script de automatización anterior envía los datos a un almacenamiento de objetos en lugar de dejar el archivo en la raíz web. Como el archivo contiene una copia completa de tu sitio, incluidos los secretos en wp-config.php, protege el destino con credenciales sólidas y autenticación de dos factores en la cuenta de almacenamiento.

Probar la restauración y los errores que hay que evitar

Una copia de seguridad no probada no es una copia de seguridad. Restaura periódicamente tu archivo .sql y el archivo de archivos en un entorno de staging o local para comprobar que la copia realmente reconstruye el sitio:

tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql          # o, sin WP-CLI:
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql

Tres tipos de fallos son responsables de la mayoría de los sitios perdidos: hacer una copia de seguridad de los archivos sin la base de datos, guardar la copia en el mismo servidor que el sitio, y confiar únicamente en las copias automáticas del hosting. Todos son evitables con el flujo de trabajo descrito anteriormente.

El patrón fiable es sencillo y sin complicaciones: un cron job que vuelca la base de datos de forma consistente, archiva los archivos, envía ambos fuera del servidor y una restauración que realmente pruebas. Escribe el script una vez, apúntalo al almacenamiento de objetos, añade la línea en crontab y realiza una restauración de prueba esta semana — así tendrás una copia de seguridad que controlas tú, en lugar de una que esperas que esté funcionando.

Preguntas frecuentes

¿Cuál es la diferencia entre wp db export y ejecutar mysqldump directamente?

wp db export es una capa delgada sobre mysqldump. Ejecuta la utilidad mysqldump usando las credenciales DB_HOST, DB_NAME, DB_USER y DB_PASSWORD ya almacenadas en wp-config.php, por lo que no necesitas buscar ni pasar los datos de conexión manualmente, y acepta cualquier flag válido de mysqldump. Además, añade --no-tablespaces por defecto, evitando el error de privilegio PROCESS habitual en hostings gestionados. El mysqldump directo produce el mismo volcado, pero requiere que proporciones las credenciales y los flags tú mismo.

¿Por qué mysqldump lanza un error de privilegio PROCESS en hostings gestionados y cómo lo soluciono?

En hostings gestionados y con cPanel, mysqldump intenta volcar la información de los tablespaces, lo que requiere el privilegio PROCESS que los usuarios de bases de datos compartidas normalmente no tienen, generando un error 'Access denied; you need the PROCESS privilege'. Añade el flag --no-tablespaces para omitir ese paso y el volcado se completará con normalidad. WP-CLI añade --no-tablespaces automáticamente en wp db export. En la mayoría de los casos el volcado se completa correctamente a pesar del error, así que verifica el resultado comprobando que tus tablas estén presentes.

¿Puedo omitir la copia de seguridad de los archivos si el núcleo y los plugins de WordPress se pueden volver a descargar?

Puedes reducir lo que archivas, pero nunca omitas los archivos por completo. El núcleo de WordPress, los temas y los plugins se pueden volver a descargar desde sus fuentes, por lo que algunas herramientas de copia de seguridad almacenan únicamente la base de datos más la carpeta uploads. Sin embargo, la carpeta uploads contiene todos los archivos multimedia que no puedes volver a descargar, wp-config.php contiene tus credenciales de base de datos y claves de seguridad, y cualquier archivo personalizado o modificado es irremplazable. Hacer una copia de seguridad de wp-content y wp-config.php captura las partes que son genuinamente únicas de tu sitio.

¿Cómo restauro un sitio WordPress desde una copia de seguridad con mysqldump y tar?

Extrae el archivo de archivos en el directorio del sitio con tar -xzf archive.tar.gz y luego importa la base de datos. Con WP-CLI, ejecuta wp db import db.sql, que lee las credenciales de wp-config.php. Sin WP-CLI, ejecuta mysql -u DB_USER -p DB_NAME < db.sql contra una base de datos existente. Restaura ambas partes juntas y, si el dominio ha cambiado, ejecuta un search-replace en la base de datos para actualizar las URLs almacenadas. Prueba siempre la restauración en un entorno de staging o local antes de confiar en ella en producción.

¿Es seguro seguir usando mysqldump o debería cambiar a mysqlpump?

Usa mysqldump, no mysqlpump. La utilidad mysqlpump quedó obsoleta en MySQL 8.0.34 y fue eliminada por completo en MySQL 8.4, por lo que los scripts que la llaman fallan en servidores actuales. mysqldump sigue siendo compatible y está actualizado; MySQL recomienda mysqldump o las utilidades de volcado de MySQL Shell como sus reemplazos. Para obtener una instantánea consistente de un sitio InnoDB en producción, ejecuta mysqldump con el flag --single-transaction, que evita bloquear las tablas durante el volcado.