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

El año pasado estuve investigando por qué una página web iba tan lenta y no encontré nada evidente. No había plugins nuevos, ni picos de tráfico, ni nada llamativo en los registros de errores.

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

La mayoría de los usuarios de WordPress instalan un plugin de copias de seguridad, eligen una programación y ya no vuelven a tocarlo. Es una de esas tareas que, una vez activado el plugin, se da por terminada.

Sin embargo, la configuración predeterminada de la mayoría de los plugins de copias de seguridad no está optimizada para el rendimiento, sino para la simplicidad.

Realizar una copia de seguridad completa diaria y guardarla en Dropbox parece una medida responsable. En un sitio web pequeño con un alojamiento generoso, lo es. En un sitio web más grande o con un alojamiento compartido económico, supone una merma constante del rendimiento que quizá ni siquiera notes debido a las copias de seguridad.

En esta entrada, te mostraré qué ocurre cuando se ejecuta una copia de seguridad, por qué algunas configuraciones afectan más al servidor que otras y los cambios concretos que reducen ese impacto casi a cero.

He aquí las principales conclusiones:

• Las copias de seguridad consumen muchos recursos: la compresión de archivos, la exportación de bases de datos y la carga en la nube consumen simultáneamente una cantidad considerable de CPU, E/S de disco y ancho de banda.
• Los límites del alojamiento compartido pueden provocar fallos silenciosos: los tiempos de espera ocultos de PHP y las cuotas de CPU/E/S en los servidores económicos suelen interrumpir las copias de seguridad de larga duración a mitad del proceso, lo que da lugar a archivos dañados o incompletos.
• El formato de copia de seguridad es importante: los archivos ZIP estándar se procesan en una sola pasada continua, lo que los hace muy vulnerables a los tiempos de espera del servidor. Los formatos por partes, como el formato DupArchive personalizado de Duplicator, evitan por completo estas limitaciones.
• La optimización es sencilla: puedes reducir prácticamente a cero la pérdida de rendimiento realizando las copias de seguridad fuera de las horas punta, excluyendo los archivos de caché, utilizando el cron del servidor y programando copias de seguridad solo de la base de datos con mayor frecuencia que las copias de seguridad completas del sitio.

Índice

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

Una copia de seguridad no consiste simplemente en copiar tus archivos a otra ubicación. Se trata de un proceso de varios pasos que se ejecuta íntegramente en tu servidor, compitiendo por los mismos recursos que se utilizan para mostrar tu sitio web a los visitantes.

Mientras se realiza la copia de seguridad, tu servidor está realizando dos tareas a la vez. En el alojamiento compartido, donde esos recursos ya se reparten entre docenas de sitios web, eso es importante.

Compresión de archivos y carga de la CPU

Durante una copia de seguridad, todos los archivos de tu instalación de WordPress se leen y se comprimen en un archivo. Ese proceso consume muchos recursos de la CPU.

En el alojamiento compartido, tu cuenta dispone de una parte limitada de la capacidad de procesamiento del servidor, y una copia de seguridad que comprima cientos de megabytes de archivos consumirá gran parte de esa capacidad.

Los sitios web más grandes agravan esta situación. Un mayor número de archivos implica un proceso de compresión más largo, lo que significa que la CPU está sometida a una mayor carga durante más tiempo.

Un blog pequeño con pocos archivos multimedia puede comprimirse en menos de un minuto. Un sitio web con imágenes subidas a lo largo de varios años puede tardar bastante más.

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

Exportación de bases de datos y bloqueo de tablas

La exportación de la base de datos suele ser la causa oculta. La mayoría de los usuarios piensan en sus archivos cuando se imaginan una copia de seguridad, pero WordPress almacena tus entradas, ajustes, usuarios y todo lo demás en una base de datos MySQL, lo que requiere un proceso de exportación independiente.

La mayoría de los plugins de copia de seguridad exportan la base de datos mediante 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 la tabla pueden provocar tiempos de espera en un servidor lento o con mucha actividad.

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

