Respaldos por tabla para minimizar la pérdida de datos

¿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

1. Identificar tablas críticas y dependencias. Comprobar engine y collation.
2. Exportar esquema y datos de las tablas objetivo con flags transaccionales.
3. Guardar dump de la tabla actual como rollback inmediato.
4. Restaurar en modo controlado (desactivar FK si procede). Comprobar duplicados.
5. Ejecutar pruebas funcionales en staging y en producción fuera pico.
6. Documentar y rotar backups en remoto, cifrados y con retención.

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.

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.

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:

1. Generar backup físico con xtrabackup --backup --target-dir=/backups/xtrabackup
2. Preparar el backup: xtrabackup --prepare --target-dir=/backups/xtrabackup
3. 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.
4. 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:

1. Poner modo mantenimiento si la tabla afecta operaciones críticas.
2. Respaldar la tabla existente (dump pre_restore).
3. Opcional: SET FOREIGN_KEY_CHECKS=0;
4. Importar el SQL: mysql -u user -p DB < backup_tabla.sql
5. Reactivar FK: SET FOREIGN_KEY_CHECKS=1;
6. 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

1. Exportar ambas tablas en formato SQL.
2. Importar primero wp_users, luego wp_usermeta.
3. 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:

1. Identificar el binlog y el intervalo temporal relevante (por ejemplo usando SHOW BINARY LOGS y mysqlbinlog --start-datetime/--stop-datetime)
2. 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
3. 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.

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:

1. Exportar por rangos en la clave primaria con WHERE id BETWEEN X AND Y (ej. exportar bloques de 100k filas), no usar OFFSET.
2. Preferir operaciones desde una réplica para no impactar el maestro.
3. 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).
4. Al importar, respetar el orden de tablas relacionadas o desactivar temporalmente las FK y ejecutar comprobaciones posteriores.
5. 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

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):

1. Identificar 3 tablas críticas y hacer un dump inmediato de ellas.
2. Guardar los dumps cifrados en remoto y notificar al equipo.
3. Programar una restauración de prueba en staging esta semana.

Recursos y documentación oficial:

• WordPress.org
• Percona XtraBackup docs

• Actualizar multilenguaje: evitar pérdida de traducciones
• Backups para foros y grandes bases de datos (bbPress)

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.