Introducción

Todos los usuarios de WordPress nos vemos en la necesidad de realizar copia de seguridad y más si nos dedicamos al mantenimiento de webs de clientes.

Ya sea nuestro blog personal o una tienda de comercio electrónico con miles de ventas diarias, la pérdida de datos, accidental o por un hackeo, nos puede traer consecuencias catastróficas.

Y aunque casi todos los que nos dedicamos al desarrollo y mantenimiento web, implementamos algún tipo de copia de seguridad, en la mayoría de las ocasiones nos quedamos con soluciones básicas que no se ajustan a las necesidades reales de cada proyecto.

Veremos algo más que el típico «haz una copia de seguridad completa cada noche». Vamos a ver cómo planificar una estrategia avanzada de copias de seguridad, optimizada según el tipo de web, los recursos disponibles y las posibilidades de automatización. También abordaremos uno de los aspectos menos tratados y más potentes: las restauraciones parciales.

Porque no siempre necesitamos restaurar el sitio web completo, en la mayoría de las ocasiones solamente una tabla de la base de datos, un plugin dañado o una carpeta específica.

backups WordPress
  1. Introducción
  2. Tipos de backups en WordPress
  3. ¿Qué incluir (o excluir) en una copia de seguridad?
  4. Automatización avanzada con código (BASH, PHP y WP-CLI)
  5. Restauraciones parciales en WordPress
  6. Buenas prácticas y seguridad en la gestión de backups
  7. Consejos adicionales, errores comunes y combinaciones útiles
  8. Backups en WordPress.com
  9. Conclusión final y resumen

¿Por qué es necesario ir más allá del backup completo?

Los backups completos son necesarios, sí, pero tienen limitaciones claras:

  • Tiempo y recursos: Hacer una copia completa de un sitio de 5 GB cada pocas horas no es sostenible.
  • Flexibilidad nula: Si solo necesitas restaurar un plugin, ¿por qué sobrescribir toda la base de datos?
  • Riesgos: Restaurar completamente un sitio en producción puede conllevar pérdida de datos actuales, como pedidos, comentarios o usuarios registrados después del backup.

Aquí entra en juego la lógica de las estrategias granulares, selectivas y automatizadas. Tener backups no es suficiente: deben ser inteligentes, rápidos de restaurar y estar siempre disponibles fuera del servidor de producción.

¿Eres más de vídeo que de lectura? Aunque esta entrada en el blog sea la enciclopedia de los backups, te animamos a que veas este contenido en vídeo en nuestro canal de YouTube con preguntas de la audiencia en directo. ¡Esperamos que lo disfrutes!

Tipos de backups en WordPress

Cuando hablamos de «hacer una copia de seguridad en WordPress», muchos piensan automáticamente en una exportación completa del sitio. Sin embargo, existen diferentes tipos de backups, y entenderlos es fundamental para optimizar tanto el almacenamiento como el tiempo de restauración. No todos los backups sirven para todos los contextos, y combinarlos adecuadamente es lo que te da una solución realmente sólida.

Backup completo

Es el más común. Consiste en copiar todos los archivos del sitio (núcleo de WordPress, temas, plugins, uploads, archivos personalizados…) y la base de datos completa.

Ventajas:

  • Restauración sencilla: lo restauras todo y el sitio vuelve a su estado original.
  • Ideal como copia de emergencia completa o para migraciones.

Inconvenientes:

  • Tamaño muy grande (especialmente en sitios con muchos medios).
  • Requiere más tiempo y recursos, tanto para generar como para restaurar.
  • No es flexible: todo o nada.

Ejemplo con WP-CLI:

wp db export backup.sql

tar -czf backup-full.tar.gz wp-content backup.sql

Backup parcial

Se refiere a realizar copias específicas de algunas partes del sitio: solo los plugins, solo la carpeta de medios, o solo algunas tablas de la base de datos.

Ventajas:

  • Rápidos de hacer y restaurar.
  • Muy útiles para pruebas, staging, restauraciones selectivas.
  • Menor espacio de almacenamiento.

Inconvenientes:

  • Requieren planificación y conocimiento del sitio.
  • No sirven para desastres completos (salvo que se combinen).

Ejemplo con WP-CLI para solo uploads y wp_posts:

wp db export --tables=wp_posts posts.sql