La lectura de miles de archivos durante una copia de seguridad genera una actividad considerable en el disco. El almacenamiento de tu servidor tiene un límite en cuanto al número de operaciones de lectura y escritura que puede gestionar por segundo, y una copia de seguridad que abarca toda tu instalación de WordPress supera ese límite.

Los servidores de alojamiento económico y compartido suelen seguir utilizando discos duros tradicionales en lugar de SSD. En esos servidores, una elevada actividad del disco durante una copia de seguridad ralentiza todo lo que tiene que ver con el almacenamiento, incluidas las consultas a la base de datos y las lecturas de archivos que generan tus páginas.

Carga en la nube y ancho de banda

El impacto en el rendimiento no termina cuando finaliza la creación del archivo. La mayoría de las configuraciones de copia de seguridad suben posteriormente ese archivo a un almacenamiento en la nube: Dropbox, Google Drive o S3. Esa subida se realiza a través de la misma conexión de servidor que atiende a tus visitantes.

Subir una copia de seguridad de 2 GB a Dropbox a la velocidad habitual de un alojamiento compartido lleva varios minutos. Durante ese tiempo, tu ancho de banda disponible puede verse saturado.

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

Los servidores de alojamiento económico y compartido imponen límites a nivel de servidor que la mayoría de los usuarios nunca encuentran documentados en ningún sitio.

No se trata de errores ni de configuraciones incorrectas. Son límites impuestos a propósito para evitar que una cuenta consuma recursos que afecten al resto de sitios web alojados en el mismo servidor.

El problema es que esos mismos límites interfieren en los procesos de copia de seguridad, y los fallos que provocan no siempre son evidentes.

Tiempos de espera de PHP

PHP tiene un límite de tiempo de ejecución. En los servidores compartidos económicos, suele estar fijado entre 30 y 60 segundos. Un proceso de copia de seguridad en un sitio web de gran tamaño puede tardar mucho más que eso, y cuando alcanza el límite, el servidor interrumpe el proceso a mitad de su ejecución.

El resultado es un archivo de copia de seguridad incompleto. Parece que hay una copia de seguridad. El archivo está ahí, pero se interrumpió antes de completarse, lo que significa que no se puede restaurar.

El sitio sufrió todas las consecuencias en el rendimiento que conlleva una copia de seguridad en curso y no obtuvo ningún resultado fiable. Un archivo de copia de seguridad dañado es peor que no tener ninguna copia de seguridad, ya que genera una falsa sensación de seguridad, dando a entender que estás protegido cuando en realidad no lo estás.

Cuotas de CPU y E/S

La mayoría de los servidores compartidos limitan el uso de la CPU por cuenta. Una vez que se alcanza el límite, el proveedor no detiene los procesos por completo, sino que los ralentiza. Todo lo que se ejecuta en tu cuenta se ralentiza, incluidas las solicitudes de páginas de los visitantes.

Los límites de E/S funcionan de la misma manera. Tu cuenta tiene un límite máximo de operaciones de lectura y escritura por segundo. Una copia de seguridad que comprima una biblioteca multimedia de gran tamaño alcanzará con frecuencia ese límite.

Por eso algunas copias de seguridad se realizan correctamente a las 3 de la madrugada, pero fallan al mediodía con la misma configuración. Las horas de menor actividad implican una menor carga base del servidor, lo que se traduce en un mayor margen antes de que se active el límite de cuota.

¿Importa el formato del archivo de copia de seguridad?

La mayoría de los plugins de copias de seguridad utilizan archivos ZIP por defecto. No es una mala opción para un sitio web pequeño alojado en un servidor con buenos recursos. Sin embargo, el formato ZIP procesa los archivos de forma secuencial, uno por uno, en una sola pasada ininterrumpida.

En un entorno de alojamiento compartido con recursos limitados, esa única ejecución ininterrumpida es precisamente lo que los tiempos de espera de PHP están diseñados para detener.

