Cómo automatizar de forma segura las copias de seguridad de WordPress
Publicado el 7 de noviembre de 2026
Una copia de seguridad de WordPress solo es útil si contiene los datos correctos y se puede restaurar antes de que la interrupción afecte al negocio. Para automatizar de forma segura las copias de seguridad de WordPress, programa tanto los archivos como las exportaciones de la base de datos, envía copias fuera del servidor de producción y verifica que la restauración realmente funcione. Un trabajo de copia de seguridad que informa que se completó correctamente, pero guarda un archivo vacío, no ofrece protección. Es solo un problema muy cortés a la espera del viernes por la tarde.
Qué debe incluir una copia de seguridad completa de WordPress
WordPress no es una sola cosa. El contenido, la configuración, los plugins, los temas, los archivos multimedia subidos y los datos de los usuarios de tu sitio se distribuyen entre el sistema de archivos y la base de datos. Para una recuperación completa se necesitan ambos componentes.
La base de datos contiene entradas, páginas, pedidos de WooCommerce, cuentas de clientes, envíos de formularios, ajustes y otros contenidos que cambian. El sistema de archivos contiene los archivos principales de WordPress, plugins, temas, archivos subidos y archivos como `wp-config.php`. Si solo restauras los archivos, es posible que el sitio se cargue con contenido antiguo o que falte contenido. Si solo restauras la base de datos, es posible que esta apunte a archivos inexistentes.
Para muchos sitios empresariales, el mínimo práctico es una copia de seguridad diaria de la base de datos y una copia diaria del sitio completo. Las tiendas de comercio electrónico, las plataformas de membresía, los sistemas de reservas y los entornos de páginas de destino de SaaS con mucho tráfico pueden necesitar copias de seguridad de la base de datos más frecuentes, ya que pueden recibirse pedidos y datos de clientes cada hora. La frecuencia debe reflejar cuántos datos puedes permitirte perder en la práctica, no lo que resulte más cómodo.
Elige el nivel adecuado para la automatización
Hay tres formas habituales de automatizar las copias de seguridad de WordPress: usar un plugin de copias de seguridad de WordPress, el panel de control del alojamiento o un servicio gestionado, y trabajos a nivel del servidor. Ninguna es la mejor en todos los casos. La opción adecuada depende de quién gestione el servidor, del tamaño del sitio y de la rapidez con la que necesites recuperarlo.
Copias de seguridad con plugins
Un plugin suele ser la opción más sencilla para un sitio pequeño. Puede crear archivos comprimidos, programar tareas y enviar copias de seguridad a un almacenamiento remoto sin acceso al shell. Esto ofrece visibilidad directa a los propietarios del sitio y resulta útil cuando el plan de alojamiento no incluye un servicio de copias de seguridad.
La contrapartida es la carga del servidor. Comprimir una biblioteca multimedia grande mientras el sitio atiende a sus visitantes puede consumir CPU, memoria, E/S de disco y procesos de PHP. En un entorno compartido con mucho tráfico o en un VPS pequeño, los trabajos de copia de seguridad pueden agotar el tiempo de espera o ralentizar las páginas de pago. Siempre que sea posible, configura el trabajo para que se ejecute durante las horas de menor tráfico y supervisa sus primeras ejecuciones en lugar de dar por hecho que la programación funciona bien.
Copias de seguridad del alojamiento o gestionadas
Las copias de seguridad a nivel del alojamiento se ejecutan fuera de WordPress, lo que suele ser más seguro si falla un plugin, se produce un incidente de malware o una actualización de WordPress sale mal. Un sistema de copias de seguridad gestionado puede capturar bases de datos y archivos sin depender de que la aplicación del sitio siga funcionando correctamente.
Este enfoque reduce la cantidad de componentes móviles dentro de WordPress y suele facilitar la restauración a nivel de infraestructura. Para las empresas que no quieren encargarse por sí mismas de mantener plugins de copias de seguridad, programaciones, credenciales de almacenamiento y reglas de alerta, las copias de seguridad gestionadas del alojamiento son una opción más tranquila. En kodu.cloud, este tipo de tareas operativas se puede gestionar junto con la supervisión del servidor y el soporte, en lugar de dejarlo como un recordatorio mensual que nadie disfruta.
Copias de seguridad a nivel del servidor
Un VPS o un servidor dedicado te ofrece más control. Puedes usar tareas programadas para volcar las bases de datos, archivar los archivos de la aplicación, cifrar el resultado y transferirlo a un destino de almacenamiento independiente. Los desarrolladores y las agencias suelen preferir esta opción porque permite adaptar la programación, la retención, las exclusiones y los registros a cada sitio.
Más control también implica más responsabilidad. El script de copia de seguridad necesita gestión de errores, espacio disponible en disco, permisos, supervisión del almacenamiento y documentación de restauración. Es bastante común que un comando programado falle silenciosamente durante tres semanas, así que conviene tomarlo en serio.
Diseña un calendario de copias de seguridad según las necesidades de recuperación
Empieza con dos preguntas: ¿cuántos datos recientes puede perder la empresa y cuánto tiempo puede estar el sitio fuera de servicio? Estos son el objetivo de punto de recuperación y el objetivo de tiempo de recuperación. No hace falta que uses las siglas en una reunión, pero sí debes conocer las respuestas.
Un sitio informativo que cambia dos veces al mes puede estar suficientemente protegido con copias de seguridad diarias y una retención de entre 14 y 30 días. Un sitio de agencia con mucho contenido puede beneficiarse de copias de seguridad completas diarias y de una copia antes de las actualizaciones importantes. Una tienda WooCommerce requiere más atención: las copias diarias de los archivos no bastan si se registran pedidos durante todo el día.
Para una tienda activa, considera hacer copias de seguridad de la base de datos cada hora o cada pocas horas, copias diarias del sistema de archivos y una copia antes de actualizar WooCommerce, los plugins de pago, los temas o el núcleo de WordPress. Evita conservar una sola generación de copias de seguridad. Si la corrupción, el spam o el malware llegaron al sitio hace varios días, la copia de ayer podría contener el mismo problema.
La retención tiene un coste. Más puntos de restauración requieren más almacenamiento, capacidad de transferencia y mantenimiento. Una política sensata suele conservar varias copias diarias recientes, algunas semanales y un pequeño número de copias mensuales. Las cifras exactas dependen del sitio y de las necesidades de cumplimiento, pero el principio no cambia: conserva suficiente historial para recuperarte de un problema que se descubra tarde.
Conserva al menos una copia fuera del servidor de producción
No consideres que una copia de seguridad guardada junto al sitio web sea un plan de recuperación ante desastres. Si falla el disco del servidor, se elimina una cuenta, el ransomware llega al almacenamiento montado o se ejecuta un comando de limpieza equivocado con demasiada confianza, los datos de producción y la copia de seguridad podrían desaparecer a la vez.
Usa un almacenamiento de copias de seguridad independiente, con credenciales propias y, preferiblemente, un dominio de fallos distinto. Puede ser almacenamiento de objetos, un servidor de copias de seguridad u otro proveedor. Cifra los archivos antes de transferirlos si contienen registros de clientes, datos de cuentas o archivos privados subidos. Mantén las claves de cifrado y las credenciales de almacenamiento separadas de la raíz web y del repositorio.
El conocido principio 3-2-1 sigue siendo útil: conserva tres copias de los datos importantes, en dos tipos de almacenamiento, y guarda una copia fuera de las instalaciones. No hace falta convertirlo en un ritual. Es simplemente una forma de evitar que un solo incidente se convierta en una pérdida total.
Excluye lo que no sea necesario respaldar
Las cachés grandes, los archivos temporales, los registros de depuración, los artefactos de implementación y las cachés de imágenes generadas pueden ralentizar las copias de seguridad y encarecerlas sin mejorar la recuperación. Por lo general, es sensato excluir estos archivos, siempre que se puedan volver a generar de forma segura.
Ten cuidado con los archivos subidos. El directorio `wp-content/uploads` suele contener imágenes de productos, documentos, archivos enviados por usuarios y archivos de la biblioteca multimedia. Normalmente, debe permanecer en la copia de seguridad. También hay que revisar los directorios personalizados de la aplicación, el almacenamiento no estándar de los plugins y los archivos que estén fuera de la raíz de WordPress. Puede que un desarrollador haya colocado recursos esenciales en un lugar inesperado. Por desgracia, el servidor no es adivino.
Antes de finalizar las exclusiones, compara el contenido del archivo con lo que necesita la aplicación tras una restauración limpia. Una copia de seguridad más pequeña solo es buena si permite restaurar el negocio.
Haz visibles los fallos de las copias de seguridad
La automatización sin informes es solo una automatización parcial. Configura alertas para los trabajos fallidos, las transferencias incompletas, el almacenamiento insuficiente, los archivos inusualmente pequeños y las copias de seguridad cuya antigüedad supere lo establecido en tu política. El correo electrónico es aceptable en un entorno pequeño, pero un canal de alertas supervisado es mejor para los equipos responsables de varios sitios de clientes.
Revisa los registros después de la configuración y tras cambios importantes en PHP, WordPress, las versiones de la base de datos, las credenciales de almacenamiento o los permisos del sistema de archivos. Una copia de seguridad correcta debe tener una marca de tiempo clara, un intervalo de tamaño previsto, una confirmación del destino y un resultado de retención.
Supervisa también el espacio disponible en disco del servidor de origen. Algunas herramientas crean el archivo completo localmente antes de subirlo. Un servidor con el disco casi lleno puede fallar durante la copia de seguridad y, al mismo tiempo, provocar problemas de rendimiento. No es la situación de disco más agradable, pero se puede evitar.
Prueba las restauraciones antes de que haya una emergencia
Una prueba de restauración es el momento en que las promesas sobre las copias de seguridad se convierten en hechos operativos. Al menos cada trimestre, restaura una copia reciente en un entorno de pruebas o en una ubicación temporal independiente. Confirma que WordPress se inicia, la base de datos se conecta, los archivos multimedia se cargan, los usuarios pueden iniciar sesión y las funciones empresariales clave funcionan.
En una tienda en línea, prueba las páginas de productos, el comportamiento del carrito, los ajustes relacionados con el pago, los registros de pedidos, la configuración del correo transaccional y las dependencias de los plugins de pago. No coloques una copia restaurada en un lugar desde el que pueda enviar correos reales a los clientes o aceptar pagos reales. Desactiva primero el correo saliente y las operaciones de pago en el entorno de prueba.
Documenta los pasos de restauración mientras los realizas. Anota dónde se almacena la copia de seguridad, qué base de datos hay que importar, dónde se cambian los valores de configuración y cómo se gestionan el DNS o las URL de la aplicación. Durante una interrupción real, una guía de ejecución breve y actualizada ahorra más tiempo que la memoria de cualquiera.
Protege el propio proceso de copia de seguridad
Usa credenciales de almacenamiento específicas con solo los permisos necesarios para leer y escribir los datos de las copias de seguridad. Activa la autenticación multifactor en la cuenta de almacenamiento y en el panel de control del alojamiento. Mantén actualizados WordPress, los plugins, los paquetes del servidor y las herramientas de copia de seguridad, ya que un sitio comprometido también puede atacar las credenciales de copia de seguridad accesibles.
Si tus copias de seguridad están cifradas, prueba el descifrado durante los simulacros de restauración. Un archivo cifrado sin la clave correcta es perfectamente seguro y perfectamente inútil. Guarda las instrucciones de recuperación en una ubicación protegida que siga estando disponible si el servidor de producción deja de estarlo.
Las copias de seguridad automatizadas deben reducir tu carga de trabajo, no ocultar riesgos detrás de un indicador verde de estado. Establece la programación, guarda copias fuera de las instalaciones, supervisa los trabajos y practica la restauración mientras todo está en calma. Así podrás hacer cambios en WordPress con mucha más tranquilidad.
Andres Saar, ingeniero de atención al cliente