Cómo las copias de seguridad de WordPress afectan el rendimiento del sitio (y cómo solucionarlo)

El año pasado estuve solucionando un sitio lento y no pude encontrar nada obvio. Ni plugins nuevos, ni picos de tráfico, nada en los registros de errores que destacara.

Entonces revisé la programación de copias de seguridad. Estaba configurada para ejecutarse al mediodía, todos los días, en una cuenta de hosting compartido. Eso era todo.

La mayoría de los usuarios de WordPress instalan un plugin de copias de seguridad, eligen una programación y nunca vuelven a tocarlo. Es una de esas tareas que se sienten hechas una vez que el plugin está activo.

Pero la configuración predeterminada de la mayoría de los plugins de copias de seguridad no está optimizada para el rendimiento. Están optimizados para la simplicidad.

Una copia de seguridad completa diaria almacenada en Dropbox suena responsable. En un sitio pequeño con hosting generoso, lo es. En un sitio más grande o en un host compartido económico, es un golpe de rendimiento recurrente que quizás ni siquiera estés relacionando con las copias de seguridad.

En esta publicación, te mostraré qué sucede cuando se ejecuta una copia de seguridad, por qué algunas configuraciones afectan más al servidor que otras y los cambios específicos que reducen el impacto a casi cero.

Aquí están los puntos clave:

• Las copias de seguridad consumen muchos recursos: Comprimir archivos, exportar bases de datos y subir a la nube consumen una cantidad significativa de CPU, E/S de disco y ancho de banda simultáneamente.
• Los límites del hosting compartido pueden causar fallos silenciosos: Los tiempos de espera de PHP ocultos y las cuotas de CPU/E/S en hosts económicos a menudo matan las copias de seguridad de larga duración a mitad del proceso, dejándote con archivos corruptos o incompletos.
• El formato de la copia de seguridad importa: Los archivos ZIP estándar se ejecutan en un solo pase continuo, lo que los hace muy vulnerables a los tiempos de espera del servidor. Los formatos fragmentados como el DupArchive personalizado de Duplicator evitan estas restricciones por completo.
• La optimización es fácil: Puedes eliminar casi por completo el impacto en el rendimiento ejecutando copias de seguridad durante las horas de menor actividad, excluyendo archivos de caché, confiando en el cron del servidor y programando copias de seguridad solo de la base de datos con más frecuencia que las copias de seguridad completas del sitio.

Tabla de Contenidos

¿Qué sucede en tu servidor cuando se ejecuta una copia de seguridad?

Una copia de seguridad no es solo copiar tus archivos a otra ubicación. Es un proceso de varios pasos que se ejecuta completamente en tu servidor, compitiendo por los mismos recursos que sirven tu sitio a los visitantes.

Mientras se ejecuta la copia de seguridad, tu servidor está haciendo dos trabajos a la vez. En el hosting compartido, donde esos recursos ya se dividen entre docenas de otros sitios, eso importa.

Compresión de archivos y carga de CPU

Cada archivo en tu instalación de WordPress se lee y se comprime en un archivo durante una copia de seguridad. Ese proceso consume mucha CPU.

En el hosting compartido, tu cuenta recibe una porción limitada del poder de procesamiento del servidor, y una copia de seguridad que comprime cientos de megabytes de archivos consumirá parte de ella.

Los sitios más grandes empeoran esto. Más archivos significan una ventana de compresión más larga, lo que significa más tiempo que tu CPU está bajo presión.

Un blog pequeño con medios mínimos podría comprimirse en menos de un minuto. Un sitio con años de imágenes subidas puede tardar significativamente más.

¿Quieres reducir al instante el tamaño de tu biblioteca de medios a la mitad? ¡Elimina las variaciones de imágenes no utilizadas con WP Media Cleanup!

Exportación de base de datos y bloqueo de tablas

La exportación de la base de datos es a menudo el culpable oculto. La mayoría de los usuarios piensan en sus archivos cuando imaginan una copia de seguridad, pero WordPress almacena tus publicaciones, configuraciones, usuarios y todo lo demás en una base de datos MySQL, y eso requiere un proceso de exportación separado.