El formato de archivo que utiliza tu plugin de copias de seguridad determina la carga que ejerce sobre el servidor y si este puede soportar las limitaciones de un alojamiento económico. Esto casi nunca se menciona en las conversaciones sobre el rendimiento de las copias de seguridad, y a menudo marca la diferencia entre una copia de seguridad que se completa de forma fiable y otra que falla sin avisar.

Cómo gestiona DupArchive las limitaciones del servidor

Duplicator es un plugin de copias de seguridad para WordPress que utiliza un formato propio denominado DupArchive. Se ha diseñado específicamente para realizar copias de seguridad y migraciones de WordPress, teniendo en cuenta las limitaciones de los alojamientos económicos como factor clave en su diseño.

Mientras que un proceso ZIP estándar se ejecuta como una operación continua, DupArchive trabaja por partes más pequeñas. Cada parte se completa dentro de los límites de tiempo de ejecución del servidor, y luego el proceso continúa donde se había quedado.

Los tiempos de espera de PHP que interrumpirían una copia de seguridad basada en ZIP mientras se está ejecutando no tienen el mismo efecto, ya que cada fragmento es lo suficientemente breve como para completarse antes de que se active el límite.

Además, permite gestionar sitios web de mayor tamaño sin el límite de tamaño de archivo que provoca errores en los archivos ZIP. ¡Se han completado migraciones reales con DupArchive de más de 400 GB!

Para la mayoría de los usuarios de alojamiento compartido, ese margen significa que el formato simplemente funciona allí donde un enfoque basado en ZIP daría error de tiempo de espera o se corrompería.

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

Shell Zip frente a ZipArchive

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

Shell Zip delega la compresión al sistema operativo en lugar de ejecutarla a través de PHP. Cuando está disponible, es considerablemente más rápido, ya que el sistema operativo gestiona la compresión de forma más directa que un proceso de PHP.

En ocasiones, los proveedores de alojamiento Budget desactivan Shell Zip. Si es tu caso, puedes pedirles que lo activen o considerarlo una señal de que el procesamiento por fragmentos de DupArchive de Duplicator es la alternativa adecuada.

Estas dos opciones cubren entre ambas la mayoría de los entornos de alojamiento: Shell Zip para mayor rapidez cuando el proveedor lo permite y DupArchive para mayor fiabilidad cuando no es así.

Cómo realizar copias de seguridad sin ralentizar tu sitio web

El objetivo es que las copias de seguridad pasen desapercibidas para los visitantes. Se ejecutan, se completan y se suben sin que nadie note ninguna diferencia en la velocidad del sitio web.

Esto se puede conseguir en la mayoría de las configuraciones con unos pocos ajustes. Ninguno de ellos requiere cambiar de proveedor de alojamiento ni contratar a un desarrollador.

Las formas más eficaces de realizar copias de seguridad sin ralentizar tu sitio web:

• Programa las copias de seguridad en horas de poco tráfico: el momento lo es todo. Identificar las horas de menor actividad de tu sitio web garantiza que las copias de seguridad no compitan con los visitantes reales por los recursos del servidor.
• Excluir los archivos que no es necesario incluir en la copia de seguridad: al eliminar los directorios de caché, los registros y los archivos temporales, se reduce considerablemente el tamaño de la copia de seguridad, lo que ahorra recursos de la CPU y reduce la carga de E/S del disco.
• Realiza copias de seguridad de la base de datos con más frecuencia que las copias de seguridad completas: dado que la base de datos cambia constantemente, pero los archivos no, realizar copias de seguridad diarias y rápidas de la base de datos te permite reducir la frecuencia de las copias de seguridad completas del sitio a solo una vez a la semana.
• Utiliza el cron del servidor en lugar de WP-Cron: pasar de la programación de WordPress, que depende del tráfico, a una tarea cron dedicada del servidor garantiza que las copias de seguridad se ejecuten exactamente cuando deben.

