Copias de seguridad en WordPress: qué guardar, cada cuánto y cómo restaurarlas

Una copia de seguridad de WordPress son dos cosas: los ficheros del sitio y la base de datos. Hacen falta las dos para restaurar la web, y la copia solo sirve si está guardada fuera del servidor y has probado a restaurarla al menos una vez.

Esta guía explica qué incluye cada parte, cada cuánto conviene copiarla, tres formas de hacerlo (plugin, panel del hosting y línea de comandos) y el procedimiento para comprobar que la copia funciona. Es una de las tareas que cubre un servicio de mantenimiento de WordPress, pero puedes montarla tú si tienes una hora y algo de paciencia.

Qué incluye una copia de seguridad de WordPress

Un sitio WordPress vive en dos sitios distintos. Los ficheros están en el servidor web. Los textos, los ajustes, los usuarios y los comentarios están en una base de datos (MySQL o MariaDB). Según la documentación oficial de WordPress, copiar los ficheros no copia la base de datos, porque son sistemas separados.

Parte	Qué contiene	Cómo se copia
Ficheros	Núcleo de WordPress, plugins, temas, imágenes subidas, wp-config.php, .htaccess	FTP o SFTP, administrador de archivos del panel, tar o rsync
Base de datos	Entradas, páginas, comentarios, usuarios, ajustes de plugins	Exportación SQL desde phpMyAdmin o wp db export

No todos los ficheros valen lo mismo. El núcleo de WordPress se puede volver a descargar limpio. Lo que no se puede reponer es la carpeta wp-content (tus imágenes, tus plugins y tu tema) y el fichero wp-config.php, que guarda las credenciales de la base de datos.

Por qué no basta con la copia que hace tu hosting

La mayoría de los hostings copian el servidor entero, y eso está bien como segunda red. El problema es de acceso y de tiempo. La propia documentación de WordPress señala que pedir una copia al proveedor lleva tiempo y que la recuperación rápida es crítica, así que conviene saber copiar tus ficheros por tu cuenta.

Hay otra razón: una copia que vive en el mismo servidor que la web desaparece con el servidor. Si se borra la cuenta, falla el disco o entra un atacante y borra todo, se va la web y se va la copia.

Y una advertencia sobre dónde dejas las copias. Al revisar 71 webs WordPress en octubre de 2026, retiramos de la carpeta pública copias de la base de datos en formato .sql y un CSV de pedidos que cualquiera podía descargar escribiendo la dirección en el navegador. Las habían dejado allí como copia «de paso». Una copia accesible desde internet es una fuga de datos.

La regla 3-2-1 aplicada a WordPress

La regla 3-2-1 aparece tal cual en las guías de CISA y del INCIBE: tres copias de los datos (el original y dos copias), en dos tipos de soporte distintos, y una de ellas fuera del lugar donde está el original.

Aplicada a una web WordPress, un reparto razonable es este (es nuestra traducción de la regla, no una norma de WordPress):

1. La web en producción, que es el original.
2. Una copia en el panel del hosting o generada por un plugin en el propio servidor, útil para recuperar rápido.
3. Una copia descargada o enviada a un almacenamiento externo, separado del hosting y con otra cuenta de acceso.

El INCIBE recomienda cifrar las copias que se envían a la nube. Con WordPress tiene sentido por una razón concreta: wp-config.php contiene la contraseña de la base de datos, y la base de datos contiene tus usuarios.

Cada cuánto hacer copias y cuántas conservar

La guía oficial da una pauta clara: una copia semanal en un sitio pequeño, diaria si el sitio se actualiza mucho, y siempre una copia justo antes de actualizar algo o de mover la web. También recomienda conservar entre tres y cinco copias recientes en sitios distintos.

Para decidir la frecuencia ayuda una pregunta práctica: cuánto contenido nuevo puedes permitirte rehacer a mano. Una web de presentación que cambia dos veces al año aguanta una copia semanal. Una tienda con pedidos diarios necesita copia diaria de la base de datos como mínimo, porque los pedidos no se pueden reescribir.

La retención importa tanto como la frecuencia. Un ataque o un error pueden pasar desapercibidos varios días, y si solo conservas la copia de anoche, esa copia ya puede llevar el problema dentro. Por eso CISA aconseja poder volver atrás al menos siete días.

Tres formas de hacer una copia de seguridad de WordPress

Con un plugin

Es el camino más corto. Entre los plugins de copia de seguridad están UpdraftPlus, BackWPup, Duplicator, All-in-One WP Migration y Jetpack VaultPress Backup. Todos programan copias y varios las envían a un almacenamiento externo.

Para elegir entre ellos, mira cuatro cosas:

• Que programe copias de forma automática.
• Que pueda enviarlas fuera del servidor (otra nube o un servidor propio).
• Que permita restaurar sin entrar en el escritorio de WordPress, por si la web no carga.
• Cómo se comporta en webs grandes: una copia consume recursos y, en hostings modestos, puede exigir subir el límite de memoria o de tiempo de PHP. Si ves cortes, es el primer sitio donde mirar (en la guía sobre actualizar PHP en WordPress explicamos cómo ver y cambiar esos valores).