tar -czf media-only.tar.gz wp-content/uploads

Backups incrementales

Solo copian los archivos o datos que han cambiado desde la última copia. Esto se puede aplicar tanto a archivos como a base de datos, aunque esta última requiere un sistema de control más preciso (por ejemplo, triggers, logs binarios o herramientas específicas).

Ventajas:

  • Uso muy eficiente del espacio y del tiempo.
  • Ideales para backups frecuentes (cada hora, cada 10 minutos…).
  • Muy útiles en sitios con alto volumen de contenido dinámico.

Inconvenientes:

No hay una forma nativa en WordPress o WP-CLI de hacer backups incrementales, pero puedes usar herramientas como rsync:

rsync -a --delete --link-dest=/ruta/anterior /ruta/origen/ /ruta/destino/

Backups diferenciales

Parecidos a los incrementales, pero en vez de comparar con la última copia, comparan con la última copia completa. De esta forma, los diferenciales crecen con el tiempo hasta que se hace una nueva copia completa.

Ventajas:

  • Más sencillos de restaurar que los incrementales (solo necesitas la completa y la última diferencial).
  • Buen equilibrio entre espacio y facilidad de uso.

Inconvenientes:

  • Cada diferencial es más pesado cuanto más tiempo pasa sin hacer una completa.
  • Este enfoque se usa sobre todo en scripts personalizados o soluciones externas como rsnapshot.

Backups en caliente vs en frío

Backups en caliente: se realizan mientras el sitio está en funcionamiento. Requieren que las herramientas puedan manejar archivos abiertos o bases de datos en uso. Muchos plugins hacen esto por defecto.

Backups en frío: se realizan con el sitio detenido o «congelado», garantizando la integridad total de los datos. Son más seguros pero menos prácticos para entornos en producción.

En servidores propios puedes usar mysqldump con lock o parar PHP temporalmente si se automatiza bien.

# Ejemplo de base de datos en frío (idealmente con tráfico pausado)

mysqldump -u usuario -p base_datos > db-backup.sql

Locales vs remotos

Locales: el backup se guarda en el mismo servidor donde se aloja el sitio.

✅ Rápido y accesible

❌ Peligroso si el servidor falla o es atacado

Remotos: el backup se guarda en otro servidor, sistema de almacenamiento o servicio en la nube (Dropbox, S3, Google Drive, FTP/SFTP…).

✅ Más seguros y resistentes

❌ Requieren más configuración

Ejemplo de envío automático a servidor remoto por SFTP en BASH:

scp backup-completo.tar.gz usuario@ip:/ruta/remota/

¿Qué incluir (o excluir) en una copia de seguridad?

Una copia de seguridad no debería ser un calco total y sin filtros del servidor. Muchas veces, sobre todo en backups automatizados o de gran tamaño, conviene ser selectivo y decidir exactamente qué partes del sitio se deben guardar y cuáles no. Esto te permite ganar en velocidad, reducir el uso de disco, evitar restauraciones problemáticas y mejorar la seguridad.

Vamos a revisar las diferentes partes del ecosistema WordPress y valorar si deben incluirse, cuándo y cómo.

Archivos del núcleo de WordPress

backup de archivos de WordPress

Carpetas principales: /wp-admin/, /wp-includes/
Archivos raíz: wp-config.php, index.php, .htaccess, etc.

¿Incluirlos?

  • ✅ Solo si necesitas una imagen completa del sitio.
  • ❌ Normalmente no hace falta: estos archivos se pueden restaurar fácilmente desde una instalación limpia de WordPress.

Excepción:

  • wp-config.php sí debe guardarse siempre, ya que contiene datos sensibles como el acceso a la base de datos y claves únicas.

BASH (excluyendo núcleo):

tar --exclude='./wp-admin' --exclude='./wp-includes' -czf wp-solo-contenido.tar.gz .

Temas y plugins

/wp-content/themes/
/wp-content/plugins/

¿Incluirlos?

  • ✅ Sí, sobre todo si tienes personalizaciones o plugins/temas que no están en el repositorio.
  • ❌ Puedes omitirlos si usas solo temas y plugins descargables y no has hecho ninguna modificación.

WP-CLI para listar plugins activos (útil para restauraciones manuales):

wp plugin list --status=active > plugins-activos.txt

PHP para copiar solo temas y plugins:

$folders = array( 'wp-content/themes', 'wp-content/plugins' );
foreach ( $folders as $folder ) {
    // Código en el que copiamos cada carpeta a un destino de backup.
}

Carpeta uploads

/wp-content/uploads/

¿Incluirla?
✅ Siempre. Esta carpeta contiene todos los archivos multimedia subidos desde el panel: imágenes, PDFs, vídeos, documentos, etc.

  • Es casi siempre la parte más pesada del sitio.
  • En sitios con mucho contenido, puede convenir hacer backups parciales por fechas o tipos de archivo.

BASH para comprimir solo la carpeta de mayo de 2025:

tar -czf uploads-mayo.tar.gz wp-content/uploads/2025/05

Base de datos

backup de la base de datos de WordPress

Contiene TODO el contenido dinámico del sitio: entradas, páginas, usuarios, opciones, configuraciones de plugins, etc.

¿Incluirla?
✅ Siempre, pero no siempre completa. A veces solo necesitas una tabla concreta.

Backup completo con WP-CLI:

wp db export backup.sql

Backup parcial (solo tablas de contenido):

wp db export --tables=wp_posts,wp_postmeta,wp_terms contenido.sql

PHP (usando $wpdb) para exportar tabla específica:

global $wpdb;
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}posts" );
// Aquí guardamos los datos como JSON o CSV.

Otros archivos personalizados

.git/, .svn/, logs/, tmp/, cache/, backups/, etc.

¿Incluirlos?
❌ En general, no. Estos archivos:

  • No son necesarios para restaurar el sitio.
  • Pueden contener información delicada (como el historial de código en .git/)
  • Aumentan el tamaño sin beneficio práctico.

BASH para excluir múltiples carpetas:

tar -czf backup-completo.tar.gz . \
  --exclude='./.git' \
  --exclude='./cache' \
  --exclude='./logs' \
  --exclude='./wp-content/backups'

Configuraciones del servidor

Archivos como .htaccess, php.ini, nginx.conf, configuraciones de cron, etc.

¿Incluirlos?

  • ✅ Si tienes control sobre el servidor (VPS, dedicado) y has hecho personalizaciones relevantes.
  • ❌ Si estás en un hosting compartido o no has modificado estos archivos manualmente.

Consejo: guarda estos archivos por separado en un backup técnico.

BASH:

cp .htaccess ~/backups/server-configs/htaccess-$(date +%F).bak

Automatización avanzada con código (BASH, PHP y WP-CLI)

Automatizar los backups es esencial para garantizar que no dependan de la intervención humana. Hacerlo con código (en lugar de depender exclusivamente de plugins) te permite tener control total, personalizar al milímetro el proceso, y además integrarlo con otros scripts del servidor (deploys, staging, alertas, etc.).

Aquí verás cómo combinar scripts en BASH, comandos de WP-CLI y funciones en PHP para lograr backups programados, seguros y eficientes.

Automatización con BASH + cron

Si tienes acceso SSH o control sobre el servidor (VPS, dedicado o contenedor), podemos crear un script BASH que haga el backup completo o parcial y lo programe con cron.

Script básico para backup completo

#!/bin/bash

# Configuración
SITE_DIR="/var/www/html"
BACKUP_DIR="/home/backups/wordpress"
DATE=$(date +%F_%H-%M)
DB_NAME="nombre_base_de_datos"
DB_USER="usuario_base_de_datos"
DB_PASS="clave_base_de_datos"

# Crear carpetas
mkdir -p "$BACKUP_DIR/$DATE"

# Backup base de datos
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > "$BACKUP_DIR/$DATE/backup-db.sql"

# Backup archivos (sin carpetas innecesarias)
tar --exclude="$SITE_DIR/wp-content/cache" \
    --exclude="$SITE_DIR/.git" \
    -czf "$BACKUP_DIR/$DATE/archivos.tar.gz" "$SITE_DIR"

# Eliminar backups antiguos (más de 7 días)
find "$BACKUP_DIR" -type d -mtime +7 -exec rm -rf {} \;

Programar con cron (backup diario a las 3:13 AM)

13 3 * * * /bin/bash /ruta/al/script.sh

Automatización con WP-CLI

WP-CLI no solo sirve para tareas puntuales. También se puede usar en scripts programados, para hacer backups selectivos o como parte de procesos de CI/CD.

