Optimizar el WP‑Cron y los backups consiste en desactivar WP‑Cron interno, programar tareas con el cron real del servidor y usar un plugin de backups automático (idealmente con copias incrementales y almacenamiento offsite). El objetivo es garantizar copias fiables sin ralentizar la web, con ventanas nocturnas y notificaciones de fallo.
Los factores clave para decidir Optimizar cron y backups
En este apartado el lector conocerá los elementos que influyen en la decisión.
En el contexto de gestión de tareas y copias, hay cuatro variables clave. Primero, la actividad del sitio. Segundo, el tipo de hosting. Tercero, la tolerancia a pérdida de datos. Cuarto, el presupuesto y la facilidad de uso.
La actividad del sitio determina la frecuencia. Un blog con pocas visitas puede ejecutar cron cada 30 minutos. Una tienda WooCommerce requiere cron cada 5-15 minutos y backups más frecuentes.
El tipo de hosting condiciona cambios en el sistema. En hostings gestionados muchas funciones ya vienen incluidas. En un VPS o servidor propio hay control total y también responsabilidad.
La tolerancia a pérdida de datos marca la retención y la granularidad. Para un ecommerce la recomendación es retención entre 30 y 90 días. Para un blog personal 7 a 30 días suele ser suficiente.
El presupuesto y la simplicidad afectan la elección de plugins y almacenamiento. El almacenamiento offsite reduce riesgos y suele costar entre 0,005 y 0,02 USD por GB al mes, según proveedores del mercado.
Resumen de decisiones clave:
Frecuencia de cron: según actividad, entre 5 y 60 minutos.
Tipo de backup: incremental si hay muchos cambios frecuentes.
Almacenamiento: offsite por seguridad y coste controlable.
En el sector, el rango habitual de retención es entre 7 y 90 días. Según W3Techs, WordPress alimenta el 43% de los sitios web. Según Backblaze B2, el precio por GB suele rondar 0.005 USD mensuales.
Una frase para pausar.
Escenario A Hosting gestionado Optimizar cron y backups
Aquí se explica qué hacer si el hosting ya gestiona crons y backups.
En el contexto de un hosting gestionado, el proveedor suele ofrecer cron fiables y backups con SLA. Antes de cambiar nada, confirme con soporte si ya hay cron del servidor y backups automáticos.
Si el hosting ya tiene backups diarios con SLA y restauraciones en 24 horas, no es necesario instalar un plugin pesado. En ese caso, use una solución ligera para exportar copias puntuales y comprobar restauraciones.
Si el hosting no da control sobre cron, hay alternativas. Usar servicios externos de programación como Healthchecks.io o cron-job.org permite disparar wp-cron sin tocar el servidor.
Recomendación experta: confiar en el backup del hosting solo si hay SLA y pruebas de restauración. Si no hay pruebas, añadir backups offsite con un plugin fiable.
Una frase para pausar.
No basta con que el cron lance tareas; hay que notificar éxito/fallo a sistemas de alerta. Ejemplo simple para Slack (Incoming Webhook): en el script de backup al final añadir: curl -X POST -H 'Content-type: application/json' --data '{"text":"Backup OK: example.com - db y uploads ($DATE)"}' https://hooks.slack.com/services/TOKEN; en fallo, enviar nivel de gravedad y salida de log. Para integración con Prometheus use Pushgateway desde el script: printf "wordpress_backup_success{site=/"example.com/"} 1
" | curl --data-binary @- http://pushgateway:9091/metrics/job/wordpress_backup; en fallo envíe valor 0. Configure Alertmanager para notificar a PagerDuty/email si la métrica está en 0 durante X minutos. Para PagerDuty Events API v2, enviar JSON con routing_key y payload desde el script cuando falle la verificación de integridad del backup. Estas integraciones permiten automatizar escalado y cumplir SLAs (p. Ej. Alerta crítica si no hay backup válido en 24 h).
Escenario B Hosting compartido o VPS Optimizar cron y backups
Aquí se describe la configuración si hay acceso al panel o SSH.
En el contexto de hosting compartido o VPS con acceso, se puede desactivar WP‑Cron y usar el cron real. Esto evita que WP‑Cron se dispare por visitas y genere picos de CPU.
Si hay cPanel, cree un cron cada 15 minutos que llame a wp-cron.php. Si hay Plesk, use la sección Tareas programadas. Si hay SSH, edite crontab con crontab -e.
Ejemplo simple para cPanel o crontab:
*/15 * * * * curl -s "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2 >& 1
Para desactivar WP‑Cron añadir en wp-config.php:
define('DISABLE_WP_CRON', true);
Para evitar solapamientos use flock. Ejemplo de crontab con flock:
*/30 * * * * /usr/bin/flock -n /tmp/wp_backup.lock /usr/local/bin/backup.sh
El script backup.sh puede exportar la base de datos y empaquetar uploads. Luego subir a S3 o B2 con aws cli.
Una frase para pausar.
Mejores plugins cron y backups para principiantes
Esta sección lista plugins fáciles, fiables y probados desde el primer minuto.
En el contexto de elegir plugins, la prioridad es seguridad, bajo impacto y facilidad. Para principiantes la recomendación es elegir soluciones con interfaz clara y almacenamiento remoto.
Plugins recomendados:
UpdraftPlus : opción freemium. Copias incrementales con add-on. Compatible con S3, Google Drive y Dropbox.BlogVault : servicio pago con backups incrementales, staging y restauración en 1 clic.Jetpack Backup : copia gestionada por Automattic, integrada y con restauraciones simples.
¿Por qué elegir UpdraftPlus para empezar? Porque ofrece una configuración rápida sin tocar servidor. Permite programar copias, elegir almacenamiento remoto y restaurar partes como uploads o base de datos.
Una frase para pausar.
Criterio
UpdraftPlus
BlogVault
Cuándo elegirlo
Tipo
Plugin freemium
Servicio pago gestionado
Elige UpdraftPlus para empezar barato. Elige BlogVault para soporte y staging.
Backups incrementales
Con add-on pago
Incluido
Elige BlogVault si hay muchos cambios diarios.
Restauración
Restauración por componentes
Restauración en 1 clic
Elige BlogVault para recuperar rápido tiendas grandes.
Impacto en CPU/IO
Moderado si se programa fuera de horas
Bajo, procesado fuera del servidor
Elige servicio gestionado para menor impacto.
Recomendación clara: para principiantes empezar con UpdraftPlus y almacenamiento offsite. Cambiar a BlogVault si el sitio crece y requiere staging y restauración rápida.
Una frase para pausar.
Restauración parcial: pasos y ejemplos reales
Las restauraciones parciales requieren comandos precisos y medidas para no corromper datos. Para restaurar una sola tabla (ej. Wp_posts) desde un backup SQL comprimido: 1) extraer el SQL del backup (tar -xzf db-2026-03-01.sql.gz) 2) extraer solo la tabla usando mysqldump/grep o, más seguro, exportar la tabla desde el servidor que guarda el backup: mysqldump -u DBUSER -pDBPASS DBNAME wp_posts > wp_posts.sql 3) en el servidor de destino haga copia de seguridad previa: mysqldump -u DBUSER -pDBPASS DBNAME > pre-restore.sql 4) importar la tabla: mysql -u DBUSER -pDBPASS DBNAME < wp_posts.sql. Para restaurar sólo un subdirectorio de uploads desde un tar.gz: tar -xzf uploads-2026-03-01.tar.gz -C /var/www/html/wp-content/uploads ruta/a/restaurar --strip-components=2 (ajuste --strip-components según el paquete); luego arregle permisos: chown -R www-data:www-data /var/www/html/wp-content/uploads/ruta/a/restaurar && find ... -type d -exec chmod 755 {} /; -type f -exec chmod 644 {} /;. Antes de restaurar, ponga el sitio en modo mantenimiento y desactive plugins de cache o sincronización para evitar conflictos; después valide URLs afectadas, ejecute wp cache flush y compruebe tablas relacionadas (meta, postmeta) para coherencia. Incluir estos comandos en la documentación de operaciones y probar en staging evita sorpresas en producción.
✉
¿Quieres más información? Escríbenos y te orientamos
Cómo reducir carga por backups guía simple
Aquí está la guía paso a paso para minimizar CPU e IO durante backups.
En el contexto de reducir impacto, hay tres acciones efectivas. Programar en ventanas nocturnas. Usar backups incrementales. Mover trabajo fuera del servidor cuando sea posible.
Pasos prácticos:
Programar backups en horas de baja actividad. Normalmente entre 01:00 y 05:00 locales. Evitar horas pico y campañas de marketing.
Activar backups incrementales. Solo se copian cambios, no todo el sitio. Esto reduce IO y tiempo.
Excluir carpetas grandes y cache. Por ejemplo, node_modules o backups locales incrustados.
Comprimir y subir a offsite en paralelo. Usar rsync o herramientas con multipart upload.
Ejemplo de exclusiones típicas en UpdraftPlus:
Carpeta /wp-content/cache
Carpeta /wp-content/uploads/cache
Carpetas de plugins voluminosos
Si el hosting permite, delegar el trabajo a servidores externos. Servicios como BlogVault procesan el backup fuera del servidor y causan menos carga.
💡 Consejo
Una frase para pausar.
Guía simple para elegir plugin backups WordPress
Aquí se enumeran criterios y una plantilla práctica de decisión.
En el contexto de elegir un plugin, priorizar facilidad, almacenamiento remoto y capacidad de restauración parcial. Los criterios clave son compatibilidad, velocidad de restauración y soporte.
Plantilla de selección rápida:
¿Necesita backups incrementales? Si el sitio cambia mucho elija plugin con incrementales.
¿Quiere almacenamiento offsite? Elija integraciones con S3, Google Drive o Dropbox.
¿Desea restauraciones parciales? Confirme que puede restaurar solo base de datos o uploads.
Recomendación experta: elegir UpdraftPlus para familiarizarse y escalar a BlogVault o Jetpack Backup cuando la tienda crezca. Esta es una elección práctica y de bajo riesgo.
Una frase para pausar.
Paso a paso evitar solapar tareas programadas
Cada paso aquí evita que dos procesos compitan por recursos.
En el contexto operativo, las solapaciones ocurren cuando una tarea larga comienza antes de terminar la anterior. El resultado suele ser sobrecarga de CPU y bloqueo de disco.
Pasos concretos:
Use lock files con flock en crontab.
Configure tiempos de espera razonables entre tareas. Por ejemplo, backups incrementales cada 4 horas y copias completas una vez al día.
Revise logs y tiempos promedio de ejecución. Ajuste horarios según datos reales.
Si usa plugins, active registros y compruebe si el plugin ya maneja locks internamente.
Ejemplo de script con lock y tiempo límite:
LOCKFILE = /tmp/wp_backup.lock
if /usr/bin/flock -n $LOCKFILE -c "/usr/bin/timeout 2700 /usr/local/bin/backup.sh" ; then
echo "Backup iniciado"
else
echo "Otro proceso en curso. Se cancela el backup."
fi
Una frase para pausar.
Qué plugins evitar en backups para principiantes
Lista de plugins que suelen causar problemas a principiantes.
En el contexto de elección prudente, evitar plugins antiguos sin actualizaciones o aquellos que realizan backups completos por defecto sin incrementales. Estos generan picos y pueden dejar el sitio lento.
Plugins a evitar o evaluar con precaución:
Plugins inactivos sin soporte desde hace años.
Plugins que almacenan backups localmente sin opción offsite.
Soluciones que requieren configuración compleja de servidor para funcionar correctamente.
⚠️ Atención
⚠️ Atención
Una frase para pausar.
Procedimientos técnicos para desactivar WP Cron y usar cron real
Instrucciones paso a paso para cPanel Plesk y SSH.
En el contexto de implementación, seguir pasos reproducibles reduce errores. A continuación están los comandos y cambios seguros para cada panel.
CPanel pasos:
Acceder a cPanel y abrir Tareas programadas.
Seleccionar frecuencia cada 15 minutos.
Comando recomendado:
curl -s "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2 >& 1
Editar wp-config.php y añadir:
define('DISABLE_WP_CRON', true);
Plesk pasos:
Abrir Plesk y acceder a Tareas programadas.
Crear tarea cron con URL o comando curl.
Programar cada 15 minutos o según necesidades.
SSH pasos (VPS o servidor dedicado):
Abrir terminal y ejecutar crontab -e.
Añadir la línea con curl o wget según ejemplo de cPanel.
Guardar y comprobar con crontab -l.
Comprobación:
Revisar registros en wp-content/debug.log si está activo.
Usar WP Crontrol para ver eventos programados.
Una frase para pausar.
Ejemplo práctico y comprobable: desactivar WP‑Cron y usar cron real
Para entornos distintos conviene seguir pasos reproducibles y comprobar el resultado. En cPanel: 1) en wp-config.php añadir define('DISABLE_WP_CRON', true); 2) en cPanel → Tareas programadas crear una tarea que ejecute cada 15 minutos: curl -s "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1; 3) comprobar ejecución viendo las entradas de wp‑cron con WP‑CLI: wp cron event list --path=/home/usuario/public_html. En Plesk el flujo es equivalente: desactivar en wp-config.php y crear una Tarea programada (Command) con el mismo curl. En servidores con SSH y systemd es más robusto usar un systemd timer: crear /etc/systemd/system/wp-cron.service con el comando ExecStart=/usr/bin/curl -fsS "https://example.com/wp-cron.php?doing_wp_cron" y /etc/systemd/system/wp-cron.timer con OnCalendar=- - :0/15:00 para cada 15 minutos; ejecutar systemctl daemon-reload && systemctl enable --now wp-cron.timer y comprobar con systemctl list-timers --all. Verifique además en WordPress con wp cron event list y en el servidor con journalctl -u wp-cron.service para errores. Estas comprobaciones reproducibles evitan que se corte la ejecución de hooks programados al migrar entorno.
✉
¿Quieres más información? Escríbenos y te orientamos
Scriptss para backups y rotación
Ejemplos sencillos listos para adaptar.
En el contexto de automatización, usar scripts pequeños reduce errores manuales. Los ejemplos incluyen export de base de datos y subida a S3 con rotación simple.
Script básico para DB y uploads con aws cli:
> variables
SITE_PATH = /var/www/html
BACKUP_PATH = /var/backups/wp
DATE = $( date +"%F-%H%M" )
mkdir -p $BACKUP_PATH
> Export DB
wp db export $BACKUP_PATH /db-$DATE .sql --path= $SITE_PATH
> Tar uploads
tar -czf $BACKUP_PATH /uploads-$DATE .tar.gz -C $SITE_PATH wp-content/uploads
> Upload to S3
aws s3 cp $BACKUP_PATH s3://mi-bucket-wordpress/ --recursive --exclude "*" --include "* $DATE *"
> Rotate local backups older than 14 days
find $BACKUP_PATH -type f -mtime +14 -delete
Este script requiere wp-cli y aws cli instalados. Ajustar permisos y probar en entorno de staging primero.
Una frase para pausar.
Análisis del impacto en CPU IO y cómo programar ventanas seguras
Datos y recomendaciones numéricas para minimizar efecto en rendimiento.
En el contexto de impacto, los backups completos generan picos de IO y pueden duplicar latencia. Corrección: "Los backups incrementales reducen el volumen de datos transferidos y el tiempo de ejecución respecto a un backup completo, pero el porcentaje varía mucho según cuántos y qué tamaño tengan los ficheros modificados. En la práctica la reducción puede oscilar entre ~20% y ~80% dependiendo del sitio; por eso es recomendable medir IO y tiempo en su entorno con pruebas controladas antes de fijar la política de backups."
Reglas prácticas y números:
Backups completos: 1 vez por semana en sitios con pocas actualizaciones.
Backups incrementales: diarios o cada 4-6 horas para sitios activos.
Cron del servidor: cada 5-15 minutos en ecommerce, cada 15-60 minutos en sitios estáticos.
Ejemplo de plantillas horarias:
Blog pequeño: cron 30 minutos. Backup incremental diario. Completo semanal.
Sitio corporativo: cron 15 minutos. Incremental diario. Completo semanal.
Tienda WooCommerce: cron 5-15 minutos. Incremental cada 4 horas. Completo diario.
Una frase para pausar.
Procedimiento de restauración parcial con ejemplos reales
Cómo restaurar solo la tabla de pedidos de WooCommerce o la carpeta uploads.
En el contexto de restauraciones, muchas ocasiones requieren solo una parte. Esto reduce riesgos y tiempo de inactividad.
Restaurar tabla de la base de datos (ejemplo tabla wp_posts):
Exportar la tabla del backup SQL:
wp db query "CREATE TABLE tmp_wp_posts AS SELECT * FROM wp_posts WHERE 1=0;"
mysql -u user -p dbname < backup.sql
O usar phpMyAdmin para importar solo la tabla deseada.
Restaurar carpeta uploads:
Descargar el archivo uploads-YYYY-MM-DD.tar.gz.
Extraer solo la carpeta wp-content/uploads en modo seguro.
tar -xzf uploads-2026-03-01.tar.gz -C /var/www/html/wp-content --strip-components= 2
Precaución: siempre hacer backup del estado actual antes de restaurar partes.
Una frase para pausar.
Coste y retención optimizada por tipo de proyecto
Plantillas para calcular costes de almacenamiento offsite.
En el contexto económico, la retención debe equilibrar riesgo y coste. Aquí hay plantillas rápidas con rangos.
Blog personal:
Retención: 7-30 días.
Almacenamiento estimado: 1-5 GB.
Solución recomendada: Google Drive o Dropbox.
Web corporativa o blog con medios:
Retención: 30-60 días.
Almacenamiento estimado: 10-100 GB.
Solución recomendada: S3 o Backblaze B2.
Ecommerce:
Retención: 30-90 días.
Almacenamiento estimado: 50-500+ GB según fotos y productos.
Solución recomendada: S3 con lifecycle rules o BlogVault.
Cálculo de 200 GB en Backblaze B2 = 200 * 0.005 = 1 USD/mes según Backblaze 2024.
Una frase para pausar.
Monitorización y alertas para crons y jobs de backup
Opciones sencillas para recibir avisos cuando algo falla.
En el contexto de detectar fallos, la monitorización evita sorpresas. Configure notificaciones por email o Slack y alertas externas.
Herramientas prácticas:
Healthchecks.io para comprobar que cron se ejecuta.
Monitorización por correo con plugins y servicios de hosting.
Integraciones con Slack o Teams para alertas inmediatas.
Ejemplo Healthchecks uso rápido:
Cree un check en Healthchecks.io.
Añada la URL provista en la crontab: curl -fsS "https://hc-ping.com/uuid" >/dev/null
Configure tiempo de espera y alertas por email o Slack.
Una frase para pausar.
Checklist de pruebas de restauración y proceso DR con SLA recomendados
Checklist accionable para verificar la validez de backups.
En el contexto de preparación ante desastre, practicar restauraciones reduce el tiempo de recuperación. Hacer pruebas trimestrales al menos.
Checklist mínima:
Probar restauración completa en staging cada 30-90 días.
Probar restauración parcial (BD o uploads) cada 30 días.
Verificar archivos comprimidos y checksum.
Comprobar integridad de la base de datos y permisos.
SLA recomendados según criticidad:
Sitios no críticos: RTO 24 horas, retención 7-30 días.
Sitios corporativos: RTO 12 horas, retención 30-60 días.
Ecommerce crítico: RTO 1-4 horas, retención 30-90 días.
Una frase para pausar.
✉
¿Quieres más información? Escríbenos y te orientamos
Integraciones de monitorización avanzadas
Opciones para equipos con necesidades serias de alertas.
En el contexto de equipos, integrar Prometheus o PagerDuty ofrece escalado de alertas. Para la mayoría de principiantes esto es excesivo. Para tiendas grandes es justificable.
Opciones escaladas:
Exportar métricas a Prometheus y crear reglas de alerta.
Usar PagerDuty para escalado y on-call.
Conectar webhooks desde Healthchecks a Slack y PagerDuty.
Una frase para pausar.
Errores al tomar esta decisión
Advertencias directas basadas en casos reales.
En el contexto de la experiencia real, estos errores aparecen frecuentemente. Evitarlos reduce riesgo y pérdida de datos.
Errores frecuentes:
Desactivar WP‑Cron sin cron real, lo que deja tareas sin ejecutar.
Confiar solo en un backup local y no probar restauraciones.
Instalar plugins de backup pesados que generan picos de CPU en horas punta.
Caso típico: un blog que desactiva WP‑Cron para mejorar velocidad y olvida configurar cron. Meses después las estadísticas y pedidos dejan de procesarse.
Advertencia experta: siempre probar la ejecución de cron y la restauración tras cualquier cambio.
Una frase para pausar.
Preguntas frecuentes
A continuación preguntas reales que la gente busca en Google.
¿Qué es WP Cron y cómo funciona?
WP‑Cron se refiere al sistema interno de WordPress para tareas programadas. Se dispara cuando alguien visita la web y ejecuta eventos pendientes. Sirve para tareas como publicación programada, limpieza de caché y programar backups.
¿Cómo desactivo WP Cron y uso un cron real en mi servidor?
Primera línea: añade define('DISABLE_WP_CRON', true) en wp-config.php. Luego crea un cron del servidor que llame a wp-cron.php cada 5-30 minutos. Use curl o wget y pruebe ejecución.
¿Cuál es el mejor plugin para hacer copias de seguridad en WordPress?
para principiantes, UpdraftPlus es el mejor punto de partida. Es sencillo, tiene almacenamiento remoto y restauración por componentes. Si se necesita procesamiento fuera del servidor, elegir BlogVault.
¿Cómo hacer una restauración parcial de la base de datos en WordPress?
exporte la tabla desde el backup y use phpMyAdmin o wp-cli para importarla. Siempre hacer una copia del estado actual antes de importar.
¿Con qué frecuencia debo programar backups para una tienda WooCommerce?
copias incrementales cada 4 horas y copias completas una vez al día. Retención recomendada 30-90 días según volumen de ventas.
¿Cómo comprobar que mis backups son válidos y restaurables?
realizar pruebas de restauración en staging trimestralmente. Comprobar checksums y que la base de datos se importa sin errores.
¿Los backups incrementales reducen el espacio de almacenamiento?
sí, reducen significativamente el espacio. En sitios con pocos cambios el ahorro puede ser del 60 al 90% respecto a backups completos.
¿Cómo monitorizar y recibir alertas cuando falla un cron o un backup?
use Healthchecks.io o cron-job.org y configure alertas por email o Slack. Para empresas, integre PagerDuty o Prometheus.
¿Cómo Optimizar cron y backups para mi WordPress?
desactive WP‑Cron, configure cron real y use un plugin con almacenamiento offsite. Ajuste frecuencia según actividad y pruebe restauraciones.
Una frase para pausar.
Conclusión
Optimizar cron y backups reduce fallos y mejora rendimiento sin complicaciones.
En el contexto final, la mejor decisión equilibra seguridad y simplicidad. Desactivar WP‑Cron y usar cron del servidor junto a backups incrementales offsite es la opción más segura para la mayoría de proyectos.
Opinión experta: para la mayoría de principiantes la combinación UpdraftPlus + cron servidor ofrece la mejor relación entre coste, seguridad y facilidad de uso. Para tiendas grandes, migrar a BlogVault o Jetpack Backup añade fiabilidad y menor impacto en recursos.
💡 Consejo
Una frase para pausar.
Recursos y enlaces útiles
Una frase para pausar.
Proceso recomendado
Desactivar WP‑Cron
Configurar cron del servidor
Plugin backups a offsite
Ventanas y frecuencia sugerida
Blog: Cron 30m, Backup diario
Corp: Cron 15m, Incremental diario
Ecommerce: Cron 5-15m, Incremental 4h
Una frase para pausar.
Fuentes y lecturas recomendadas
W3Techs estadisticas sobre uso de CMS 2024. W3Techs
Precios y opciones de almacenamiento en Backblaze 2024. Backblaze
Una frase para pausar.