Programa las copias de seguridad para que se realicen en horas de poco tráfico

La sincronización es la solución más eficaz que existe, independientemente del nivel de alojamiento que tengas. Una copia de seguridad que se ejecute a las 3 de la madrugada en un servidor con poca actividad tiene mucho más margen que la misma copia de seguridad ejecutada al mediodía, cuando compite con el tráfico real de visitantes.

La recomendación habitual es entre las 2 y las 5 de la madrugada, hora local. Esto se aplica a la mayoría de los sitios web, pero conviene consultar tus propias estadísticas.

Abre MonsterInsights, analiza el tráfico por horas y descubre cuál es tu verdadero valle. Algunos sitios web dirigidos a un público internacional no presentan un periodo claro de bajo tráfico. Otros registran su punto más bajo a primera hora de la tarde, en lugar de durante la noche. Organiza tu agenda en función de tus datos, no de una regla genérica.

No programes copias de seguridad durante las horas de mayor tráfico. Si envías un boletín informativo los martes a las 9 de la mañana, no realices una copia de seguridad los martes a las 9 de la mañana. Los picos de tráfico provocados por las campañas son precisamente el momento en el que no quieres una carga adicional en el servidor.

Excluir los archivos que no es necesario incluir en la copia de seguridad

La forma más rápida de reducir la carga de las copias de seguridad es reducir el volumen de datos que se copian. Los archivos más pequeños se comprimen más rápido, se cargan más rápido y ejercen menos presión sobre la E/S del disco durante todo el proceso.

Los directorios de caché son lo más importante. Tu plugin de caché los regenera automáticamente cuando se carga el sitio, por lo que no tiene sentido hacer una copia de seguridad de ellos.

También conviene excluir:

• Archivos de registro
• Carpetas temporales de carga
• Cualquier archivo de copia de seguridad que hayan dejado en el servidor otros complementos de copia de seguridad

En Duplicator, utiliza filtros de archivos y bases de datos para excluir los datos innecesarios. Te recomiendo el filtro «Cache» integrado.

El informe de análisis previo a la copia de seguridad identifica los archivos de gran tamaño antes de que se ejecute la copia. Vale la pena revisarlo antes de configurar una programación periódica. Dedicar unos minutos a ese informe puede reducir considerablemente el tamaño de la copia de seguridad.

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

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

Cada nueva publicación, comentario, pedido y envío de formulario se guarda en la base de datos. Eso es precisamente lo que debes respaldar con frecuencia.

Las copias de seguridad diarias que solo incluyen la base de datos son rápidas, suelen completarse en menos de 30 segundos y suponen una carga mínima para el servidor. Reserva las copias de seguridad completas del sitio (archivos y base de datos) para realizarlas semanalmente en horas de menor actividad.

Este enfoque te ofrece puntos de recuperación frecuentes para los datos más importantes, al tiempo que reduce la frecuencia del pesado proceso de copia de seguridad completa del sitio.

Utiliza el cron del servidor en lugar de WP-Cron

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

Si nadie visita el sitio a las 3 de la madrugada, la copia de seguridad no se ejecuta. Y lo que es peor, una visita al mediodía podría activar sin querer una copia de seguridad programada para ejecutarse durante la noche.

Una tarea cron en un servidor real se ejecuta según un horario fijo, independientemente del tráfico. La mayoría de los paneles de control de alojamiento permiten acceder a la configuración de cron.

Configurarlo para tu plugin de copias de seguridad te llevará unos minutos y elimina por completo la imprevisibilidad de WP-Cron. La documentación de Duplicator explica el proceso de configuración del cron del lado del servidor, por si aún no lo has hecho.

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

Quizás no relacionas las ralentizaciones del sitio web con las copias de seguridad porque no es fácil saber cuándo se producen. Una copia de seguridad que se ejecuta a una hora intempestiva no avisa de su llegada. Sin embargo, hay patrones que vale la pena buscar si tu sitio web se ha mostrado lento y no has podido identificar la causa.

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