Backup de uploads + base de datos con WP-CLI

#!/bin/bash

DATE=$(date +%F)
BACKUP_DIR="/home/backups/wpcli"

mkdir -p "$BACKUP_DIR/$DATE"

# Backup de la base de datos
wp db export "$BACKUP_DIR/$DATE/backup-db.sql"

# Backup de uploads
tar -czf "$BACKUP_DIR/$DATE/uploads.tar.gz" wp-content/uploads

Restaurar desde backup

# Importar base de datos
wp db import backup-db.sql

# Restaurar uploads
tar -xzf uploads.tar.gz -C wp-content/uploads

Backup de tabla específica antes de modificarla

wp db export --tables=wp_options antes-de-mods.sql

Automatización en PHP (para backups desde dentro de WordPress)

Si no tienes acceso a cron jobs o prefieres ejecutar desde WP, puedes crear una función en un plugin personalizado que se ejecute manualmente, o en un hook programado usando wp_schedule_event().

Ejemplo de backup programado en PHP

function cl_wp_custom_backup() {
    global $wpdb;

    $upload_dir = wp_upload_dir();
    $backup_dir = WP_CONTENT_DIR . '/backups';
    wp_mkdir_p( $backup_dir );

    // 1. Exportar base de datos.
    $sql_file = $backup_dir . '/db-' . date( 'Ymd-His' ) . '.sql';
    $command  = sprintf(
        'wp db export %s',
        escapeshellarg( $sql_file )
    );
    exec( $command );

    // 2. Comprimir uploads.
    $uploads_tar = $backup_dir . '/uploads-' . date( 'Ymd-His' ) . '.tar.gz';
    $cmd_tar     = sprintf(
        'tar -czf %s -C %s uploads',
        escapeshellarg( $uploads_tar ),
        escapeshellarg( dirname( $upload_dir['basedir'] ) )
    );
    exec( $cmd_tar );
}

Programar con wp_schedule_event

if ( ! wp_next_scheduled( 'cl_wp_daily_custom_backup' ) ) {
    wp_schedule_event( time(), 'daily', 'wp_daily_custom_backup' );
}

add_action( 'cl_wp_daily_custom_backup', 'cl_wp_custom_backup' );

Envío automático a servidor externo (SFTP, Dropbox, etc.)

Con BASH puedes enviar automáticamente los backups una vez generados.

Envío por SFTP (clave SSH recomendada)

scp /ruta/backup.tar.gz user@host:/ruta/remota/

Envío a Dropbox (usando rclone1)

rclone copy /ruta/backup/ dropbox:wordpress-backups

Logs y alertas

Todo sistema automático debe dejar trazas y, si es posible, enviar alertas cuando falla.

Registro de logs en BASH

exec >> /var/log/wp-backup.log 2>&1
echo "Backup ejecutado en $(date)"

Notificación por correo en caso de error (BASH)

if [ $? -ne 0 ]; then
  echo "Fallo en backup" | mail -s "Error en el backup de WordPress" tu@correo.com
fi

Restauraciones parciales en WordPress

Una restauración parcial te permite recuperar una parte concreta del sitio sin tener que sobreescribir todo lo demás. Esto es crucial cuando:

  • Solo se ha dañado una tabla de la base de datos.
  • Se ha eliminado una imagen o carpeta de uploads.
  • Se necesita volver a una versión anterior de un plugin o tema personalizado.
  • Hay que hacer una restauración puntual en staging sin afectar producción.

Hacerlo bien requiere planificar desde el backup, pero es completamente viable usando BASH, WP-CLI, y PHP.

Restaurar una tabla concreta de la base de datos

Supongamos que el plugin X ha corrompido la tabla wp_options.

Paso 1: Extraer solo esa tabla desde el backup

Con sed + grep en BASH:

sed -n '/DROP TABLE.*`wp_options`/,/UNLOCK TABLES/p' backup.sql > wp_options.sql

Esto extrae solo el bloque SQL de esa tabla.

Paso 2: Importarla

Con WP-CLI:

wp db query < wp_options.sql

Si la tabla original existe y quieres sobreescribirla, puedes hacer primero:

wp db query "DROP TABLE wp_options;"

Restaurar una imagen o carpeta de uploads

