Velocidad de copia de seguridad del sitio web: por qué sus copias de seguridad son lentas y cómo solucionarlas
John Turner
John Turner
Tu copia de seguridad lleva 45 minutos en ejecución. Nada está roto, pero una barra de progreso no deja de moverse.
O quizás tu sitio se ralentiza hasta casi detenerse todas las noches a las 3 AM, y no puedes averiguar por qué. Revisas la configuración de tus plugins, realizas una prueba de velocidad y no encuentras nada obvio. Entonces alguien menciona las copias de seguridad y lo entiendes.
Las copias de seguridad lentas del sitio web son un problema real. El proceso de copia de seguridad en sí mismo podría estar tardando demasiado o fallando silenciosamente antes de finalizar. Por otro lado, tu copia de seguridad podría estar completándose bien, pero los recursos que consume mientras se ejecuta están ralentizando tu sitio en vivo.
La solución es diferente dependiendo del problema que enfrentes. Este tutorial cubre ambos.
Al final, habrás abordado la baja velocidad de las copias de seguridad del sitio web, habrás revisado la configuración de Duplicator Pro que la soluciona y habrás configurado un calendario de copias de seguridad que no compita con tu tráfico real.
Aquí están los puntos clave:
- Existen dos problemas distintos de velocidad de copia de seguridad: un proceso de copia de seguridad lento o roto y una copia de seguridad que ralentiza tu sitio en vivo durante la ventana de copia de seguridad. La solución es diferente para cada uno, y esta publicación cubre ambos.
- Una copia de seguridad que parece completa pero falla al restaurarse es un problema de tiempo de espera de PHP, no un problema de corrupción. El formato DupArchive de Duplicator Pro evita esto al procesar archivos en fragmentos en lugar de una operación continua.
- Reducir el tamaño de tu archivo es la palanca más rápida. Los directorios de caché, los archivos de registro y los archivos de copia de seguridad sobrantes de otros plugins se pueden excluir de forma segura y a menudo representan la mayor parte del peso innecesario de la copia de seguridad.
- Las copias de seguridad completas diarias suelen ser excesivas. Una copia de seguridad diaria solo de la base de datos (menos de 30 segundos) combinada con una copia de seguridad completa semanal reduce el tiempo de compilación y la carga del servidor sin sacrificar la cobertura de restauración.
- El cron de WordPress no se ejecuta en un horario real. Las copias de seguridad programadas para las 3 AM pueden cambiar silenciosamente a horas de tráfico pico. Reemplazar WP-Cron con un trabajo cron de servidor real es lo que hace que las copias de seguridad programadas sean realmente confiables.
- Prueba una restauración antes de necesitarla. La mayoría de las personas descubren una copia de seguridad rota durante un desastre real. Verificar una restauración en un sitio de staging toma 20 minutos y es el único paso que separa una recuperación rápida de una dolorosa.
Tabla de Contenidos
- ¿Cuánto Debería Tardar una Copia de Seguridad de WordPress?
- Lo que necesitas antes de empezar
- How to Speed Up Your Website Backups
- Paso 1: Identifica tu Problema de Rendimiento de Copia de Seguridad
- Paso 2: Reduce lo que se Copia
- Step 3: Switch to a Faster Backup Engine
- Step 4: Fix Slow Database Backups
- Paso 5: Reemplaza WordPress Cron con un Cron de Servidor Real
- Paso 6: Configura una Estrategia de Copia de Seguridad de Dos Horarios
- Paso 7: Añade Copias de Seguridad Incrementales
- Paso 8: Solicita Límites de Recursos del Servidor Más Altos
- Troubleshooting: When Backups Are Still Slow or Broken
- La Copia de Seguridad se Completa pero Falla al Restaurarse
- La Copia de Seguridad se Queda Atascada en un Porcentaje Específico
- El Sitio se Ralentiza Todas las Noches a la Misma Hora
- Shell Exec Causa un Fallo Inmediato en la Compilación
- Las Copias de Seguridad Funcionan en Staging pero Fallan en el Servidor en Vivo
- Frequently Asked Questions (FAQs)
¿Cuánto Debería Tardar una Copia de Seguridad de WordPress?
En un sitio bien configurado con un hosting decente, una copia de seguridad completa debería completarse en entre dos y diez minutos. Los sitios grandes en hosting compartido podrían tardar de 30 a 45 minutos, a veces más. Y el tiempo varía no solo por el tamaño del sitio, sino por cómo se ejecuta la copia de seguridad, lo que permite tu host y si tu servidor está bajo carga cuando comienza el proceso.
Cuatro factores impulsan la mayor parte de la variación.
- Límites de E/S del host
El hosting compartido limita la cantidad de operaciones de lectura y escritura que su cuenta puede realizar por segundo. Una copia de seguridad lee cada archivo de su sitio y los escribe en un archivo. En un servidor limitado, ese proceso se ralentiza hasta casi detenerse y puede afectar el tiempo de respuesta de su sitio mientras se ejecuta.
- Tamaño del sitio
Una biblioteca multimedia grande, una base de datos hinchada o años de archivos de complementos acumulados extienden el tiempo de compilación. Un sitio de 500 MB y un sitio de 5 GB no se respaldarán de la misma manera.
- Método de copia de seguridad
Las copias de seguridad completas comprimen todo desde cero cada vez. Las copias de seguridad incrementales solo guardan lo que cambió desde la última ejecución, lo que las hace significativamente más rápidas después de que se completa la primera copia de seguridad. Duplicator Pro admite ambos enfoques, y la estrategia de dos programaciones en este tutorial le brinda la mayor parte del beneficio de velocidad de las copias de seguridad incrementales sin la complejidad.
- Tiempos de espera de PHP
La mayoría de los hosts compartidos establecen límites de tiempo de ejecución de PHP entre 30 y 60 segundos. Una copia de seguridad que excede ese límite se interrumpe a mitad del proceso. El archivo parece completo. No lo está. Esta es una de las causas más comunes de copias de seguridad que parecen tener éxito pero fallan durante una restauración.
Lo que necesitas antes de empezar
Antes de cambiar cualquier configuración, asegúrese de tener lo siguiente implementado.
- Un plugin de copia de seguridad de WordPress instalado y activo. Este tutorial utiliza Duplicator Pro para todos los pasos específicos y referencias de interfaz de usuario. Duplicator Pro es un plugin de copia de seguridad, migración y recuperación ante desastres de WordPress utilizado por más de 1.5 millones de profesionales de WordPress. Maneja copias de seguridad, migraciones de sitios, staging y restauraciones, incluido un formato de archivo basado en fragmentos diseñado específicamente para sobrevivir a los límites de tiempo de espera de PHP comunes en el hosting compartido.
- Acceso de administrador de WordPress (lo necesitará para acceder a la configuración de su plugin de copia de seguridad)
- Acceso al panel de control de hosting (cPanel o el equivalente de su host: necesario para la configuración de cron del servidor y los cambios en los límites de PHP)
- El tamaño actual de su copia de seguridad (encuéntrelo en la pantalla de paquetes o historial de copias de seguridad de su plugin)
- Su tipo de hosting: compartido, VPS, WordPress administrado o dedicado. Esto es importante porque algunas soluciones en este tutorial requieren la cooperación de su host. En el hosting compartido, no siempre puede cambiar la configuración de PHP usted mismo.
- Acceso al soporte de hosting (chat en vivo o un sistema de tickets de soporte: es posible que lo necesite para los pasos 3 y 8)
Conocer su tipo de hosting antes de comenzar le ahorrará tiempo. Los aumentos de Shell Exec y del límite de memoria de PHP se controlan a nivel del servidor. Lo que puede cambiar usted mismo depende completamente de su plan.
Cómo acelerar las copias de seguridad de su sitio web
Trabajar en estos pasos le dará los resultados más rápidos. El primer paso es un diagnóstico, para que sepa qué soluciones se aplican realmente a su situación antes de comenzar a cambiar la configuración.
Esto es lo que hará:
- Paso 1: Identifique el problema de rendimiento de su copia de seguridad: diagnostique si su proceso de copia de seguridad es lento o está roto, o si las copias de seguridad completadas están ralentizando su sitio en vivo, ya que la solución es diferente para cada uno
- Paso 2: Reduce lo que se respalda: excluye directorios de caché, archivos de registro y archivos de plugins sobrantes para reducir el tamaño de tu archivo, que es la forma más rápida de reducir el tiempo de compilación.
- Paso 3: Cambia a un motor de archivo más rápido: reemplaza ZipArchive basado en PHP con Shell Exec para mayor velocidad o DupArchive para resiliencia en hosts con límites de ejecución de PHP estrictos.
- Paso 4: Soluciona copias de seguridad lentas de la base de datos: cambia el modo SQL a Código PHP y ejecuta una limpieza de la base de datos para reducir el tiempo de exportación en bases de datos de más de 20 MB.
- Paso 5: Reemplaza el cron de WordPress con un trabajo cron de servidor real: haz que las copias de seguridad programadas se ejecuten a la hora exacta que estableces en lugar de activarse cuando llega el primer visitante.
- Paso 6: Configura una estrategia de copia de seguridad de dos programaciones: ejecuta copias de seguridad diarias solo de la base de datos y copias de seguridad semanales de todo el sitio por separado para que las compilaciones pesadas ocurran con la menor frecuencia posible.
- Paso 7: Solicita límites de recursos del servidor más altos: aumenta los límites de memoria y tiempo de ejecución de PHP como último recurso cuando todas las demás configuraciones ya estén optimizadas.
Paso 1: Identifica tu Problema de Rendimiento de Copia de Seguridad
Hay dos problemas diferentes ocultos dentro de "mi copia de seguridad es lenta".
- Problema A: El proceso de copia de seguridad en sí es lento o está roto. Las señales incluyen compilaciones que tardan más de 20 minutos, una barra de progreso que se congela en un porcentaje específico o una copia de seguridad que parece completarse pero falla durante una restauración.
- Problema B: Tus copias de seguridad están ralentizando tu sitio en vivo. Las señales incluyen visitantes o administradores que informan lentitud durante una ventana de tiempo recurrente o una herramienta de monitoreo que muestra un pico en el tiempo de respuesta que ocurre en un horario predecible.
Para diferenciarlos, comienza con el registro de compilación de tu plugin de copias de seguridad. Para Duplicator, ve a Duplicator Pro » Herramientas » Registros de Duplicator. Encuentra el registro de tu copia de seguridad más reciente.

Otros plugins tienen registros similares; consulta la configuración avanzada de tu plugin.
Desplázate hasta el final. Si ves un error de tiempo de espera, un error de memoria o una línea que se corta a mitad del proceso, ese es el Problema A. Si el registro muestra que se completó, pero tu sitio todavía está arrastrando, ese es el Problema B.
Un escenario más que vale la pena nombrar antes de continuar: si el registro de compilación dice que la copia de seguridad se completó pero falla durante una restauración, es probable que un límite de tiempo de ejecución de PHP haya cortado la compilación silenciosamente antes de que terminara.
El archivo existe, pero fue truncado. Parece el Problema A, pero la causa raíz es un límite de recursos de alojamiento. El Paso 3 cubre esto directamente.
Si necesitas ayuda para leer los registros de copia de seguridad de Duplicator, lee esta guía.
Paso 2: Reduce lo que se Copia
Cada megabyte adicional en tu copia de seguridad extiende el tiempo de compilación. En alojamiento compartido, donde la CPU y la E/S del disco ya están limitadas, un archivo inflado hace que las copias de seguridad sean más lentas y te acerca al umbral de tiempo de espera donde las copias de seguridad comienzan a fallar.
La forma más rápida de reducir tu copia de seguridad es dejar de incluir archivos que no necesitan estar allí.
Los infractores más comunes:
- Directorios de caché
- Archivos de registro
- Archivos temporales
- Archivos de copia de seguridad dejados por otros plugins
- Archivos multimedia grandes como videos que también almacenas en una CDN o servicio externo
Ninguno de estos afecta tu capacidad de restaurar un sitio funcional. Las cachés se regeneran automáticamente cuando los visitantes cargan páginas. Los registros no forman parte de tu sitio. Los archivos de copia de seguridad antiguos de otros plugins solo añaden peso.
Aquí te explicamos cómo personalizar las copias de seguridad en Duplicator Pro. Crea una nueva copia de seguridad yendo a Duplicator Pro » Copias de seguridad » Añadir nueva.

