El día que tu web muestra un error grave, abres Google Drive con alivio y ves una carpeta de copias. Pero la última es de hace tres meses, ocupa unos pocos megas o no contiene la base de datos. Tener archivos fuera del hosting no garantiza que puedas recuperar WordPress cuando más falta hace.
Un monitor de backups externos te avisa si la copia de tu WordPress no llega, falla o pesa mucho menos de lo habitual, antes de que necesites restaurarla. Comprueba una pregunta sencilla: «¿Tengo una copia correcta y reciente fuera del hosting?». Revisa la fecha, el tamaño y realiza una prueba de recuperación al menos cada seis meses.
Un backup externo solo cuenta si llega y se restaura
Una copia externa protege WordPress solo cuando se cumplen tres condiciones: se crea, llega completa a un lugar distinto del hosting y puede restaurarse. En una pyme de Valencia, por ejemplo, guardar el archivo en la misma cuenta de alojamiento no evita perderlo si el servidor sufre un borrado, un ataque o una suspensión de cuenta.
Una copia dentro del hosting es como guardar una llave de repuesto dentro de la misma casa. Puede ser útil para salir de un apuro pequeño, pero no sirve si no puedes entrar al edificio.
Crear no significa enviar
Un backup automático es una copia que el plugin intenta crear según un horario. UpdraftPlus, BackWPup y otros plugins de WordPress pueden terminar ese proceso correctamente, pero fallar al subir el archivo a Google Drive, Dropbox, Amazon S3 o SFTP.
El error más frecuente que se detecta aquí es confiar en el icono verde del plugin sin abrir el destino externo. Un token de Google Drive caducado, una cuota llena o una contraseña SFTP cambiada pueden cortar el envío tras crear una copia local.
Enviar no significa recuperar
Una copia restaurable debe incluir la base de datos de WordPress , los archivos del núcleo, temas, plugins y la carpeta de subidas. La base de datos guarda entradas, usuarios, ajustes y pedidos; la carpeta de subidas contiene imágenes, PDF y otros archivos.
Un archivo con fecha de hoy no siempre es suficiente. Si el backup solo contiene la base de datos o solo los ficheros, la recuperación quedará incompleta.
Crear una copia, guardarla fuera del servidor y demostrar que se restaura son tres tareas distintas. Completar la primera no prueba las otras dos.
Conocer estas tres pruebas evita una falsa sensación de seguridad. El siguiente paso es decidir cuánto dato puede permitirse perder tu web.
✉
¿Quieres más información? Escríbenos y te orientamos
La antigüedad y el RPO indican si una copia sirve
El RPO , o punto objetivo de recuperación, es la cantidad máxima de datos que aceptas perder desde la última copia válida. Una tienda WooCommerce con pedidos diarios suele necesitar un RPO de 24 horas o menos; una web corporativa que cambia una vez al mes puede aceptar entre 7 y 30 días.
No hay una frecuencia universal. Lo que vale para un portfolio con tres cambios al año no vale para una academia con alumnos, pagos y formularios diarios.
El RPO depende de tus cambios
Si publicas artículos cada semana, una copia diaria suele ser razonable. Si recibes pedidos cada hora, las copias cada 24 horas pueden dejar ventas, stock y datos de clientes fuera de la recuperación.
Piensa en el RPO como la distancia entre dos fotos de tu web. Cuanto mayor sea esa distancia, más trabajo tendrás que rehacer tras una incidencia.
Cinco datos que debes vigilar
El panel o registro de copias de seguridad debería mostrar datos sencillos y comparables:
Última copia correcta: fecha y hora de la última ejecución terminada.Antigüedad: horas o días desde esa copia válida.Tamaño esperado: rango habitual del archivo completo.Tasa de éxito: copias completadas frente a copias programadas.Retención: cuántas versiones antiguas conserva el destino.Un backup de 20 MB cuando normalmente ocupa entre 1 y 2 GB merece revisión inmediata. Puede faltar la carpeta de imágenes, la base de datos o una parte comprimida del archivo.
Lo que cambia todo es lo siguiente: definir el RPO solo sirve si una alerta avisa antes de superar ese límite.
Cuatro alertas evitan descubrir el fallo tarde
Un monitor útil debe avisar por cuatro motivos: fallo de ejecución, retraso, tamaño anómalo y archivo ausente en el destino externo. Estas cuatro señales cubren los casos en que el plugin falla, termina tarde, genera una copia incompleta o pierde una copia que sí había llegado.
La alerta de error es necesaria, pero no basta. Una ejecución puede marcarse como correcta y aun así dejar un backup demasiado pequeño.
Retraso no es un fallo técnico
Una copia diaria que no aparece tras 24 horas ya supera el RPO de una tienda con actividad diaria. Si el proceso suele terminar de madrugada, un margen de entre 6 y 12 horas permite evitar avisos por pequeños retrasos sin esperar varios días.
El retraso pregunta algo fácil: «¿Ha llegado la copia cuando debía?». La respuesta se comprueba mirando la hora del archivo en Google Drive, Dropbox, un bucket de Amazon S3 o una carpeta SFTP.
El tamaño revela omisiones invisibles
Una regla inicial práctica es alertar si el tamaño baja o sube más de un 30% respecto a las últimas copias completas. No es una ley fija, porque una limpieza de imágenes o una importación grande cambia el peso, pero da una señal útil para revisar.
Lo que se ve en la práctica es que los tamaños anómalos suelen revelar exclusiones mal configuradas, falta de espacio temporal o compresiones interrumpidas. La alerta no confirma el problema, pero obliga a mirar antes de necesitar el backup.
Ciclo de control de una copia externa
1. Crear
→
2. Enviar
→
3. Verificar fecha y peso
→
4. Restaurar en staging
Alerta si falla, se retrasa, cambia mucho de tamaño o desaparece.
Estas alertas detectan el síntoma. Ahora conviene elegir una herramienta que alcance tu destino remoto y tu forma de trabajar.
✉
¿Quieres más información? Escríbenos y te orientamos
Compara alertas y destino antes de elegir plugin
La mejor herramienta no es la que promete más copias, sino la que permite comprobar el destino, recibir avisos y restaurar sin dudas. Para una sola web, UpdraftPlus puede bastar con una revisión externa; para agencias, BlogVault o ManageWP aportan un panel central para varios sitios.
Los precios cambian por promociones, impuestos y número de webs. En España, las opciones gestionadas suelen partir de unos 10 a 35 € al mes para una web o un pequeño grupo, mientras que un plugin gratuito exige más comprobaciones manuales.
Qué opción encaja con cada caso
Opción Destino remoto Alertas y panel Coste orientativo UpdraftPlus Drive, Dropbox, S3, FTP/SFTP Correo y revisión manual Gratis o licencia Jetpack VaultPress Backup Nube de Automattic Panel y restauración guiada Suscripción BlogVault Almacenamiento gestionado Panel multisitio Suscripción ManageWP Servicio gestionado Panel para agencias Por sitio y extras
El destino también puede fallar
Google Drive y Dropbox son simples para empezar, pero dependen de permisos y cuota. Amazon Web Services S3 y Backblaze suelen dar más control de retención, aunque exigen entender buckets, claves y reglas de borrado.
SFTP es una conexión cifrada hacia un servidor remoto; FTP normal no cifra usuario ni contraseña. Para datos personales, el RGPD y la LOPDGDD obligan a controlar quién accede a las copias y dónde se almacenan, especialmente si contienen formularios, clientes o pedidos.
⭐
Selección para ti
Un disco externo puede servir como tercera copia desconectada para guardar una exportación cifrada. No sustituye el almacenamiento cloud, pero reduce el riesgo de depender de una sola cuenta.
Permite conservar una copia fuera del hosting y de la cuenta cloud principal
Facilita guardar versiones mensuales antes de cambios importantes
Ayuda a disponer de un archivo local durante una caída prolongada de internet
Ver en Amazon →
La comparación más extendida se queda corta cuando solo mira destinos compatibles. Una herramienta puede conectar con S3 y no avisarte de que una copia ha desaparecido, por eso el siguiente control debe hacerse fuera del plugin.
Comprueba el destino fuera del plugin
La verificación más fiable consiste en abrir el almacenamiento remoto y comprobar fecha, tamaño, número de archivos y acceso con una cuenta autorizada. Hazlo cada semana al principio y, cuando el sistema lleve varios meses estable, al menos una vez al mes.
No necesitas ser técnico. Solo debes comprobar que ves los archivos esperados en la carpeta, bucket o servidor elegido.
Mira fecha, peso y contenido
En Google Drive o Dropbox, abre la carpeta y ordena por fecha. En Amazon S3, revisa el bucket, que es como una carpeta remota con reglas propias; en SFTP, entra con un cliente autorizado y verifica los archivos.
Los backups completos suelen dividirse en varios archivos comprimidos. No confundas un registro de texto con una copia recuperable: el registro cuenta lo ocurrido, pero no contiene tu web.
Revisa permisos y retención
Los permisos pueden romperse cuando se borra la cuenta de un empleado, cambia una contraseña o caduca una autorización API. Un caso habitual es una agencia que configura Drive con el correo personal de un técnico y pierde acceso cuando ese usuario deja la empresa.
Configura una cuenta de empresa, un responsable y un sustituto. Revisa también la retención: conservar entre 7 y 30 versiones puede ser adecuado según el espacio y el RPO, pero una sola copia nunca cubre un archivo corrupto que se subió ayer.
La documentación de seguridad de WordPress.org insiste en separar capas de protección. Ver el archivo remoto confirma existencia; restaurarlo confirma algo más valioso.
Un NAS puede formar parte de las copias de seguridad externas si está en otra ubicación física, se accede mediante VPN o una conexión cifrada y no depende del mismo servidor ni de la misma red que aloja WordPress. El monitor debe comprobar que la tarea ha terminado, que el volumen disponible no está cerca del límite y que el archivo más reciente mantiene un tamaño coherente. Conviene conservar varias versiones mediante instantáneas o retención y probar la restauración de WordPress desde ese NAS en staging.
Un NAS instalado junto al servidor de producción no protege frente a un incendio, robo o fallo eléctrico común; en ese caso es una segunda copia local, no un destino externo suficiente por sí solo.
La monitorización puede ser independiente del plugin de backup. Un sistema de control consulta la carpeta, bucket o servidor remoto con una cuenta de solo lectura y registra la fecha, el nombre y el tamaño de los archivos esperados. Así puede avisar aunque WordPress, su cron o el propio plugin dejen de enviar correos. En Google Drive y Dropbox se vigila la carpeta asignada; en Amazon S3, el prefijo del bucket y las reglas de retención; en SFTP, la ruta remota y la disponibilidad de la conexión.
Para no exponer datos, ese control no necesita descargar todo el backup: basta con validar la presencia de los ficheros, su antigüedad y sus metadatos, además de programar restauraciones reales por separado.
Staging evita restaurar a ciegas en producción
Una prueba de restauración debe hacerse en staging , una copia privada de la web para probar cambios sin tocar la página pública. Prueba una restauración cada 6 meses y también después de cambiar de hosting, plugin, PHP o destino externo.
Restaurar directamente en producción sin una copia actual es como cambiar una rueda en plena autopista. Puede funcionar, pero el riesgo no merece la prisa.
Comprueba lo que no puede faltar
Tras restaurar, abre la portada, varias entradas, imágenes, formularios y el acceso a wp-admin. Si vendes online, comprueba usuarios, pedidos recientes, correos transaccionales y ajustes de pago sin hacer cargos reales.
La práctica demuestra que una restauración parcial suele descubrirse en detalles: imágenes rotas, usuarios ausentes o un plugin que perdió su configuración. Anota qué faltó y corrige la selección del backup antes de confiar en el siguiente.
Define también el RTO
El RTO , o tiempo objetivo de recuperación, responde a otra pregunta: «¿Cuánto tiempo puede estar caída mi web?». Una web informativa puede tolerar entre 4 y 24 horas; una tienda activa puede necesitar un plazo menor, según ventas y atención al cliente.
Antes de restaurar en producción, crea una copia nueva, documenta los pasos y prepara una vuelta atrás. Esto no funciona si el staging usa versiones muy distintas de PHP, WordPress o la base de datos.
Una restauración probada demuestra que el backup sirve. Falta decidir quién actúa cuando el monitor avisa a las tres de la madrugada.
✉
¿Quieres más información? Escríbenos y te orientamos
Una alerta sin responsable no protege la web
Cada alerta de backup necesita un responsable principal, un sustituto y un plazo de respuesta escrito. Para una copia diaria con RPO de 24 horas, revisar un aviso en menos de 12 horas evita que dos fallos seguidos dejen la web sin punto de recuperación válido.
El correo electrónico es una vía de aviso, no un plan. Puede ir a spam, llegar a una persona de vacaciones o quedar enterrado entre newsletters.
Asigna acciones por tipo de alerta
Fallo: revisar registro, espacio libre, memoria y credenciales del destino.Retraso: confirmar si la tarea programada sigue funcionando y lanzar una copia manual si procede.Tamaño anómalo: revisar exclusiones, base de datos y archivos subidos.Archivo ausente: comprobar cuota, reglas de borrado, permisos y actividad de la cuenta.Si no se resuelve dentro del plazo, escala al hosting, al desarrollador o al proveedor del plugin. Una agencia con varios WordPress debería centralizar estas tareas en ManageWP, BlogVault u otro panel, pero mantener una lista de responsables por cliente.
Separa caída web y fallo de copia
El uptime monitoring vigila si la web responde al abrirla. La monitorización de copias vigila si podrás recuperarla, y ambas son necesarias porque una web puede funcionar perfectamente mientras lleva 10 días sin una copia válida.
Antes de continuar, hay una excepción importante: no todas las webs necesitan el mismo nivel de vigilancia.
No es prioritario montar una monitorización avanzada si tu web es estática, apenas cambia y ya tiene copias verificadas gestionadas por un proveedor fiable. Aun así, comprueba periódicamente que existe una copia restaurable, porque un proveedor no elimina tu responsabilidad sobre los datos y la recuperación.
Si vas a configurar hoy tu sistema, empieza con una lista de tres acciones: elige un destino externo, asigna dos destinatarios para alertas y agenda una restauración en staging antes de seis meses.
Preguntas y respuestas
¿Cómo sé si mi backup de WordPress está bien?
Un backup está bien si existe fuera del hosting, tiene fecha y tamaño coherentes y se restaura en staging. Comprueba esos tres puntos al menos cada 6 meses, y revisa semanalmente la fecha de la última copia correcta.
¿Cada cuánto debo revisar Google drive?
Revisa Google Drive cada semana durante los primeros 2 o 3 meses y después al menos una vez al mes. Comprueba fecha, peso y que la cuenta usada por el plugin conserva permisos.
¿UpdraftPlus gratis sirve para backups externos?
UpdraftPlus gratis puede servir para enviar copias a destinos compatibles, pero debes confirmar manualmente que llegan y se pueden restaurar. Para S3, Dropbox o funciones concretas, algunas conexiones pueden requerir extensiones o versión de pago.
¿Qué alerta debo configurar primero?
La primera alerta debe avisar si no hay una copia correcta dentro de tu RPO, por ejemplo tras 24 horas en una tienda diaria. Después añade alerta por tamaño anómalo y por archivo ausente en el destino remoto.
¿Puedo guardar el backup en el mismo hosting?
Puedes guardarlo como copia rápida, pero no debe ser tu única copia. Mantén al menos una versión en Google Drive, Dropbox, S3, Backblaze, NAS remoto o SFTP independiente.
¿Qué diferencia hay entre RPO y RTO?
El RPO indica cuántos datos puedes perder, mientras que el RTO indica cuánto tiempo puede tardar la recuperación. Una tienda puede exigir RPO de 24 horas y RTO de menos de 4 horas, según su actividad.
¿Es seguro guardar copias en la nube?
Es seguro si controlas acceso, cifrado, retención y ubicación del proveedor. Si hay datos personales, limita permisos y revisa las obligaciones del RGPD antes de compartir copias con terceros.
¿Necesito un panel si gestiono varias webs?
Un panel central es útil cuando administras más de 5 o 10 webs y no puedes revisar carpetas una a una. Aun con panel, prueba restauraciones de muestra y asigna responsables por cada cliente.
Lo esencial: Una copia solo protege si se crea, llega fuera del hosting y se restaura correctamente. Controla fecha, antigüedad, tamaño, tasa de éxito y retención según tu RPO. Configura alertas por fallo, retraso, tamaño anómalo y archivo desaparecido. Prueba la restauración en staging, no directamente sobre la web pública. Una alerta requiere responsable, sustituto y un plazo claro de respuesta.
Lecturas adicionales
Si quieres ampliar información sobre este tema, estas fuentes pueden interesarte:
