¿Se han perdido pedidos, usuarios o respuestas de formularios tras una actualización o fallo? Una restauración completa puede romper la integridad y prolongar la recuperación; quien gestiona el sitio necesita recuperar datos concretos rápido y sin afectar el resto del WordPress.
Un backup granular copia y restaura solo tablas concretas de la base de datos (por ejemplo wp_posts o wp_woocommerce_orders), minimizando tiempos de inactividad. Métodos seguros: mysqldump --tables, phpMyAdmin, binlogs/PITR y réplicas; scripts reproducibles (Bash, WP-CLI), manejo de dependencias FK y conflictos, estrategias para hosts compartidos sin SSH y para bases de datos grandes. Comprobar las tablas críticas y sus dependencias es el primer paso; continuar con el resumen del proceso.
Resumen del proceso
- Identificar tablas críticas y dependencias. Comprobar engine y collation.
- Exportar esquema y datos de las tablas objetivo con flags transaccionales.
- Guardar dump de la tabla actual como rollback inmediato.
- Restaurar en modo controlado (desactivar FK si procede). Comprobar duplicados.
- Ejecutar pruebas funcionales en staging y en producción fuera pico.
- Documentar y rotar backups en remoto, cifrados y con retención.
Tiempo estimado: para tablas pequeñas el ciclo completo (dump, import, verificación) suele llevar entre 10 y 20 minutos; para tablas grandes puede tardar horas sin réplica.
Paso 1: conceptos clave y ventajas
Breve definición: un respaldo por tabla exporta el esquema y/o los datos de tablas concretas de MySQL/MariaDB. Sirve para recuperar pedidos, usuarios o metadatos sin restaurar toda la base.
Diferencia técnica: un dump lógico (.sql) contiene instrucciones CREATE/INSERT. Un snapshot físico copia ficheros InnoDB y suele ser más rápido, pero no siempre permite extraer solo una tabla sin herramientas adicionales.
Motores: InnoDB permite transacciones y el flag --single-transaction. MyISAM no soporta transacciones; exportar tablas MyISAM puede requerir bloqueo.
Tablas críticas de WordPress: wp_posts, wp_postmeta, wp_users, wp_usermeta, wp_options y tablas de ecommerce. Exportar solo una de estas sin revisar sus dependencias suele romper funcionalidades.
Advertencia: exportar solo datos sin el esquema puede causar errores por columnas nuevas o collation distinto. Siempre exportar el esquema si hay dudas.
Paso 2: ventajas de respaldos por tabla frente a copias completas
Reducción de downtime. Restaurar una tabla suele ser mucho más rápido que cargar una base completa. Esto baja el RTO para incidentes puntuales.
Ahorro de espacio y tiempo. Los dumps de tablas críticas ocupan menos y se comprimen mejor. Para tiendas con pedidos frecuentes, solo salvando tablas de pedidos se reduce el RPO.
Menor I/O en producción si se usa réplica o export desde esclavo. Para bases grandes, exportar desde un esclavo evita impacto en el maestro.
Límites: no válido cuando el incidente afecta al esquema o a áreas múltiples acopladas. En esos casos la restauración completa o PITR con binlogs es la opción segura.
Paso 3: cómo hacer backup granular de tablas en WordPress
Este bloque contiene comandos reproducibles según acceso y tamaño de BD. Escoger la opción según el entorno: SSH disponible, acceso a réplica, o solo panel phpMyAdmin.
Mysqldump por tablas
Comando estándar para InnoDB:
bash
mysqldump --single-transaction --quick --skip-lock-tables -u USUARIO -p NOMBRE_BD --tables wp_posts wp_postmeta > backup_tablas.sql
Explicación breve de flags:
- --single-transaction: crea un punto consistente para tablas InnoDB sin bloquearlas; ideal para tablas transaccionales, pero puede mantener una transacción abierta durante mucho tiempo en tablas enormes, lo que afecta al purgado de UNDO.
- --quick: lee filas por streaming para usar menos memoria durante el volcado.
- --skip-lock-tables: desactiva el bloqueo explícito de tablas. Atención: usar --skip-lock-tables en tablas MyISAM puede producir un dump inconsistente si se realizan escrituras concurrentes, porque MyISAM no soporta transacciones. Para entornos con MyISAM activos se recomienda usar --lock-tables o exportar desde una réplica, o bien convertir tablas críticas a InnoDB si se precisa exportaciones consistentes sin downtime.
Para tablas enormes exportar por rangos:
bash
mysqldump -u USUARIO -p NOMBRE_BD wp_posts --where="post_date >= '2026-01-01'" > posts_2026.sql
Si no hay espacio en disco local, usar streaming y compresión:
bash
mysqldump -u USUARIO -p NOMBRE_BD --tables wp_posts | gzip > /tmp/wp_posts.sql.gz
Tiempo real: volcar 1M filas puede tardar entre 20 y 60 minutos según I/O y CPU.
phpMyAdmin y hosting compartido
Flujo seguro:
- Entrar en phpMyAdmin, seleccionar BD, marcar tablas, Exportar → SQL.
- Marcar "Add DROP TABLE" y elegir compatibilidad UTF-8.
Errores frecuentes: timeout o límites de upload. Si ocurre dividir por tablas individuales o usar SELECT INTO OUTFILE si el host lo permite.
SELECT INTO OUTFILE / LOAD DATA INFILE
Útil cuando se tiene acceso al filesystem MySQL:
sql
SELECT * FROM wp_posts WHERE post_type='shop_order' INTO OUTFILE '/tmp/orders.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '/n';
Requiere permisos de archivo y es muy rápido. Importación con LOAD DATA INFILE.
WP-CLI para integrarlo en scripts
Obtener credenciales y lanzar mysqldump sin hardcodear:
bash
DB_NAME=$(wp config get DB_NAME)
DB_USER=$(wp config get DB_USER)
DB_PASS=$(wp config get DB_PASSWORD)
DB_HOST=$(wp config get DB_HOST)
mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" --single-transaction --quick "$DB_NAME" --tables wp_posts > /backups/wp_posts.sql
Usar --path si el WP no está en el directorio actual.
Métodos para bases de datos grandes y sin impacto
- Volcado desde réplica: crear réplica temporal y ejecutar mysqldump en esclavo.
- Percona XtraBackup (físico): copia caliente de ficheros InnoDB; extraer la tabla requiere pasos adicionales.
- Binlogs/PITR: usar mysqlbinlog para reproducir transacciones hasta un punto. Requiere binlogs activados.
Referencias: guías oficiales de Percona son útiles para entornos grandes.
1. Identificar tablas
2. Exportar esquema + datos
3. Importar en modo controlado
4. Verificar y documentar
Flujo: elegir origen (maestro/esclavo) → exportar con flags transaccionales → importar con FK controladas → ejecutar checks.
Cuando el entorno requiere copias físicas (por ejemplo Percona XtraBackup) y se necesita restaurar solo una tabla InnoDB, el proceso difiere del dump lógico. Es viable si innodb_file_per_table=1:
- Generar backup físico con xtrabackup --backup --target-dir=/backups/xtrabackup
- Preparar el backup: xtrabackup --prepare --target-dir=/backups/xtrabackup
- Exportar la tabla concreta desde el backup con xtrabackup --export --target-dir=/backups/xtrabackup --datadir=/var/lib/mysql y esto produce .ibd y .cfg listos para importar.
- En el servidor de destino crear la tabla vacía con el mismo esquema (CREATE TABLE ...) y ejecutar ALTER TABLE nombre_tabla DISCARD TABLESPACE; copiar el .ibd y el .cfg al datadir correspondiente y finalmente ALTER TABLE nombre_tabla IMPORT TABLESPACE. Puntos críticos: la tabla debe tener file-per-table, las versiones de MySQL/MariaDB deben ser compatibles y hay que respetar permisos/propietarios de archivos. Probar el flujo en staging es esencial porque la manipulación de tablespaces físicas es delicada y puede dejar la tabla inaccesible si algo falla.
Paso 4: plugins para backup granular de tablas MySQL
Plugins ofrecen facilidad en hosting sin SSH. No todos permiten exportar tablas individuales.
Recomendaciones prácticas:
- Buscar plugins con opción de export por tabla y compatibilidad con S3/GCP.
- Elegir soluciones con pruebas de restauración y cifrado en reposo.
Ejemplos habituales: UpdraftPlus y BlogVault ofrecen backups gestionados. ManageWP centraliza tareas. Para entornos críticos conviene comparar con la opción del proveedor (snapshots de infraestructura).
Paso 5: restaurar tablas específicas: guía paso a paso
Checklist previo:
- Exportar esquema de la tabla restaurada:
mysqldump --no-data --tables wp_users > schema_wp_users.sql
- Hacer dump de la tabla actual para rollback:
mysqldump DB --tables wp_users > wp_users.pre_restore.sql
- Comprobar versión MySQL y collation:
mysql -e "SELECT @@version, @@character_set_database;"
Identificar claves foráneas relacionadas:
sql
SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE REFERENCED_TABLE_NAME IS NOT NULL
AND TABLE_SCHEMA='nombre_bd'
AND REFERENCED_TABLE_NAME='wp_users';
Procedimiento de import seguro:
- Poner modo mantenimiento si la tabla afecta operaciones críticas.
- Respaldar la tabla existente (dump pre_restore).
- Opcional:
SET FOREIGN_KEY_CHECKS=0;
- Importar el SQL:
mysql -u user -p DB < backup_tabla.sql
- Reactivar FK:
SET FOREIGN_KEY_CHECKS=1;
- Ejecutar comprobaciones: identificar filas huérfanas o duplicados.
Comandos SQL para comprobaciones comunes:
sql
-- Filas huérfanas en postmeta
SELECT COUNT(*) FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);
-- Ver usuarios sin meta
SELECT u.ID FROM wp_users u LEFT JOIN wp_usermeta m ON u.ID = m.user_id WHERE m.umeta_id IS NULL LIMIT 10;
Resolución de conflictos:
- Para duplicados: eliminar entradas duplicadas antes de importar. Ejemplo:
sql
DELETE t1 FROM wp_users t1
INNER JOIN wp_users t2
WHERE t1.ID > t2.ID AND t1.user_email = t2.user_email;
- Para merges puntuales usar INSERT ... ON DUPLICATE KEY UPDATE con cautela.
Restauración en hosting compartido sin SSH:
- Exportar por tablas desde phpMyAdmin o el panel.
- Importar en fragmentos si hay límite de upload. Herramienta BigDump sirve para cargas por lotes.
- Si no funciona, solicitar al soporte del hosting una importación desde sus backups.
Recuperar wp_users y wp_usermeta tras eliminación accidental
- Exportar ambas tablas en formato SQL.
- Importar primero wp_users, luego wp_usermeta.
- Ejecutar verificación de correspondencia de IDs.
Query de verificación final:
sql
SELECT u.ID, COUNT(m.umeta_id) AS metas
FROM wp_users u
LEFT JOIN wp_usermeta m ON u.ID = m.user_id
GROUP BY u.ID
LIMIT 20;
Para recuperar datos a nivel de fila o hasta un punto en el tiempo es imprescindible detallar el uso de binlogs y mysqlbinlog. Un flujo práctico sería:
- Identificar el binlog y el intervalo temporal relevante (por ejemplo usando SHOW BINARY LOGS y mysqlbinlog --start-datetime/--stop-datetime)
- Extraer las transacciones del intervalo con mysqlbinlog --start-datetime='2026-03-01 10:00:00' --stop-datetime='2026-03-01 10:30:00' /var/lib/mysql/binlog.000012 > tramo.sql
- Revisar tramo.sql para filtrar únicamente las sentencias que afectan a la tabla objetivo (buscar recurrentemente el nombre de la tabla o usar mysqlbinlog --database=nombre_bd). Si los binlogs usan formato ROW, añadir --base64-output=DECODE-ROWS -vv permite ver los cambios por fila y localizar sólo los eventos de la tabla afectada; para aplicar, ejecutar mysql -u usuario -p nombre_bd < tramo_filtrado.sql. Advertencia práctica: antes de aplicar binlogs en producción, ensayar en un entorno clon y mantener siempre un dump de rollback de las tablas destino, porque la reproducción indiscriminada puede afectar otras tablas si no se filtran las transacciones.
Paso 6: automatizar backups granulares con scripts y WP-CLI
Principios: rotación, cifrado, logs y alertas. Ejecutar pruebas periódicas de restauración.
Script Bash reproducible (ejemplo comentado):
bash
BACKUP_DIR=/backups/$(date +%F)
mkdir -p "$BACKUP_DIR"
DB_NAME=$(wp config get DB_NAME)
DB_USER=$(wp config get DB_USER)
DB_PASS=$(wp config get DB_PASSWORD)
DB_HOST=$(wp config get DB_HOST)
TABLES=(wp_posts wp_postmeta wp_users)
for t in "${TABLES[@]}"; do
mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS" --single-transaction --quick "$DB_NAME" --tables "$t" | gzip > "$BACKUP_DIR/$t.sql.gz"
done
tar -czf - "$BACKUP_DIR" | openssl enc -aes-256-cbc -salt -out "$BACKUP_DIR.tar.gz.enc" -k "$ENCRYPT_PASS"
find /backups -maxdepth 1 -type d -mtime +14 -exec rm -rf {} /;
Puntos críticos: no dejar contraseñas en crontab. Usar archivo .my.cnf con permisos 600 o variables de entorno con permisos restrictivos.
Ejemplo crontab diaria (00:30):
cron
30 0 * * * /usr/bin/bash /usr/local/bin/backup_tables.sh >> /var/log/backup_tables.log 2>&1
Automatización sin SSH: usar plugins con programación y envío a S3/GCP. Verificar compatibilidad con el proveedor de hosting.
Dato operativo: WordPress lidera la web con aproximadamente 43% de sitios (2024). Esto justifica políticas de backup estrictas en sitios de alto tráfico.
Para bases de datos muy grandes (decenas de millones de filas) las técnicas comunes (mysqldump --single-transaction) pueden tener efectos secundarios: una transacción larga impide la purga de UNDO y consume espacio, y seleccionar por OFFSET es ineficiente. Reglas prácticas:
- Exportar por rangos en la clave primaria con WHERE id BETWEEN X AND Y (ej. exportar bloques de 100k filas), no usar OFFSET.
- Preferir operaciones desde una réplica para no impactar el maestro.
- Usar herramientas como pt-archiver para extraer filas incrementalmente sin bloquear (pt-archiver --source h=host,D=db,t=wp_posts --txn-size=1000 --limit=1000 --where "post_date >= '2026-01-01'" --purge=false --file /tmp/posts_chunk.sql).
- Al importar, respetar el orden de tablas relacionadas o desactivar temporalmente las FK y ejecutar comprobaciones posteriores.
- Documentar y automatizar los chunks en scripts con backoff entre bloques para limitar I/O. Estas tácticas reducen el riesgo de crear transacciones muy largas y mantienen la base usable durante el proceso.
Playbook operativo: errores que arruinan el resultado y cuándo no funciona este método
Errores que rompen la restauración
- Importar un dump sobre una tabla existente sin respaldarla antes. El error típico aquí es asumir que el SQL restaurará filas antiguas sin comprobar esquema.
- Ignorar dependencias entre tablas: restaurar sólo wp_posts sin wp_postmeta causa funcionalidades rotas.
- No verificar collation/charset: caracteres extraños o fallos en INSERT.
Cuándo no aplicar restauración por tabla
- Cambios de esquema simultáneos en varias tablas.
- Corrupción física de ficheros InnoDB.
- Cuando el proveedor ya ofrece snapshots atómicos y PITR.
Matriz de decisión rápida
- Si hay SSH y la tabla es InnoDB y el maestro no puede soportar I/O: exportar desde réplica.
- Si solo hay panel y límites de upload: usar phpMyAdmin por tablas o plugin certificado.
- Si se necesita recuperación a nivel de fila: usar binlogs / PITR.
Comparativa técnica
| Método |
Velocidad |
Impacto I/O |
Necesidad de acceso |
Complejidad |
| mysqldump (tablas) |
Media |
Bajo/Medio |
SSH |
Baja |
| phpMyAdmin export |
Baja a media |
Variable |
Panel |
Baja |
| Réplicas + dump |
Rápida |
Muy bajo en maestro |
SSH + réplica |
Media |
| Percona XtraBackup |
Muy rápida (físico) |
Bajo |
Acceso a FS / DBA |
Alta |
| Binlogs / PITR |
Variable |
Muy bajo |
Acceso a binlogs |
Alta |
Excepción: Si el hosting devuelve snapshots atómicos, preferirlos para fallos masivos. No aplicar dumps por tabla en ese caso.
Recomendación operativa: programar pruebas de restauración trimestrales (4 veces al año). Esta práctica se viene adoptando desde hace dos años en equipos que gestionan tiendas con alto volumen.
Preguntas frecuentes
¿Cómo hacer un backup en WordPress?
Respuesta: usar plugin o export manual con mysqldump y rsync. En entornos con SSH, mysqldump por tabla y rsync de wp-content es la opción más flexible.
Para copias completas usar wp db export o mysqldump y sincronizar wp-content con rsync. Para copias granulares exportar solo las tablas críticas. Comprimir y cifrar antes de subir a S3 o GCP. Probar la restauración en staging tras cada cambio mayor.
¿Dónde están las copias de seguridad de WordPress?
Respuesta: pueden estar en el servidor, en el panel del hosting o en almacenamiento remoto.
En hosting compartido suelen ubicarse en áreas de backup del proveedor (cPanel/Plesk). Plugins almacenan en S3, Dropbox o GCP. Snapshots de proveedor cloud quedan en el data center. Comprobar la retención y probar accesos. Para cumplimiento RGPD (2018) mantener datos en la UE cuando proceda.
¿Puede WordPress manejar una base de datos grande?
Respuesta: sí, con ajuste de infraestructura y estrategias específicas.
Es necesario escalado horizontal (réplicas), índices adecuados, caching y backups físicos como Percona XtraBackup o snapshots LVM. En grandes volúmenes, exportar desde réplica evita impacto. Monitorizar queries y planificar RTO/RPO.
¿Cuál es el mejor plugin de caché para WordPress?
Respuesta: depende del entorno y del hosting.
Opciones habituales: WP Super Cache, W3 Total Cache y LiteSpeed Cache. Algunas plataformas gestionadas ya integran caching a nivel servidor. La caché reduce I/O y mejora tiempos, pero no sustituye a las copias de seguridad.
¿Se pueden restaurar solo filas específicas?
Respuesta: sí, con binlogs o con dumps parciales usando WHERE.
Para filas concretas usar mysqldump con --where o mysqlbinlog para aplicar transacciones hasta un punto. Filtrar por tabla puede requerir procesamiento de binlogs. Estos métodos requieren mayor cuidado para mantener consistencia referencial.
¿Cómo evitar romper relaciones entre tablas al restaurar?
Respuesta: exportar y restaurar dependencias en orden y verificar FK.
Identificar constraints en information_schema, desactivar temporalmente FOREIGN_KEY_CHECKS solo cuando se tienen respaldos y comprobaciones. Restaurar tablas referenciadas primero (por ejemplo wp_posts antes de wp_postmeta) y ejecutar queries de verificación. Mantener dump pre_restore para rollback inmediato.
Cierre operativo, pasos siguientes y recursos
Cinco mandamientos para respaldos por tabla:
- Respaldar esquema y datos de la tabla antes de tocar nada.
- Validar versión MySQL y collation antes de importar.
- Probar restauraciones en staging trimestralmente.
- Mantener backlog cifrado y en región UE cuando haya datos personales.
- Documentar cada restauración y conservar dump pre_restore.
Checklist de acción inmediata (ejecutar ahora):
- Identificar 3 tablas críticas y hacer un dump inmediato de ellas.
- Guardar los dumps cifrados en remoto y notificar al equipo.
- Programar una restauración de prueba en staging esta semana.
Recursos y documentación oficial:
Nota final: si faltan binlogs, o si existe corrupción de archivos InnoDB, escalar a DBA o al soporte del hosting y solicitar acceso a snapshots del proveedor. El proceso aquí descrito no funciona para corrupción física.