La mayoría de los plugins de copia de seguridad exportan la base de datos utilizando un método que bloquea temporalmente las tablas que está leyendo. Mientras esas tablas están bloqueadas, las consultas entrantes de WordPress tienen que esperar.

Incluso unos pocos segundos de bloqueo de tablas pueden causar tiempos de espera en un servidor lento o muy ocupado.

E/S de disco: El cuello de botella que la mayoría ignora

Leer miles de archivos para una copia de seguridad crea una actividad de disco sustancial. El almacenamiento de tu servidor tiene un límite en cuanto a cuántas operaciones de lectura y escritura puede manejar por segundo, y una copia de seguridad que se ejecuta en toda tu instalación de WordPress empuja ese límite.

Los hosts económicos y compartidos con frecuencia todavía usan discos duros tradicionales en lugar de SSD. En esos servidores, la alta actividad de disco durante una copia de seguridad ralentiza todo lo que toca el almacenamiento, incluidas las consultas a la base de datos y las lecturas de archivos que generan tus páginas.

Carga a la nube y ancho de banda

El impacto en el rendimiento no termina cuando el archivo comprimido termina de crearse. La mayoría de las configuraciones de copia de seguridad luego suben ese archivo a almacenamiento en la nube: Dropbox, Google Drive o S3. Esa carga se ejecuta en la misma conexión del servidor que atiende a tus visitantes.

Una copia de seguridad de 2 GB que se sube a Dropbox a una velocidad de carga típica de alojamiento compartido tarda varios minutos. Durante esa ventana, tu ancho de banda disponible puede verse disputado.

¿Por qué el rendimiento de las copias de seguridad en alojamiento económico es peor?

Los hosts económicos y compartidos imponen límites a nivel de servidor que la mayoría de los usuarios nunca ven documentados en ningún sitio.

Estos no son errores o configuraciones incorrectas. Son límites intencionados que evitan que una cuenta consuma recursos que afecten a cualquier otro sitio en el mismo servidor.

El problema es que esos mismos límites interfieren con los procesos de copia de seguridad, y los fallos que causan no siempre son obvios.

Tiempos de espera de PHP

PHP tiene una configuración de tiempo máximo de ejecución. En hosts compartidos económicos, a menudo se establece en 30 a 60 segundos. Un proceso de copia de seguridad en un sitio más grande puede tardar mucho más que eso, y cuando alcanza el límite, el host mata el proceso a mitad de ejecución.

El resultado es un archivo comprimido incompleto. Parece que existe una copia de seguridad. El archivo está ahí, pero se cortó antes de terminar, lo que significa que no se puede restaurar.

El sitio sufrió todo el impacto de rendimiento de una copia de seguridad en ejecución y no obtuvo nada fiable de ella. Un archivo de copia de seguridad corrupto es peor que ninguna copia de seguridad porque crea una falsa confianza de que estás protegido cuando no lo estás.

Cuotas de CPU y E/S

La mayoría de los hosts compartidos limitan el uso de CPU por cuenta. Una vez que alcanzas el límite, el host no detiene tus procesos de inmediato. Los ralentiza. Todo lo que se ejecuta bajo tu cuenta se ralentiza, incluidas las solicitudes de página entrantes de los visitantes.

Los lmites de E/S funcionan de la misma manera. Tu cuenta tiene un lmite mximo de operaciones de lectura y escritura por segundo. Una copia de seguridad que comprime una biblioteca multimedia grande alcanzar frecuentemente ese lmite.

Por eso algunas copias de seguridad se completan a las 3 AM pero fallan al medioda con ajustes idnticos. Las horas valle significan una carga de servidor base menor, lo que se traduce en ms margen antes de que se active la cuota.

Importa el formato del archivo de copia de seguridad?

La mayora de los plugins de copia de seguridad utilizan de forma predeterminada los archivos ZIP. No es una mala eleccin para un sitio pequeo en un servidor con buenos recursos. Pero ZIP procesa los archivos secuencialmente, uno a la vez, en una nica pasada ininterrumpida.

En un entorno de alojamiento compartido y limitado, esa nica pasada ininterrumpida es exactamente lo que los tiempos de espera de PHP estn diseados para interrumpir.

El formato de archivo que utiliza tu plugin de copia de seguridad determina cunto presiona el servidor y si puede sobrevivir a las limitaciones del alojamiento econmico. Esto casi nunca surge en las conversaciones sobre el rendimiento de las copias de seguridad, y a menudo es la diferencia entre una copia de seguridad que se completa de forma fiable y otra que falla silenciosamente.

Cmo maneja DupArchive las limitaciones del servidor

Duplicator es un plugin de copia de seguridad de WordPress con su propio formato de copia de seguridad llamado DupArchive. Fue construido especficamente para copias de seguridad y migraciones de WordPress, con las limitaciones del alojamiento econmico como consideracin principal de diseo.

Donde un proceso ZIP estndar se ejecuta como una operacin continua, DupArchive funciona en fragmentos ms pequeos. Cada fragmento se completa dentro de los lmites de tiempo de ejecucin del servidor, y luego el proceso contina desde donde lo dej.

Los tiempos de espera de PHP que interrumpiran una copia de seguridad basada en ZIP a mitad de la ejecucin no tienen el mismo efecto, porque cada fragmento es lo suficientemente corto como para completarse antes de que se active el lmite.

Tambin maneja sitios ms grandes sin el lmite de tamao de archivo que causa fallos en ZIP. Las migraciones del mundo real utilizando DupArchive se han completado con ms de 400 GB!

Para la mayora de los usuarios de alojamiento compartido, ese margen significa que el formato simplemente funciona donde un enfoque basado en ZIP se agota o se corrompe.

Obtn la lista completa de ajustes que aceleran una copia de seguridad lenta aqu.

Shell Zip vs. ZipArchive

Duplicator te permite elegir tu motor de archivo de copia de seguridad.

Shell Zip delega la compresin al sistema operativo en lugar de ejecutarla a travs de PHP. Es significativamente ms rpido cuando est disponible porque el SO maneja la compresin de forma ms directa que un proceso de PHP.

Los hosts econmicos a veces deshabilitan Shell Zip. Si el tuyo lo hace, puedes pedirles que lo habiliten o considerarlo una seal de que el procesamiento por fragmentos de DupArchive de Duplicator es la solucin alternativa adecuada.

Estas dos opciones cubren la mayora de los entornos de alojamiento entre ellas: Shell Zip para la velocidad cuando el host lo permite y DupArchive para la fiabilidad cuando no lo hace.

Cmo ejecutar copias de seguridad sin ralentizar tu sitio

El objetivo es hacer que las copias de seguridad sean invisibles para tus visitantes. Se ejecutan, se completan y se suben sin que nadie note una diferencia en la velocidad del sitio.

Eso es factible en la mayora de las configuraciones con unos pocos cambios de ajustes. Ninguno de ellos requiere cambiar de host o contratar a un desarrollador.

Las formas más efectivas de ejecutar copias de seguridad sin ralentizar tu sitio:

• Programa las copias de seguridad en momentos de poco tráfico: El momento oportuno lo es todo. Identificar las horas de menor actividad de tu sitio garantiza que las copias de seguridad no compitan con los visitantes reales por los recursos del servidor.
• Excluye archivos que no necesitan copia de seguridad: Eliminar directorios de caché, registros y archivos temporales reduce drásticamente el tamaño de la copia de seguridad, ahorrando potencia de CPU y E/S de disco.
• Ejecuta copias de seguridad de la base de datos con más frecuencia que las copias completas: Dado que tu base de datos cambia constantemente pero tus archivos no, ejecutar copias de seguridad rápidas diarias de la base de datos te permite reducir las copias de seguridad completas del sitio a solo una vez por semana.
• Utiliza el cron del servidor en lugar de WP-Cron: Cambiar de la programación dependiente del tráfico de WordPress a un trabajo cron dedicado del servidor garantiza que las copias de seguridad se ejecuten exactamente cuando deben.