• Las ralentizaciones del sitio se producen a la misma hora cada día o cada semana, coincidiendo con tu calendario de copias de seguridad
• Los registros de copia de seguridad muestran ejecuciones fallidas, incompletas o que faltan
• El panel de control de tu alojamiento muestra picos de CPU o de E/S siguiendo un patrón predecible
• Los visitantes señalan una lentitud que no se corresponde con tus horas habituales de mayor tráfico

Si dos o más de esos casos coinciden con lo que estás viendo, comprueba primero tu programación de copias de seguridad antes de investigar nada más.

Protege tu sitio web antes de realizar cualquier cambio

Antes de modificar los horarios de las copias de seguridad, cambiar los formatos de archivo o modificar cualquier configuración del servidor, realiza primero una copia de seguridad completa.

Parece obvio, pero es fácil pasarlo por alto cuando estás en medio de la resolución de un problema y tienes prisa por arreglarlo. A mí me ha pasado exactamente eso y se me ha creado un hueco en el historial de copias de seguridad justo antes de realizar unos cambios que no salieron como esperaba.

Los errores de configuración al configurar las copias de seguridad pueden dejarte sin ninguna copia de seguridad que funcione. Es realmente irónico que, al intentar mejorar la configuración de las copias de seguridad, acabes rompiendo tu red de seguridad.

Si quieres probar nuevas configuraciones de programación o de archivos de copia de seguridad antes de aplicarlas a tu sitio web en producción, el entorno de pruebas te ofrece un entorno aislado para comprobar primero que todo funciona correctamente.

Duplicator Pro te permite crear un sitio de prueba a partir de cualquier copia de seguridad existente con solo unos clics. No se necesita una cuenta de alojamiento independiente.

Una vez que hayas creado el entorno de pruebas, podrás solucionar problemas sin ningún riesgo.

Preguntas más frecuentes (FAQ)

Tu sitio web se merece una copia de seguridad que se adapte a él

Las copias de seguridad están pensadas para proteger tu sitio web, no para ralentizarlo. La pérdida de rendimiento que provoca una copia de seguridad mal configurada es real, pero casi siempre se puede solucionar sin cambiar de proveedor de alojamiento ni tener que reconstruir nada.

Los tres aspectos más importantes son cuándo se ejecutan las copias de seguridad, qué incluyen y qué formato utilizan. La mayoría de los sitios web pueden reducir el impacto en el rendimiento prácticamente a cero si tienen en cuenta estos tres aspectos.

Tu plugin de copias de seguridad debería proteger tu sitio web sin competir con él por los recursos del servidor. Es un equilibrio más difícil de lograr de lo que parece, sobre todo en los alojamientos compartidos y económicos, 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 diseñó específicamente para entornos de alojamiento en los que las copias de seguridad estándar basadas en ZIP suelen fallar con mayor frecuencia: servidores con recursos limitados que presentan tiempos de espera de PHP, cuotas de CPU y límites de E/S.

Y si quieres probar cualquier cambio en la configuración antes de aplicarlo a tu sitio web en producción, la función de entorno de pruebas con un solo clic te permite crear una copia de tu sitio a partir de cualquier copia de seguridad existente sin necesidad de una cuenta de alojamiento independiente.

Si este artículo te ha hecho reflexionar sobre el rendimiento de las copias de seguridad y el estado del sitio, te recomendamos que leas estas guías a continuación.

• Tu sitio WordPress pierde dinero cada segundo que va lento (aquí tienes la solución)
• Cómo cifrar los archivos de copia de seguridad de sitios web para garantizar la máxima seguridad de los datos
• ¿Se ha caído su sitio web? Este es su plan completo de recuperación de sitios web
• Políticas de conservación de copias de seguridad de sitios web: ¿Cuánto tiempo conservar las copias de seguridad?
• Por qué su sitio WordPress necesita supervisión de copias de seguridad (no sólo copias de seguridad)