Supón que un editor borró por accidente la carpeta de imágenes de mayo de 2025.

Paso 1: Comprobar si tu backup la tiene

tar -tzf uploads.tar.gz | grep '2025/05/'

Paso 2: Extraer solo esa carpeta

tar -xzf uploads.tar.gz wp-content/uploads/2025/05

Paso 3: Volver a ponerla en la web

cp -r wp-content/uploads/2025/05 /ruta/actual/wp-content/uploads/

También puedes usar rsync si quieres mantener timestamps y evitar duplicados.

Restaurar un plugin o tema individual

Ideal si hiciste backup de /wp-content/plugins/ y uno de ellos falla tras una actualización.

Paso 1: Extraer el plugin desde el .tar.gz

tar -xzf files.tar.gz wp-content/plugins/nombre-plugin

Paso 2: Reemplazarlo en el sitio

rm -rf wp-content/plugins/nombre-plugin
cp -r files/extraido/wp-content/plugins/nombre-plugin wp-content/plugins/

Restaurar una opción concreta (wp_options)

Útil si, por ejemplo, se cambió accidentalmente la URL del sitio o una configuración crítica de un plugin.

Paso 1: Buscar la opción en el backup

grep "siteurl" backup.sql

Paso 2: Ejecutar un REPLACE INTO

wp db query "REPLACE INTO wp_options (option_name, option_value, autoload) VALUES ('siteurl', 'https://tusitio.com', 'auto');"

Puedes aplicar esto a cualquier otra opción. También puedes combinarlo con --skip-plugins para no cargar todo si el sitio está roto.

Restaurar desde PHP (plugin interno)

function cl_restore_wp_option( $option_name, $value ) {
    if ( false !== get_option( $option_name ) ) {
        update_option( $option_name, $value );
    } else {
        add_option( $option_name, $value );
    }
}
// Ejemplo: cl_restore_wp_option( 'siteurl', 'https://tusitio.com' );

Esto es útil, por ejemplo, si tienes backups serializados en JSON.

Restaurar usuarios (solo la tabla de users de WordPress)

Si has perdido usuarios o necesitas restaurar alguno en concreto.

sed -n '/DROP TABLE.*`wp_users`/,/UNLOCK TABLES/p' backup.sql > wp_users.sql
sed -n '/DROP TABLE.*`wp_usermeta`/,/UNLOCK TABLES/p' backup.sql > wp_usermeta.sql

wp db query < wp_users.sql
wp db query < wp_usermeta.sql

Ten en cuenta que los IDs deben coincidir para que las relaciones funcionen.

Restauraciones combinadas desde staging

Otra opción avanzada es restaurar selectivamente desde un entorno de staging donde has importado el backup completo, y luego mover a producción solo lo necesario.

Ejemplo con WP CLI:

wp search-replace --export=filtered.sql \
    --tables=wp_posts,wp_postmeta \
    'staging.tusitio.com' 'tusitio.com'

Después, importas filtered.sql en producción.

Buenas prácticas y seguridad en la gestión de backups

Almacenamiento: dónde guardar las copias

Almacenamiento en la nube para backups

Nunca en la misma máquina

Guardar backups en el mismo servidor que tu sitio web es el error más común. Si el servidor se cae, lo hackean o se borra por error… te quedas sin web y sin copia.

Recomendaciones:

  • Segundo disco físico o volumen montado por red (NFS).
  • Servidor externo SFTP/SCP.
  • Servicios de almacenamiento en la nube cifrados: Dropbox, Google Drive, S3, Backblaze, etc.
  • Rclone es un gran aliado: permite montar servicios de nube como si fueran discos locales para enviar tus backups.

Cifrado y protección de acceso

Cifrado de backups

Los backups contienen información muy sensible: contraseñas, hash, correos, claves de API, configuración interna, rutas del sistema…

Cifra tus backups

Con GPG (BASH):

gpg -c backup.tar.gz

Esto crea un .gpg protegido por contraseña.

Automatizado en script:

tar -czf - /carpeta | gpg --symmetric --cipher-algo AES256 -o backup.tar.gz.gpg

Requiere establecer y proteger la contraseña de cifrado.

Protege las rutas de backups

  • Nunca dejes backups dentro de public_html, /wp-content, ni accesibles por URL directa.
  • Usa .htaccess o nginx para bloquear su acceso si están dentro de una ruta web:

Apache:

<FilesMatch "\.(sql|tar\.gz|zip|gpg)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Nginx:

location ~* \.(sql|tar\.gz|zip|gpg)$ {
    deny all;
}

Nombres consistentes y comprensibles

Usa convenciones claras que permitan entender rápidamente qué contiene un backup:

backup-wp--2025-05-13--db.sql
backup-wp--2025-05-13--uploads.tar.gz
backup-wp--2025-05-13--full.tar.gz.gpg

También puedes incluir hashes para verificación de integridad:

sha256sum backup.tar.gz > backup.tar.gz.sha256

Y luego comprobar:

sha256sum -c backup.tar.gz.sha256

Retención y limpieza automática

No conservar copias indefinidamente: consume disco y genera ruido.

Eliminar backups viejos (BASH):

find /home/backups/ -type f -mtime +30 -delete

Esto borra los archivos de más de 30 días.

También puedes conservar solo una copia por semana o por mes con lógica de scripting.

Logs, verificación y monitoreo

Tener backups automáticos no basta. Necesitas saber que se están haciendo y que son restaurables.

Logs

En tus scripts, usa:

exec >> /var/log/backup-wp.log 2>&1

Prueba de restauración

Haz restauraciones periódicas en entornos de staging para comprobar que:

  • La base de datos carga.
  • Las rutas de uploads no están corruptas.
  • Las claves de configuración son correctas.

Puedes automatizar una verificación básica post-backup:

wp db check || echo "ERROR: base de datos corrupta tras backup" | mail -s "Fallo de backup" correo@tudominio.com

Acceso limitado y controlado

  • No permitas que cualquier usuario con SSH vea los backups.
  • Usa un usuario del sistema dedicado para el proceso de backup/restauración.
  • Usa claves SSH con scp y rsync, nunca contraseñas.

Ejemplo de conexión segura con clave:

scp -i ~/.ssh/id_rsa backup.tar.gz user@host:/ruta/

Políticas de ciclo de vida (cuando hay muchos sitios)

Si gestionas múltiples webs (como agencias, hosting propio, multisite, etc.), define:

  • Copia diaria durante 7 días.
  • Copia semanal durante 1 mes.
  • Copia mensual durante 6 meses.

Y automatiza las rotaciones con scripts y cron. Si usas S3, puedes aplicar políticas de ciclo de vida directamente desde AWS.

Informes y alertas por correo o Slack

Puedes integrar los procesos con sistemas de notificación:

  • Correo electrónico (usando mail en BASH o wp_mail() en PHP).
  • Slack, Discord o Telegram con curl y sus Webhooks.

Ejemplo BASH con Slack:

curl -X POST -H 'Content-type: application/json' \
--data '{"text":"Backup completado correctamente para site X el día '"$(date)"'"}' \
https://hooks.slack.com/services/TU_WEBHOOK

Consejos adicionales, errores comunes y combinaciones útiles

Una vez que tienes el sistema de backups funcionando, puedes ir un paso más allá integrando buenas prácticas adicionales y herramientas que te ayuden a mantener tu sitio WordPress más seguro, más estable y más profesional.

Errores comunes que debes evitar

❌ No probar los backups

Tener backups sin verificar su restauración es como tener un extintor sin presión. Haz restauraciones de prueba regularmente en entornos de staging.

❌ Guardar los backups en el mismo sitio que WordPress

Si el servidor falla o lo hackean, pierdes ambos. Siempre usa almacenamiento externo y cifrado.

❌ No automatizar nada

Depender de que un humano haga copias manuales es garantía de olvido. Usa cron, wp cron, WP-CLI, scripts en bash, o plugins que te den confianza.

❌ No separar los backups por tipo

Evita meter base de datos, archivos y configuraciones en el mismo saco. Cuanto más granular sea el backup, más fácil será restaurar solo lo que necesitas.

❌ Conservar copias indefinidamente

A menos que tengas necesidades legales concretas, una política de retención clara evita saturar discos o pagar almacenamiento innecesario.

Complementa tus backups con staging

Usa staging como entorno de prueba

Muchos hosts ya incluyen staging con un clic. Pero si no, puedes crear uno manualmente clonando archivos y base de datos, y luego usar:

wp search-replace 'produccion.com' 'staging.produccion.com' --skip-columns=guid