En la sección Copia de seguridad, verás ajustes preestablecidos y filtros.

Habilita los filtros de archivos. Excluye primero tu directorio de caché seleccionando el filtro de caché.

Si usas un plugin de caché como WP Rocket o W3 Total Cache, puede que haya una subcarpeta específica del plugin dentro de wp-content. Añade la ruta completa para cada una.
Luego, añade cualquier directorio de registros. Las ubicaciones comunes incluyen wp-content/debug.log y carpetas de registros específicas de plugins.
No excluyas wp-content/uploads a menos que almacenes todos tus medios en una CDN separada y tengas una copia confirmada y actual de cada archivo. Solo excluye extensiones de archivo específicas que estés seguro de que se copian en otro lugar. Equivocarte aquí con tus medios significa una restauración exitosa pero a la que le falta la mitad de tus imágenes.
Una vez que hayas añadido tus filtros, continúa con la copia de seguridad. Duplicator Pro escaneará tu sitio e informará sobre cualquier otro tamaño de archivo grande.

Paso 3: Cambia a un motor de copias de seguridad más rápido
Una vez que tu archivo de copia de seguridad sea lo más ligero posible, la siguiente variable es cómo se crea la copia de seguridad. Por defecto, utiliza ZipArchive integrado de PHP. Eso funciona, pero se ejecuta completamente dentro de PHP, lo que significa que está sujeto a todos los límites de recursos que tu host establece: tiempo de ejecución, memoria y limitación de CPU.
En un servidor capaz, probablemente esté bien. En alojamiento compartido, podría crear cuellos de botella.
Tienes dos alternativas, y cuál usar depende de tu host.
Opción A: Shell Zip
Esto cambia el motor del archivo de copia de seguridad de PHP a la utilidad zip nativa del sistema de tu servidor. La herramienta zip del sistema operativo es más rápida que PHP para la mayoría de las tareas de compresión y no cuenta contra tu límite de tiempo de ejecución de PHP de la misma manera.
Para cambiar, ve a Duplicator Pro » Ajustes » Copias de seguridad » Archivo y selecciona Shell Zip.

Antes de hacer el cambio, ten en cuenta esto: algunos hosts de alojamiento compartido económicos deshabilitan shell_exec a nivel de servidor. Si cambias la configuración y tu próxima compilación falla inmediatamente al 0%, eso es lo que ha sucedido.
Vuelve a ZipArchive en la misma pantalla de configuración, luego contacta a tu host y pídeles que habiliten shell_exec para tu cuenta. Si no pueden ayudarte, pasa a la Opción B.
Opción B: DupArchive
Este es el formato de archivo propio de Duplicator, y funciona de manera diferente al ZIP estándar. En lugar de una operación de compresión continua, DupArchive procesa tus archivos en fragmentos más pequeños. Cada fragmento se completa antes de que comience el siguiente.
En los planes de alojamiento compartido con límites de tiempo de ejecución de PHP de 30 a 60 segundos, una copia de seguridad ZIP estándar que tarda más que ese límite se interrumpe a mitad de la compilación. El proceso se detiene, pero el archivo ya se ha escrito en el disco.
Tu copia de seguridad parece completa. Luego, cuando intentas restaurarla, falla. El archivo se cortó antes de que terminara.
DupArchive evita esto por completo. Dado que cada fragmento reinicia el reloj de ejecución de PHP, la copia de seguridad sobrevive a los límites que matarían una compilación ZIP estándar. He visto que esta solución soluciona problemas en alojamientos compartidos más de una vez.
Para cambiar, ve a Duplicator Pro » Ajustes » Copias de seguridad » Archivo y elige DupArchive.

Después de cambiar a cualquiera de las opciones, ejecuta una copia de seguridad de prueba. Crea una copia de seguridad pequeña y luego revisa el registro cuando termine. Desplázate hasta el final del registro y confirma que se completó correctamente.
Paso 4: Solucionar copias de seguridad lentas de bases de datos
Una base de datos grande ralentiza toda la compilación de la copia de seguridad, no solo la parte donde se exporta la base de datos. Si tu base de datos está hinchada, lo notarás en todo el proceso.
Para conocer el tamaño de tu base de datos, inicia una nueva copia de seguridad en Duplicator Pro y deja que el asistente de configuración ejecute el análisis. Mostrará el tamaño de tu base de datos antes de que te comprometas a crear la copia de seguridad.
Si supera los 20 MB, estas soluciones pueden marcar una diferencia notable.
Solución 1: Cambiar el modo SQL a Código PHP
Ve a Duplicator Pro » Ajustes » Copias de seguridad » Modo SQL y cambia el ajuste de Volcado de MySQL a Código PHP. Esto cambia el método que Duplicator utiliza para exportar tus tablas de base de datos.

El método de Código PHP es generalmente más fiable en alojamientos compartidos porque es menos probable que active tiempos de espera de bloqueo de tablas que detienen la exportación. Es un pequeño cambio con un efecto significativo en bases de datos más grandes.
Solución 2: Limpiar la base de datos antes de tu próxima copia de seguridad
Esta tarea lleva unos minutos, pero vale la pena hacerla antes de cualquier copia de seguridad importante.
Instala WP-Optimize o un plugin de limpieza de bases de datos similar y ejecútalo para eliminar revisiones de publicaciones, comentarios de spam, transitorios caducados y metadatos huérfanos. Estos se acumulan silenciosamente en sitios activos y pueden representar entre el 30 y el 50 por ciento de la hinchazón de la base de datos sin contener nada que necesites restaurar.

En mi sitio personal, realicé una copia de seguridad antes y después de una limpieza rápida de la base de datos con WP-Optimize. Redujo 30 segundos de mi tiempo de copia de seguridad y el tamaño del archivo.

Sin embargo, no limpies tu base de datos y ejecutes inmediatamente una copia de seguridad crítica por primera vez. Realiza la limpieza, luego navega por tu sitio y verifica que todo funcione normalmente, luego haz la copia de seguridad. Las limpiezas son seguras cuando se hacen con una herramienta de confianza, pero quieres confirmar que tu sitio está en buen estado antes de bloquear ese estado en una copia de seguridad.
Después de realizar ambos cambios, ejecuta una nueva copia de seguridad y compara el tiempo de compilación con tu línea de base anterior. En bases de datos de más de 20 MB, la diferencia suele ser visible.
Paso 5: Reemplaza WordPress Cron con un Cron de Servidor Real
Si tus copias de seguridad están programadas pero siguen ejecutándose a la hora incorrecta, o si tu sitio se ralentiza durante el horario comercial en lugar de la ventana de inactividad que estableciste, es probable que el cron de WordPress sea la razón.
WP-Cron no se ejecuta en un horario real. Se activa solo cuando alguien visita tu sitio.
Cuando llega el tráfico, WordPress comprueba si hay tareas pendientes y las ejecuta en ese momento. Una copia de seguridad que programaste para las 3 AM se ejecuta cuando aparece el primer visitante, lo que podría ser justo en medio de tu ventana de tráfico pico.
Reemplazar WP-Cron con un trabajo cron del servidor asegura que tus copias de seguridad se ejecuten a la hora exacta que establezcas, siempre, independientemente del tráfico.
Empieza creando una cuenta en https://cron-job.org/. Luego, crea un nuevo trabajo cron.

Nombra el nuevo trabajo cron. Establece esto como la URL, reemplazándola con el dominio de tu sitio: https://example.com/wp-admin/admin-ajax.php?action=duplicator_process_worker
Establece el Horario de ejecución a Cada 1 minuto.

Una vez que el trabajo cron del servidor esté activo y guardado, añade esta línea a tu archivo wp-config.php, encima de la línea que dice "Eso es todo, ¡deja de editar!":
define('DISABLE_WP_CRON', true);
Esto le dice a WordPress que deje de ejecutar su propio sistema cron.
Añade la línea define a wp-config.php solo después de que el trabajo cron del servidor se haya confirmado y guardado. Si deshabilitas WP-Cron primero, todas las tareas programadas en tu sitio se pausan inmediatamente. Las copias de seguridad programadas, las publicaciones programadas, cualquier cosa que dependa de WP-Cron se detiene hasta que el cron del servidor esté activo.
Si estás en un hosting de WordPress gestionado como WP Engine, Kinsta o Flywheel, consulta la documentación de tu hosting antes de editar wp-config.php. Algunos hostings gestionados manejan el cron del servidor de forma diferente o lo gestionan en tu nombre.
Después de la configuración, vuelve a Duplicator Pro » Ajustes » Programar Copias de Seguridad y verifica que la hora de la próxima ejecución programada refleje exactamente lo que configuraste. Esa confirmación es tu señal de que el traspaso funcionó.
Paso 6: Configura una Estrategia de Copia de Seguridad de Dos Horarios
Las copias de seguridad completas diarias del sitio son una de las causas más comunes tanto de copias de seguridad lentas como de sitios lentos en hosting compartido. También son, para la mayoría de los sitios de WordPress, más de lo que realmente necesitas.
Tu base de datos cambia constantemente, con nuevas publicaciones, pedidos, envíos de formularios, comentarios y actividad de plugins. En contraste, tus archivos, temas, plugins y subidas se actualizan ocasionalmente.
Ejecutar una copia de seguridad completa todos los días significa comprimir y archivar gigabytes de archivos que no han cambiado recientemente.
La solución son dos programaciones de copia de seguridad separadas.
- Programación A: copia de seguridad diaria solo de la base de datos. Una copia de seguridad solo de la base de datos captura cada cambio en tu contenido, pedidos y ajustes sin tocar tus archivos. En la mayoría de los sitios se completa en menos de 30 segundos. Ejecuta esto diariamente.
- Programación B: copia de seguridad semanal completa del sitio. Incluye archivos, ejecútala una vez a la semana durante tu ventana de menor tráfico real. Esta es la copia de seguridad que restauras si algo sale muy mal.
Antes de establecer la programación, encuentra tu ventana real de menor tráfico. Busca el bloque de dos horas con menos sesiones a lo largo de una semana típica.
Para la mayoría de los sitios, esto se sitúa entre las 2 y las 5 AM, pero verifica con tus propios datos. Tu patrón de tráfico no es el mismo que el de nadie más.
Luego, ve a Duplicator Pro » Programar Copias de Seguridad » Añadir Nueva. Nombra la programación algo como Copia de Seguridad de Base de Datos. Añade una nueva plantilla de copia de seguridad.