Programar copias de seguridad en horas de poco tráfico

El momento oportuno es la solución de mayor apalancamiento disponible independientemente de tu nivel de alojamiento. Una copia de seguridad que se ejecuta a las 3 AM en un servidor tranquilo tiene mucho más margen que la misma copia de seguridad que se ejecuta al mediodía compitiendo con el tráfico real de visitantes.

La recomendación estándar es de 2 a 5 AM hora local. Esto se aplica a la mayoría de los sitios, pero vale la pena comprobar tus análisis reales.

Abre MonsterInsights, mira el tráfico por hora y encuentra tu valle real. Algunos sitios que atienden a audiencias internacionales no tienen una ventana clara de poco tráfico. Otros ven su punto más bajo a primera hora de la tarde en lugar de durante la noche. Programa en función de tus datos, no de una regla genérica.

No programes copias de seguridad durante momentos de mucho tráfico. Si envías un boletín a las 9 AM los martes, no ejecutes una copia de seguridad a las 9 AM los martes. Los picos de tráfico de las campañas son precisamente cuando no quieres una carga adicional en el servidor.

Excluye archivos que no necesitan copia de seguridad

La forma más rápida de reducir la carga de la copia de seguridad es reducir lo que se está respaldando. Los archivos más pequeños se comprimen más rápido, se suben más rápido y ejercen menos presión sobre la E/S del disco durante todo el proceso.

Los directorios de caché son la mayor ganancia. Tu plugin de caché los regenera automáticamente cuando el sitio se carga, por lo que no hay valor de recuperación en hacerles una copia de seguridad.

También vale la pena excluir:

• Archivos de registro
• Carpetas temporales de carga
• Cualquier archivo de archivo dejado en el servidor por otros plugins de copia de seguridad

En Duplicator, utiliza filtros de archivos y bases de datos para excluir datos innecesarios. Recomendaría el filtro Cache incorporado.

El informe de escaneo previo a la copia de seguridad muestra los archivos grandes antes de que se ejecute la compilación. Vale la pena revisarlo antes de establecer un horario recurrente. Unos minutos con ese informe pueden reducir significativamente el tamaño de tu copia de seguridad.

Ejecutar copias de seguridad de la base de datos con más frecuencia que las copias de seguridad completas

Tu biblioteca de medios apenas cambia. Tu base de datos cambia constantemente.

Cada nueva publicación, comentario, pedido y envío de formulario va a la base de datos. Eso es lo que realmente necesitas respaldar con frecuencia.

Las copias de seguridad diarias solo de la base de datos son rápidas, a menudo se completan en menos de 30 segundos y ejercen una carga mínima en el servidor. Reserva las copias de seguridad completas del sitio (archivos más base de datos) para ejecuciones semanales en horas de menor actividad.

Este enfoque le proporciona puntos de recuperación frecuentes para los datos que más importan, manteniendo al mismo tiempo el proceso intensivo de sitio completo infrecuente.

Usar el cron del servidor en lugar de WP-Cron

WordPress tiene un sistema de programación integrado llamado WP-Cron. El truco es que solo se activa cuando alguien visita el sitio.

Si nadie visita a las 3 AM, la copia de seguridad no se ejecuta. Peor aún, un visitante al mediodía podría activar inadvertidamente una copia de seguridad retrasada que debía ejecutarse durante la noche.

Un trabajo cron de servidor real se ejecuta en un horario fijo independientemente del tráfico. La mayoría de los paneles de control de alojamiento proporcionan acceso a la configuración de cron.

Configurar uno para su plugin de copia de seguridad lleva unos minutos y elimina por completo la imprevisibilidad de WP-Cron. La documentación de Duplicator cubre el proceso de configuración de cron del lado del servidor si no lo ha hecho antes.

Señales de que tus copias de seguridad están afectando el rendimiento del sitio