Desde ahí puedes:

  • Probar restauraciones parciales.
  • Testear actualizaciones de plugins y temas.
  • Simular fallos sin comprometer producción.

Backups antes de deploy

Si trabajas con staging y luego pasas a producción, haz siempre una copia justo antes del deploy.

Puedes incluso automatizarlo con hooks en git o con tu sistema de integración.

Versionado con Git: ¿es compatible?

Sí, aunque con matices:

✔️ ¿Qué puedes versionar?

  • Temas y plugins personalizados.
  • Archivos de configuración (wp-config.php sin claves sensibles).
  • Scripts de migración, personalización, funciones, etc.

🚫 ¿Qué no debes versionar?

  • La base de datos (usa migraciones de la BD).
  • El directorio uploads/ (muy pesado, cambia con frecuencia).

Ejemplo de .gitignore recomendado:

/wp-content/uploads/
/wp-content/cache/
/wp-config.php
/wp-content/plugins/plugin-exterior/
/node_modules/
/vendor/

Combina Git + Backups

  • Git para el código.
  • Backups para la base de datos y archivos dinámicos.
  • Así tienes un sistema completo y profesional.

Gestión avanzada con WP-CLI + scripts

Además, podemos combinar WP-CLI con bash y cron para crear una completa suite de respaldo y restauración.

Veamos un ejemplo simple:

#!/bin/bash
fecha=$(date +%Y-%m-%d)
directorio="/home/backups/$fecha"
mkdir -p "$directorio"

# Backup de la base de datos
wp db export "$directorio/db.sql" --path=/var/www/html/

# Backup de archivos
tar -czf "$directorio/uploads.tar.gz" /var/www/html/wp-content/uploads/

# Cifrado
gpg -c "$directorio/db.sql"
rm "$directorio/db.sql"

# Envío remoto
scp "$directorio/uploads.tar.gz" user@remoto.com:/backups/

Puedes combinarlo con herramientas como rclone, gpg, mail, y slack para tener un sistema pro totalmente a medida y sin gastar en servicios de terceros.

¿Qué plugin elegir si lo necesitas?

Jetpack VaultPress Backup

Aunque si eres programador o administrador de sistema, seguramente prefieras soluciones personalizadas, si tu preferencia es la utilización de plugins puedes ver estas opciones:

Aun así, ningún plugin sustituye una solución bien pensada con tus propias copias externas y controladas.

Consejo Pro

Hay ocasiones en las que trabajaremos con volcados de bases de datos grandes, de 4 GB. 40 GB. o incluso mucho más. Con estos archivos es muy complicado abrirlos en un editor desde entornos gráficos sin que acaben fallando o colapsando el sistema.

Para estas ocasiones, deberemos echar mano, como hasta ahora, de la consola y comandos como head o tail para ver X líneas del principio o del final del archivo, e incluso visualizar una parte y volcarla a un nuevo archivo.

Esto nos será especialmente útil si nos encontramos con un problema en la importación, debido a una incompatibilidad de un comando de MariaDB de las últimas versiones, que produce un error en la importación con MySQL o versiones anteriores de MariaDB2.

Para saber si el archivo tiene esa incompatibilidad, ejecutamos:

head -n 10 volcado-db.sql
comando head

Así veremos las diez primeras líneas del archivo y buscaremos si contiene «al culpable» /*!999999\- enable the sandbox mode */ .

Y si vemos que contiene /*!999999\- enable the sandbox mode */ podemos eliminar la primera línea con el siguiente comando:

tail -n +2 volcado-db.sql > nuevo-volcado-db.sql

Y ya tendremos un archivo nuevo-volcado-db.sql sin dicha línea y preparado para la correcta importación en sistemas previos.

Recomendaciones finales

  • Ten al menos tres copias en dos ubicaciones distintas, una fuera de línea. (Regla 3-2-1)
  • No automatices sin log y sin alerta de error.
  • Documenta tus rutas, comandos, claves de acceso y ciclo de vida de las copias.
  • Piensa siempre en restaurar antes que en copiar.

Backups en WordPress.com

Si tu web está en WordPress.com tenemos el apartado de los backups cubierto con las siguientes opciones:

Sitio web de Staging disponible a un clic3 y con una completa gestión de lo que migramos de o hacia staging, tanto de archivos como de la base de datos.