Desde el panel del hosting y phpMyAdmin

Sin plugins, la copia manual consiste en descargar los ficheros y exportar la base de datos:

1. Descarga la carpeta de WordPress por SFTP o con el administrador de archivos del panel. Activa la opción de mostrar archivos ocultos, o te dejarás .htaccess.
2. Abre phpMyAdmin, elige tu base de datos, entra en «Exportar», método «Rápido», formato SQL, y descarga el fichero.

Un detalle de la documentación oficial: la copia completa de cPanel está pensada como archivo y no se puede restaurar desde cPanel. Si tu hosting usa cPanel, para la base de datos usa la opción «Download a MySQL Database Backup», que sí se puede volver a subir.

Con WP-CLI desde la terminal

Si tienes acceso SSH, WP-CLI hace la base de datos en una línea. Desde la carpeta de WordPress:

# Copia de la base de datos (usa las credenciales de wp-config.php)
wp db export ~/copias/web-$(date +%F).sql

# Copia de los ficheros que no puedes reponer
tar -czf ~/copias/web-$(date +%F).tar.gz wp-content wp-config.php

# Envío a otro servidor
rsync -az ~/copias/ usuario@otro-servidor:/ruta/copias/

wp db export ejecuta mysqldump por debajo y escribe el volcado en el fichero que le indiques (documentación de WP-CLI). Para restaurar, wp db import copia.sql importa el volcado en una base de datos que ya exista. Guarda las copias en una carpeta que no cuelgue de la raíz pública de la web, para no repetir el error de los .sql descargables.

Cómo comprobar que tu copia funciona: la prueba de restauración

Una copia que no se ha restaurado nunca es una suposición. La prueba lleva menos de una hora y se hace en un entorno aparte, nunca sobre la web en producción:

1. Elige una copia reciente, no la de ayer que acabas de hacer a mano.
2. Crea un entorno de pruebas: un subdominio protegido con contraseña o una instalación local.
3. Restaura primero los ficheros y después la base de datos. Es el orden que indica la documentación oficial, y el inverso al de la copia (base de datos primero, ficheros después).
4. Si en el entorno de pruebas la base de datos tiene otro nombre, otro usuario u otra contraseña, edita wp-config.php con los nuevos datos.
5. Comprueba la portada, una entrada, las imágenes, el formulario de contacto, el acceso al escritorio y, si hay tienda, un pedido de prueba.
6. Apunta cuánto has tardado. Ese tiempo es lo que te costaría una restauración de verdad.

Haz la prueba al montar el sistema y repítela con calendario, por ejemplo cada trimestre (es un criterio nuestro, no una cifra oficial). El procedimiento es casi idéntico al de migrar WordPress a otro hosting, así que de paso practicas ambas cosas.

Errores habituales con las copias de seguridad

• Dejar la única copia en el mismo servidor que la web.
• Copiar solo la base de datos o solo los ficheros.
• No probar nunca la restauración.
• No hacer copia antes de actualizar plugins, temas o PHP.
• Guardar copias sin cifrar en un sitio compartido, con las credenciales de wp-config.php dentro.
• Dejar copias en una carpeta accesible desde el navegador.
• Fiarse de la reversión automática de WordPress. Existe un mecanismo, propuesto por el equipo de WordPress en 2024, que deshace la actualización automática de un plugin si provoca un error fatal. Solo actúa en ese caso concreto y no protege de un borrado, un ataque o un fallo del servidor.

Las copias y la seguridad de WordPress van juntas: tras un ataque, la copia limpia es lo que permite volver a una web sin rastro del atacante.

Preguntas frecuentes sobre copias de seguridad en WordPress

Si prefieres que lo hagamos nosotros

Montar las copias, vigilar que sigan funcionando y probar restauraciones es trabajo recurrente, y es de lo primero que se abandona. Si prefieres que lo hagamos nosotros, el plan de Blooglee, de MKPRO lleva copias de seguridad automáticas. Puedes ver lo que incluye cada plan en la página de precios y cómo es el hosting WordPress con el que va. Para repasar el resto de tareas, tienes la guía de mantenimiento web.

Fuentes citadas

• Documentación de WordPress sobre copias, ficheros y base de datos: https://developer.wordpress.org/advanced-administration/security/backup/ (consultada el 2 de noviembre de 2026)
• WP-CLI, wp db export: https://developer.wordpress.org/cli/commands/db/export/ y wp db import: https://developer.wordpress.org/cli/commands/db/import/
• CISA, copia de seguridad de datos de empresa: https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/back-up-business-data
• INCIBE, Día Mundial del Backup (31 de marzo de 2020): https://www.incibe.es/empresas/blog/dia-mundial-del-backup-repasamos-importancia-las-copias-seguridad
• Propuesta de reversión automática de actualizaciones (19 de abril de 2024): https://make.wordpress.org/core/2024/04/19/merge-proposal-rollback-auto-update/