Guardar solo los archivos de WordPress no protege tu web por completo. Las entradas, páginas, comentarios, usuarios, pedidos de WooCommerce y muchos ajustes viven en la base de datos MySQL o MariaDB; si la pierdes, subir de nuevo los archivos no recuperará esa información.
✉
¿Quieres más información? Escríbenos y te orientamos
¿El backup del hosting incluye tu base de datos?
No lo des por hecho: una copia del hosting debe incluir los archivos de WordPress y la base de datos MySQL o MariaDB.
Las tres preguntas para tu hosting
Pregunta por escrito si la copia incluye base de datos, si permite restaurar una sola instalación de WordPress y cuál es el tiempo real de recuperación. También pide saber si puede restaurarse primero en un entorno de pruebas, una copia privada donde verificar que no se pierde nada.
Archivos y SQL no son lo mismo
Un archivo SQL es un texto estructurado que contiene instrucciones para reconstruir los datos de MySQL o MariaDB. Sin ese archivo, no volverán las páginas, cuentas ni ajustes aunque recuperes la carpeta wp-content mediante FTP.
Plugin, dump o snapshot: cuál te protege
El plugin adecuado para principiantes
Para una primera web, un plugin con copia remota suele ser la opción más fácil de restaurar.
Método Recuperación habitual RPO orientativo Coste habitual
Plugin con nube Desde WordPress 12 a 24 horas 0 a 80 €/año mysqldump o mariadb-dump phpMyAdmin o terminal Según programación Incluido con servidor Mariabackup Administrador Horas o minutos Depende del hosting Snapshot de volumen Panel del proveedor Horas o minutos Depende del servidor
Dump, mariabackup y snapshots
El camino de una copia que sí sirve
WordPress y base de datos
→
Plugin o dump programado
→
Google Drive, S3 o disco externo
→
Prueba de restauración
Un backup lógico con mysqldump o mariadb-dump genera archivos SQL portables y suele ser la mejor opción para una base de datos WordPress pequeña o mediana, cuando interesa restaurar una sola base o incluso objetos concretos. En InnoDB, --single-transaction obtiene una copia consistente sin bloquear las escrituras durante toda la exportación; no ofrece esa garantía para tablas no transaccionales como MyISAM, que pueden requerir una ventana de mantenimiento o bloqueo. Mariabackup realiza copias físicas y resulta más adecuado para bases grandes, servidores propios y objetivos de recuperación rápidos, pero exige compatibilidad entre versiones y acceso administrativo.
Un snapshot de volumen es rápido, aunque solo es fiable si el proveedor coordina la instantánea con MySQL/MariaDB o si se detiene correctamente la escritura. Elige según tu RPO, es decir, cuánto dato puedes perder, y tu RTO, el tiempo máximo aceptable para volver a operar.
Configura copias remotas automáticas sin ser técnico
Programa una copia diaria de la base de datos y una semanal de archivos si tu web cambia poco. Si recibes pedidos, reservas o formularios cada día, programa ambas partes cada 12 o 24 horas y guarda varias versiones.
Configuración mínima que funciona
En el plugin, marca base de datos y archivos, conecta Google Drive o Dropbox y conserva entre 7 y 14 versiones . Crea una copia manual antes de actualizar WordPress, WooCommerce o un plugin que afecte a pagos y formularios.
🛒
Producto recomendado
Un disco duro externo añade un segundo soporte físico para descargar una copia cifrada cada mes. No sustituye la nube, pero evita depender de una sola cuenta o proveedor.
Permite conservar una copia desconectada de Internet ante un ataque de ransomware
Da espacio para guardar varias exportaciones SQL comprimidas y cifradas
Facilita llevar una copia a otro lugar distinto del hosting principal
Ver en Amazon →
Privacidad y datos personales
Para proteger la privacidad y los datos personales, las copias automáticas ganan valor cuando siguen la regla 3-2-1 : conserva al menos tres copias, en dos soportes distintos y una fuera del hosting. Un cron diario puede generar el dump, comprimirlo y enviarlo a un backup remoto, mientras una política de rotación mantiene, por ejemplo, 7 copias diarias, 4 semanales y 6 mensuales según el espacio disponible y las obligaciones de conservación. No basta con comprobar que existe el archivo: una vez al mes realiza una prueba de restauración de la base de datos de WordPress en un entorno privado, verifica tablas, usuarios, pedidos de WooCommerce y fechas recientes, y registra cuánto tarda el proceso.
Esa prueba revela antes de una incidencia si faltan permisos, si la copia está corrupta o si el RTO real no cumple lo previsto.
✉
¿Quieres más información? Escríbenos y te orientamos
No restaures a ciegas
Verifica cualquier copia antes de restaurarla.
Comandos seguros para una exportación
Para crear una copia de seguridad de la base de datos desde SSH sin exponer la contraseña en el historial, usa un archivo de credenciales con permisos restrictivos o deja que el cliente la solicite: set -o pipefail; mysqldump --single-transaction --routines --events --triggers --default-character-set=utf8mb4 nombre_bd | gzip -9 > copia.sql.gz. En MariaDB puede usarse mariadb-dump con las mismas opciones básicas. Comprueba que el archivo no está dañado mediante gzip -t copia.sql.gz y conserva también la fecha, versión del servidor y tamaño esperado.
Restaurar solo tras probar
Restaura primero en una base vacía de pruebas con gunzip -c copia.sql.gz | mysql -u usuario -p nombre_bd. Después entra en WordPress, abre una entrada, revisa usuarios y confirma que los pedidos o formularios esperados existen.
Un plugin no basta para una tienda con muchos pedidos, una membresía o reservas continuas. Si solo puedes perder minutos de datos, necesitas binlogs, que registran cambios uno a uno, y recuperación a un punto en el tiempo (PITR), gestionados por el hosting o por un profesional. Define también cuánto tiempo debe tardar la recuperación antes de contratar el servicio.
Para proteger datos personales antes de enviarlos a un backup remoto, cifra el archivo con gpg --symmetric copia.sql.gz; después súbelo a Google Drive, Dropbox, S3 u otro destino fuera del servidor. La restauración debe probarse en una base vacía y aislada con gunzip -c copia.sql.gz | mysql -u usuario -p nombre_bd_pruebas.
Lo que más preguntan
¿Cómo hago una copia de MySQL para WordPress?
Usa un plugin que copie archivos y base de datos a Google Drive o Dropbox cada 24 horas. Si tienes SSH, mysqldump --single-transaction crea un archivo SQL, pero exige probar la restauración.
¿El backup del hosting ya protege mi WordPress?
Solo te protege si incluye archivos, MySQL o MariaDB, varias fechas y una restauración comprobada. Confirma con el proveedor una retención de entre 7 y 30 días y el proceso para restaurar una sola web.
¿Qué plugin de copia de seguridad para WordPress?
UpdraftPlus y WPvivid Backup Plugin son opciones gratuitas válidas si configuras destino remoto y retención. BackWPup también sirve, pero revisa que el archivo llegue a la nube antes de confiar en él.
¿Cada cuánto debo copiar la base de datos?
Una web con pedidos o formularios debe copiarla cada 12 o 24 horas. Un blog que publica una vez por semana puede hacerlo semanalmente, más una copia antes de actualizaciones.
¿Puedo restaurar un archivo SQL en phpMyAdmin?
Sí, phpMyAdmin permite importar un archivo SQL si el tamaño cabe en el límite del hosting. Hazlo primero en una base de pruebas, porque importar borra o reemplaza datos según el contenido del archivo.
¿Cuál es la diferencia entre MySQL y MariaDB?
MySQL y MariaDB suelen aceptar exportaciones SQL básicas de WordPress entre versiones cercanas. Evita mezclar copias físicas de Mariabackup o funciones avanzadas sin confirmar versiones, motor y compatibilidad.
Lo esencial: una copia de archivos sin SQL no recupera el contenido ni los usuarios de WordPress.
Lo esencial: guarda copias automáticas fuera del hosting y conserva entre 7 y 14 versiones.
Lo esencial: elige un plugin si empiezas, y deja binlogs y PITR para cambios continuos.
Lo esencial: prueba una restauración antes de que un incidente te obligue a hacerlo.
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