Es posible que no conecte la lentitud del sitio con las copias de seguridad porque el momento no es obvio. Una copia de seguridad que se ejecuta a una hora extraña no se anuncia. Pero hay patrones que vale la pena buscar si su sitio se ha sentido lento y no ha podido determinar la causa.

Estas son las señales que indican que las copias de seguridad están ralentizando su sitio:

• La lentitud del sitio aumenta a la misma hora cada día o semana, coincidiendo con su horario de copias de seguridad
• Los registros de copias de seguridad muestran ejecuciones fallidas, incompletas o faltantes
• Su panel de control de alojamiento muestra picos de CPU o E/S en un horario predecible
• Los visitantes informan de lentitud que no se alinea con sus horas pico de tráfico normales

Si dos o más de esas coinciden con lo que está viendo, revise primero su horario de copias de seguridad antes de investigar cualquier otra cosa.

Protege tu sitio antes de cambiar nada

Antes de ajustar los horarios de copia de seguridad, cambiar los formatos de archivo o modificar cualquier configuración del servidor: realice primero una copia de seguridad completa.

Eso suena obvio, pero es fácil de omitir cuando estás en medio de la resolución de problemas y con impaciencia por arreglar algo. He hecho exactamente eso y he creado una brecha en mi historial de copias de seguridad justo antes de hacer cambios que no salieron como esperaba.

Los errores de configuración durante la configuración de la copia de seguridad pueden dejarle sin una copia de seguridad funcional. La ironía de romper su red de seguridad de copias de seguridad mientras intenta mejorar su configuración de copias de seguridad es real.

Si desea probar nuevas configuraciones de programación o de archivos de copia de seguridad antes de aplicarlas a su sitio en producción, el staging le proporciona un entorno aislado para confirmar que todo funciona primero.

Duplicator Pro le permite crear un sitio de staging a partir de cualquier copia de seguridad existente en unos pocos clics. No se requiere una cuenta de alojamiento separada.

Una vez que construya el área de staging, puede solucionar problemas sin riesgo.

Preguntas Frecuentes (FAQs)

Tu sitio merece una copia de seguridad que funcione con él

Las copias de seguridad se supone que deben proteger tu sitio, no gravarlo. El impacto en el rendimiento de una copia de seguridad mal configurada es real, pero casi siempre se puede solucionar sin cambiar de host ni reconstruir nada.

Las tres palancas que más importan son cuándo se ejecutan las copias de seguridad, qué incluyen y qué formato utilizan. La mayoría de los sitios pueden lograr un impacto de rendimiento cercano a cero abordando esas tres cosas.

Tu plugin de copia de seguridad debe proteger tu sitio sin competir con él por los recursos del servidor. Ese es un equilibrio más difícil de lograr de lo que parece, especialmente en hosting compartido y económico, donde las limitaciones son reales y no siempre están documentadas.

Más de 1.5 millones de profesionales de WordPress utilizan Duplicator Pro para gestionar copias de seguridad, migraciones y recuperación ante desastres. El formato DupArchive se creó específicamente para entornos de alojamiento en los que las copias de seguridad estándar basadas en ZIP fallan con mayor frecuencia: servidores limitados con tiempos de espera de PHP, cuotas de CPU y límites de E/S.

Y si desea probar cualquier cambio de configuración antes de aplicarlo a su sitio web en producción, la puesta en escena con un solo clic le permite crear una copia de su sitio a partir de cualquier copia de seguridad existente sin una cuenta de alojamiento separada.

Si esta publicación le hizo pensar en el rendimiento de las copias de seguridad y la salud del sitio, estas guías merecen ser leídas a continuación.

• Tu sitio de WordPress está perdiendo dinero cada segundo que es lento (aquí tienes la solución)
• Cómo cifrar archivos de copia de seguridad del sitio web para una máxima seguridad de los datos
• ¿Sitio caído? Aquí tienes tu plan completo de recuperación de sitios web
• Políticas de retención de copias de seguridad de sitios web: ¿Cuánto tiempo guardar las copias?
• Por qué tu sitio de WordPress necesita monitorización de copias de seguridad (no solo copias de seguridad)