Sitio web de Staging disponible a un clic en WordPress.com

Copia de seguridad en tiempo real con restauración total, parcial y posibilidad de descargar el backup completo, solo algunos archivos o carpetas y tablas específicas de la base de datos4.

Los backups, como debería ser siempre, están alojados en servidores diferentes de los que albergan la web y podemos elegir la localización del centro de datos.

Copia de seguridad en tiempo real en WordPress.com
Restauración parcial de copias de seguridad en WordPress.com

Registro de actividad5 desde el que podemos ver todos los cambios realizados sobre la web y revertirlos en caso de ser necesario o descargar una copia de seguridad de archivos y base de datos de cómo estaba en ese momento.

Registro de actividad desde el que podemos ver todos los cambios realizados en WordPress.com

Acceso a phpMyAdmin6.

Acceso SSH con WP Cli para la ejecución de comandos avanzados de copias y restauraciones como wp wpcomsh backup-import.

Conclusión final y resumen

No existe un único tipo de backup válido para todo. Lo ideal es combinar varios enfoques:

  • Backups completos diarios a una ubicación remota
  • Incrementales frecuentes en local
  • Copias diferenciales antes de hacer cambios importantes
  • Backups parciales para restauraciones puntuales

Un buen backup en WordPress debería incluir siempre:

  • ✔️ Base de datos (completa o selectiva)
  • ✔️ /wp-content/ (especialmente uploads, themes, plugins)
  • ✔️ wp-config.php
  • ❌ Pero excluir contenido innecesario como .git, node_modules, tmp, logs, o el núcleo de WordPress si puedes regenerarlo.

Con una estrategia bien definida de inclusiones y exclusiones, podrás optimizar tiempos, reducir espacio y mejorar la rapidez de las restauraciones.

Una estrategia de backups sin automatización es como tener una alarma que suena solo si te acuerdas de activarla. Con unos pocos scripts puedes:

  • Controlar qué se guarda, cuándo y dónde.
  • Integrarlo con tus sistemas de monitorización o CI/CD.
  • Evitar olvidos o dependencias humanas.

Las restauraciones parciales te ahorran tiempo, reducen riesgos y te permiten actuar con precisión quirúrgica sobre tu instalación WordPress. No son excesivamente complejas si:

  • Tienes backups bien estructurados.
  • Usas herramientas como WP-CLI, tar, sed, grep o pequeños scripts en PHP.
  • Documentas tus cambios y procedimientos.

Un backup que no está protegido, cifrado, controlado o monitorizado es tan peligroso como no tener ninguno. Si quieres que tu sistema de copias sea profesional y confiable, asegúrate de que:

  • No sea accesible públicamente.
  • Esté cifrado y controlado.
  • Tenga una política de retención clara.
  • Puedas restaurarlo con confianza.

Un buen sistema de backups no se trata solo de tener un botón de «restaurar» o de ejecutar un cron diario. Se trata de entender tu instalación, sus puntos débiles, sus prioridades, y preparar un conjunto de herramientas que te den control, tranquilidad y velocidad de reacción.

Dominar los backups avanzados y las restauraciones parciales es, para cualquier desarrollador o administrador de WordPress, una herramienta estratégica, no solo técnica.

  1. https://rclone.org/ rclone soporta más de 90 diferentes proveedores remotos como Dropbox, Amazon S3, Backblaze B2, Cloudflare R2, Google Drive, Hetzner Storage Box, Microsoft OneDrive, ownCloud, pCloud o Wasabi entre otros muchos ↩︎
  2. Microsoft OneDrive, ownCloud, pCloud o Wasabi entre otros muchos. ↩︎
    MariaDB Dump File Compatibility Change https://mariadb.org/mariadb-dump-file-compatibility-change/ ↩︎
  3. Desde el panel de administración de WordPress, ir a Alojamiento -> Resumen -> Sitio de pruebas. ↩︎
  4. Desde el panel de administración de WordPress, ir a Jetpack-> VaultPress. ↩︎
  5. Desde el panel de administración de WordPress, ir a Jetpack -> Registro de actividad. ↩︎
  6. Desde el panel de administración de WordPress, ir a Alojamiento -> Resumen -> Ajsutes _> Base de datos -> Abrir phpMyAdmin. ↩︎