Nombra la plantilla. Elige el ajuste preestablecido de copia de seguridad Solo Base de Datos y guárdala.

Vuelve a la nueva programación y elige la plantilla de copia de seguridad de base de datos que acabas de crear. Elige una ubicación de almacenamiento y configúrala para que se ejecute diariamente.

Guárdalo. Luego crea un segundo plan y repite el proceso, pero con una plantilla de copia de seguridad de sitio completo. Déjalo ejecutarse semanalmente.

Ambos planes aparecerán en Duplicator Pro » Planes de Copias de Seguridad con sus próximas horas de ejecución indicadas.

Paso 7: Añade Copias de Seguridad Incrementales
Las copias de seguridad completas comprimen todo tu sitio desde cero cada vez que se ejecutan. Eso está bien para copias de seguridad semanales de sitio completo, pero es más de lo que la mayoría de los sitios necesitan para protección diaria.
Las copias de seguridad incrementales adoptan un enfoque diferente: después de la primera copia de seguridad completa, solo guardan lo que cambió desde la última ejecución. La copia de seguridad se completa más rápido porque no está reprocesando archivos que no han cambiado.
Duplicator Pro no ejecuta copias de seguridad incrementales reales, pero la estrategia de dos planes del Paso 6 te proporciona la mayor parte del mismo beneficio. Las copias de seguridad diarias solo de la base de datos capturan todo lo que cambia en un sitio de WordPress típico, completándose en menos de 30 segundos. La copia de seguridad semanal de sitio completo se encarga de todo lo demás.
Para la mayoría de los sitios, esa división cubre la necesidad práctica que las copias de seguridad incrementales están diseñadas para resolver.
Si tu sitio es lo suficientemente grande como para que incluso las copias de seguridad semanales de sitio completo sean consistentemente lentas o fallen, las copias de seguridad incrementales de archivos pueden valer la pena implementarlas. Herramientas como BlogVault procesan las copias de seguridad en sus servidores en lugar de los tuyos, lo que elimina el problema de la carga del servidor.
Paso 8: Solicita Límites de Recursos del Servidor Más Altos
Los límites de memoria y tiempo de ejecución de PHP son restricciones reales, pero cambiarlos requiere la cooperación de tu host y no soluciona problemas subyacentes como un archivo comprimido hinchado o un plan mal programado.
Trabaja primero en los pasos anteriores. Si las copias de seguridad siguen fallando por tiempo de espera, entonces el límite podría ser los límites de recursos de tu plan de hosting.
Dos configuraciones son las más importantes para la velocidad de copia de seguridad: memory_limit y max_execution_time.
memory_limit controla cuánta RAM puede usar PHP durante un solo proceso. Las copias de seguridad consumen mucha memoria. Si tu límite está establecido en 64 MB o 128 MB, las compilaciones grandes se quedan sin espacio y mueren antes de terminar.
Pide al menos 256 MB. Si tu host ofrece 512 MB, solicítalo en su lugar.
max_execution_time controla cuánto tiempo puede ejecutarse un proceso PHP antes de que el servidor lo termine. El valor predeterminado en muchos hosts compartidos es de 30 a 60 segundos. Una copia de seguridad grande necesita significativamente más que eso. Pide 300 segundos.
Contacta al equipo de soporte de tu host y sé específico en tu solicitud. Pide un memory_limit de 512 MB y un max_execution_time de 300 segundos.
Si tu host no puede o no quiere aumentar estos límites, DupArchive del Paso 3 es tu camino práctico a seguir. Está diseñado específicamente para funcionar dentro de límites PHP estrictos dividiendo el proceso. Es más lento que Shell Exec en un servidor capaz, pero se completa donde una compilación ZIP estándar no lo haría.
Después de cualquier cambio de límite, ejecuta una copia de seguridad de prueba y abre el registro de compilación. Confirma que la copia de seguridad se completó sin errores de tiempo de espera o de memoria.
Solución de problemas: Cuando las copias de seguridad siguen siendo lentas o están rotas
Trabajar en los pasos anteriores resuelve la mayoría de los problemas de velocidad de copia de seguridad del sitio web. Si algo sigue mal, esto es lo que probablemente estás viendo y cómo superarlo.
La Copia de Seguridad se Completa pero Falla al Restaurarse
Ves una copia de seguridad, el registro de compilación no muestra errores obvios, pero cuando ejecutas el instalador, falla o restaura un sitio en blanco.
Esto sucede porque un límite de tiempo de ejecución de PHP interrumpió la compilación antes de que terminara realmente. El archivo se escribió en el disco hasta ese punto y luego se detuvo.
Cambia a DupArchive (cubierto en el Paso 3), luego elimina la copia de seguridad fallida y crea una nueva. Ejecuta el instalador y verifica que la restauración se complete antes de confiar en ella.
La Copia de Seguridad se Queda Atascada en un Porcentaje Específico
La barra de progreso se congela en un punto particular y permanece allí durante más de diez minutos sin moverse.
Un archivo grande o una tabla de base de datos bloqueada está impidiendo el proceso en ese punto exacto de la compilación. Ve al registro de copias de seguridad y desplázate para encontrar el último archivo o tabla listada antes de que se corte el registro. Ese es tu culpable.
Si es un archivo, agrégalo a tus filtros de exclusión (Paso 2) y reconstruye. Si es una tabla de base de datos, cambia el Modo SQL a Código PHP (Paso 4) e inténtalo de nuevo.
El Sitio se Ralentiza Todas las Noches a la Misma Hora
Los visitantes o tu herramienta de monitoreo informan lentitud durante una ventana específica. El momento coincide con tu copia de seguridad programada.
Tu copia de seguridad se está ejecutando durante un período de tráfico activo y compitiendo por los mismos recursos de CPU y disco que sirven a tus visitantes. Consulta tu ventana de bajo tráfico real en Google Analytics y reprograma la copia de seguridad para ese momento.
Si estás ejecutando copias de seguridad completas diarias del sitio, cambia a la estrategia de dos programaciones del Paso 6. Las copias de seguridad solo de la base de datos se completan lo suficientemente rápido como para que el impacto en el rendimiento sea mínimo, incluso durante el tráfico moderado.
Shell Exec Causa un Fallo Inmediato en la Compilación
Cambiaste el motor de archivo a Shell Exec, y la siguiente compilación falla al 0% con un error inmediato.
Tu host ha deshabilitado shell_exec a nivel de servidor. Vuelve a cambiar a ZipArchive o DupArchive. Luego, contacta a tu host y pregunta específicamente si shell_exec se puede habilitar para tu cuenta.
Si dicen que no, DupArchive es tu motor de archivo a largo plazo. Maneja los mismos problemas de tiempo de espera que Shell Exec habría resuelto, solo que a través de un método diferente.
Las Copias de Seguridad Funcionan en Staging pero Fallan en el Servidor en Vivo
Nuestras copias de seguridad se realizan correctamente en sitios de staging o locales, pero agotan el tiempo de espera o producen archivos corruptos en producción.
Tu servidor en vivo tiene límites de PHP más estrictos o está bajo una limitación activa de CPU que tu entorno de staging no tiene. Compara la configuración de PHP entre entornos: verifica memory_limit y max_execution_time en ambos. Solicita límites más altos a tu host en vivo (Paso 7), o cambia a DupArchive para trabajar dentro de los límites existentes.
Si nada de lo anterior resuelve tu problema, el equipo de soporte de Duplicator Pro es el siguiente paso correcto. Ve a duplicator.com y abre un ticket de soporte. Incluye tu registro de compilación, tu configuración de PHP y tu entorno de alojamiento. Esas tres piezas de información te llevarán a una resolución más rápido que una descripción genérica del problema.
Preguntas Frecuentes (FAQs)
¿Cuánto debería tardar una copia de seguridad de WordPress?
Depende del tamaño de tu sitio y de los recursos de tu servidor. Un sitio pequeño de menos de 500 MB en un host compartido decente debería completarse en dos a cinco minutos. Un sitio más grande en el rango de 2 a 5 GB puede tardar de 15 a 30 minutos en alojamiento compartido, más rápido en VPS o dedicado.
Si una copia de seguridad tarda sistemáticamente más de 45 minutos o falla antes de finalizar, algo en tu configuración necesita atención. Empieza por las exclusiones de archivos y la configuración del motor de archivado antes de asumir que tu servidor es el problema.
¿Las copias de seguridad ralentizan mi sitio web?
Sí, pueden. Las copias de seguridad leen cada archivo de tu instalación de WordPress, los comprimen en un archivo y exportan tu base de datos. Todo eso consume la misma CPU, memoria y E/S de disco que atiende a tus visitantes. En el alojamiento compartido, el efecto es más notable porque esos recursos ya se dividen entre varias cuentas.
La solución es programar las copias de seguridad durante tu ventana de menor tráfico real y separar las copias de seguridad diarias solo de la base de datos de las copias de seguridad completas semanales del sitio, para que el trabajo pesado ocurra con la menor frecuencia posible.
¿Por qué DupArchive es mejor que zip?
DupArchive es el formato de archivo de copia de seguridad de Duplicator. En lugar de una compresión continua, procesa los archivos en fragmentos más pequeños, y cada fragmento se completa antes de que comience el siguiente. Esto lo hace más resistente en el alojamiento compartido, donde los límites de tiempo de ejecución de PHP son estrictos.
Una compilación ZIP estándar que tarda más que el límite de tu host se interrumpe a mitad del proceso y produce un paquete dañado. DupArchive sobrevive a esos límites porque cada fragmento reinicia el reloj.
No siempre es más rápido que ZIP en servidores capaces, pero es significativamente más fiable en entornos de alojamiento compartido limitados.
¿Puedo hacer una copia de seguridad solo de la base de datos para ahorrar tiempo?
Sí, y para las copias de seguridad diarias suele ser la decisión correcta. Tu base de datos captura todo lo que cambia con regularidad: publicaciones, pedidos, comentarios, envíos de formularios y configuraciones de plugins. Tus archivos cambian con mucha menos frecuencia.
Realizar una copia de seguridad diaria solo de la base de datos y una copia de seguridad completa del sitio semanalmente te proporciona puntos de restauración actuales para tu contenido sin la sobrecarga de comprimir gigabytes de archivos cada 24 horas.
¿Por qué mi copia de seguridad parece completa pero falla al restaurar?
Un límite de tiempo de ejecución de PHP interrumpió la compilación antes de que finalizara. El archivo de copia de seguridad se escribió en el disco hasta ese punto, por lo que aparece y el tamaño del archivo parece razonable, pero la copia de seguridad está incompleta. Cambia a DupArchive en Duplicator Pro » Configuración » General » Motor de archivado, elimina la copia de seguridad fallida y vuelve a crearla. El procesamiento basado en fragmentos de DupArchive sobrevive a los límites de ejecución que causan este problema.
¿Qué configuración de PHP necesito cambiar para copias de seguridad más rápidas?
Los dos que más importan son memory_limit y max_execution_time. Apunta a un límite de memoria de al menos 256 MB, preferiblemente 512 MB, y un tiempo de ejecución de 300 segundos. En servidores VPS o dedicados, puedes cambiar estos valores directamente en tu configuración de PHP. En alojamiento compartido, ponte en contacto con tu proveedor y solicita esos valores específicos por nombre. Si tu proveedor no puede aumentarlos, cambia a DupArchive, que está diseñado para completar copias de seguridad dentro de los estrictos límites de PHP.
¿Con qué frecuencia debo hacer una copia de seguridad de mi sitio de WordPress?
Depende de la frecuencia con la que cambie tu contenido. Para un sitio activo con publicaciones, pedidos o envíos de formularios diarios, una copia de seguridad diaria de la base de datos y una copia de seguridad semanal completa del sitio son una base práctica. Para un sitio que cambia con poca frecuencia, las copias de seguridad semanales completas del sitio pueden ser suficientes.
La pregunta más importante es si has probado una restauración recientemente. Una copia de seguridad que nunca has probado es una copia de seguridad que en realidad no sabes si funciona. Elige un entorno de staging, restaura tu copia de seguridad más reciente y verifica que el sitio se cargue correctamente.
Ejecuta tu próxima copia de seguridad sin preguntarte si funcionará
Una copia de seguridad lenta es un inconveniente. Una copia de seguridad que parece completa pero no se puede restaurar es un problema completamente diferente, y es más común de lo que la mayoría de la gente espera.
Las configuraciones de este tutorial existen porque el hosting compartido no fue diseñado para copias de seguridad de WordPress. Duplicator Pro sí.
Más de 1.5 millones de profesionales de WordPress utilizan Duplicator Pro para gestionar copias de seguridad, migraciones, staging y recuperación ante desastres en sitios de todos los tamaños. El formato DupArchive, la estrategia de dos programaciones y los filtros de exclusión de archivos te ayudan a evitar copias de seguridad lentas o que consumen muchos recursos.
Si este tutorial te ha sido útil, estas guías también merecen ser marcadas.
- Cómo las copias de seguridad de WordPress afectan el rendimiento del sitio (y cómo solucionarlo)
- Deja de adivinar por qué fallan las copias de seguridad (consulta estos registros en su lugar)
- ¿Sitio caído? Aquí tienes tu plan completo de recuperación de sitios web
- Por qué tu sitio de WordPress necesita monitorización de copias de seguridad (no solo copias de seguridad)
- Cómo ver tu copia de seguridad de WordPress como un sitio web funcional