¿Qué nos enseñaron más de 2000 sitios de WordPress sobre la configuración de copias de seguridad?
John Turner
John Turner
Tu copia de seguridad se detiene en el mismo punto cada vez.
Así que buscas ayuda. Un hilo del foro dice que reduzcas el tamaño del fragmento. Otro dice que desactives la compresión. Pruebas ambas cosas.
La copia de seguridad todavía se detiene. O ahora termina, pero tarda mucho más de lo que solía hacerlo.
Ese consejo solucionó la copia de seguridad de alguien. Simplemente la arregló en su servidor, y la tuya podría no permitir las mismas cosas.
Así que, en lugar de intercambiar anécdotas, analizamos datos. AutoTune, el probador de configuraciones integrado en Duplicator, realiza copias de seguridad de prueba reales en el servidor de un sitio hasta que una se completa. Analizamos dónde terminaron más de 2000 sitios.
En esta publicación, repasaremos esos resultados y explicaremos qué significan para la configuración de tu copia de seguridad.
Tabla de Contenidos
- Hallazgos Clave
- ¿Cómo prueba AutoTune tu servidor?
- ¿Cuántos sitios terminaron con configuraciones diferentes?
- ¿Existe una configuración de copia de seguridad óptima para WordPress?
- ¿Qué correcciones comunes fueron generalmente innecesarias?
- ¿Con qué frecuencia necesitó AutoTune más de un intento?
- ¿Qué sucede cuando ninguna configuración de copia de seguridad funciona?
- ¿Qué deberías hacer con tus propias configuraciones de copia de seguridad?
- Preguntas Frecuentes (FAQs)
Hallazgos Clave
Para cualquiera que quiera los números primero, esto es lo que muestran los datos. Cada cifra proviene de los datos de uso de AutoTune de Duplicator.
- AutoTune cambió al menos una configuración de copia de seguridad en aproximadamente 9 de cada 10 sesiones de ajuste. Eso no significa necesariamente que las configuraciones anteriores estuvieran rotas.
- Shell ZIP con mysqldump representó aproximadamente la mitad de las configuraciones exitosas.
- PHP ZIP representó poco menos de 4 de cada 10 configuraciones exitosas, mientras que DupArchive representó menos de 1 de cada 10.
- Mysqldump apareció en aproximadamente 2 de cada 3 configuraciones exitosas. La exportación de bases de datos basada en PHP manejó el resto.
- Casi todas las configuraciones exitosas utilizaron compresión y el tamaño de fragmento de 128 MB.
- Aproximadamente 9 de cada 10 sesiones de ajuste exitosas se completaron en el primer intento de prueba.
- Más de 8 de cada 10 sesiones de ajuste encontraron una configuración exitosa.
¿Cómo prueba AutoTune tu servidor?
AutoTune de Duplicator realiza copias de seguridad de prueba reales en tu sitio. Comienza con la configuración más rápida. Si una prueba falla, ajusta la configuración y prueba otra.
Una vez que una prueba tiene éxito, guarda esas configuraciones automáticamente. Si el problema es un límite del servidor que ninguna configuración puede cambiar, te lo indica en su lugar.

AutoTune ajusta cuatro grupos de configuraciones de copia de seguridad. Esto es lo que controla cada uno:
- Motor de archivo y compresión: Cómo se empaquetan los archivos en la copia de seguridad.
- Modo ZIP y tamaño de fragmento: Cómo se divide el procesamiento del archivo en pasos.
- Motor de base de datos y modo de volcado: Cómo se exporta la base de datos.
- Reducción de carga del servidor: Si el procesamiento se ralentiza para reducir la presión sobre el servidor.
Su Resumen del servidor también informa información sobre tu entorno, incluidos los límites de PHP, la disponibilidad del motor y las comprobaciones de procesamiento en segundo plano.
Si deseas ejecutarlo en tu propio sitio, te guío paso a paso en Cómo arreglar una copia de seguridad fallida de WordPress.
¿Cuántos sitios terminaron con configuraciones diferentes?
AutoTune cambió al menos una configuración de copia de seguridad en aproximadamente 9 de cada 10 sesiones de ajuste.
Es una parte sustancial, pero "cambiado" no significa "arreglado una configuración rota".
Un sitio podría haber estado usando configuraciones que completaron copias de seguridad de manera fiable, mientras que AutoTune encontró una opción compatible más rápida. Otro sitio podría haber necesitado una solución alternativa porque su configuración existente no pudo completarse.

Hay varias razones para revisar la configuración de tus copias de seguridad:
- El sitio se ha movido a un servidor diferente.
- Tu proveedor ha cambiado su configuración de PHP o sus límites de recursos.
- Tus archivos o base de datos han crecido.
- Copiastes la configuración de otro sitio.
- Nunca has probado alternativas a la configuración predeterminada.
Los datos no nos dicen cuán comunes son estas situaciones en todos los sitios de WordPress. Sí muestran que ejecutar AutoTune a menudo resultó en un cambio de configuración entre los sitios que lo usaron.
Si tu entorno de alojamiento ha cambiado, volver a probar es más útil que asumir que tu configuración anterior todavía es adecuada.
¿Existe una configuración de copia de seguridad óptima para WordPress?
No existe una combinación que todos los servidores puedan usar.
Algunos proveedores ofrecen herramientas de archivo y base de datos de línea de comandos. Otros restringen esas herramientas pero admiten alternativas basadas en PHP. Los límites de recursos también afectan qué configuraciones pueden completarse.
Aquí es donde aterrizaron las configuraciones exitosas de AutoTune:
| Configuración | Porcentaje de configuraciones exitosas | Lo que tu servidor necesita | Dónde encaja |
|---|---|---|---|
| Shell ZIP con mysqldump | Aproximadamente la mitad | Herramientas ZIP accesibles, funciones de comando PHP habilitadas y acceso a mysqldump | Servidores que permiten sus propias herramientas. Suele ser la combinación más rápida cuando el servidor lo admite. |
| PHP ZIP (con mysqldump o exportación PHP) | Algo menos de 4 de cada 10 | La extensión ZipArchive de PHP | Proveedores que restringen las herramientas de línea de comandos pero tienen ZipArchive habilitado |
| Shell ZIP con la exportación de base de datos PHP | Aproximadamente 1 de cada 20 | Soporte Shell ZIP, sin depender de mysqldump | Servidores que permiten herramientas ZIP pero donde mysqldump no está disponible |
| DupArchive con cualquiera de los métodos de exportación de base de datos | Menos de 1 de cada 10 | Requisitos normales del servidor de Duplicator; no se necesita un ejecutable ZIP externo ni la extensión ZipArchive. | Servidores donde los otros motores no pudieron terminar. Construye la copia de seguridad en pequeñas partes a través de muchas solicitudes. |
Cada una de estas es la respuesta correcta en algún lugar. La pregunta es cuál se adapta a tu servidor.
La configuración más rápida representó aproximadamente la mitad de las configuraciones exitosas
Shell ZIP con mysqldump representó aproximadamente la mitad de las configuraciones exitosas. Incluyendo su par de exportación de bases de datos PHP, Shell ZIP representó un poco más de la mitad.
Shell ZIP utiliza las propias herramientas ZIP del servidor en lugar de construir el archivo completamente a través de PHP. A menudo es más rápido que PHP ZIP cuando el servidor lo soporta.
La opción Shell ZIP de Duplicator requiere las herramientas zip y unzip y las funciones PHP popen() y pclose() habilitadas.
Mysqldump es una herramienta de línea de comandos separada para exportar la base de datos. Duplicator debe poder acceder a ella y ejecutarla.
Cuando esas herramientas están disponibles, pueden ser una combinación eficiente. Cuando no están disponibles o están restringidas, una alternativa basada en PHP puede ser la mejor opción.
PHP ZIP cubre la mayoría del resto
Poco menos de 4 de cada 10 configuraciones exitosas utilizaron PHP ZIP en modo multihilo.
PHP ZIP no depende de ejecutables ZIP externos, pero sí requiere que la extensión ZipArchive de PHP esté instalada y habilitada.
Eso lo convierte en una alternativa útil cuando un host restringe las herramientas de línea de comandos.
Puede combinarse con mysqldump o con la exportación de bases de datos de PHP. La creación del archivo y la exportación de la base de datos son tareas separadas, por lo que tu servidor puede soportar una herramienta de línea de comandos para una pero no para la otra.
DupArchive es la red de seguridad para los servidores más difíciles
DupArchive representó menos de 1 de cada 10 configuraciones exitosas.
Ese pequeño número importa, porque muestra quién lo necesita. Los tamaños de fragmentos más pequeños y la reducción de la carga del servidor aparecieron en solo un puñado de configuraciones exitosas, y la mayoría de ellas utilizaron DupArchive. Estos parecen ser los servidores más limitados en los datos.
DupArchive es el propio formato de archivo de Duplicator. Construye la copia de seguridad en pequeñas partes a través de muchas solicitudes, que es cómo supera los estrictos límites de tiempo que detienen a otros motores a mitad de camino.

En servidores como estos, es lo que permite que una copia de seguridad finalice.
Pero no es la solución predeterminada para cada copia de seguridad lenta. La mayoría de los servidores nunca lo necesitaron.
¿Mysqldump o PHP: qué método de copia de seguridad de base de datos funciona con más frecuencia?
Mysqldump apareció en aproximadamente 2 de cada 3 configuraciones exitosas. La exportación basada en PHP representó aproximadamente 1 de cada 3.
Si mysqldump no está disponible, la exportación de PHP le da a Duplicator otra forma de exportar la base de datos. Todavía depende de los recursos adecuados del servidor, el acceso a la base de datos y los permisos.
¿Qué correcciones comunes fueron generalmente innecesarias?
Tres consejos aparecen en los hilos del foro sobre copias de seguridad lentas o fallidas. Aquí se compara cada uno con las configuraciones exitosas en nuestros datos.
Una cosa a tener en cuenta mientras lees esto. AutoTune se detiene tan pronto como finaliza una copia de seguridad de prueba, por lo que la configuración final muestra lo que una copia de seguridad necesitaba para finalizar en ese servidor, no todas las configuraciones que podrían haber funcionado.
- “Desactivar la compresión.” Casi todas las configuraciones exitosas usaron compresión. Desactivarla rara vez es el cambio que convierte una copia de seguridad fallida en una que funciona. Si su copia de seguridad se está deteniendo, el motor de archivo y los límites de su host son mejores lugares para buscar.
- “Usar siempre DupArchive en alojamiento compartido.” Menos de 1 de cada 10 configuraciones exitosas usaron DupArchive, y la mayoría de los servidores en nuestros datos terminaron en Shell ZIP o PHP ZIP. (No tenemos un desglose por tipo de host, por lo que esto cubre todos los servidores, no solo los compartidos). DupArchive es la opción correcta en los hosts más limitados.
- “Reducir el tamaño del fragmento.” Casi todas las configuraciones exitosas usaron el tamaño de fragmento de 128 MB. Los fragmentos más pequeños solo aparecieron en un pequeño grupo de servidores, y casi siempre junto con DupArchive.
Cada solución funcionó para alguien. En su servidor, es una suposición. Use AutoTune para encontrar la mejor configuración para su sitio.
¿Con qué frecuencia necesitó AutoTune más de un intento?
Aproximadamente 9 de cada 10 sesiones exitosas encontraron una configuración que funcionaba al primer intento.
El 1 de cada 10 restante necesitó al menos una solución alternativa antes de que una copia de seguridad finalizara. Menos de 1 de cada 100 necesitó cuatro o cinco intentos.
¿Qué sucede cuando ninguna configuración de copia de seguridad funciona?
En menos de 1 de cada 20 sesiones de ajuste, AutoTune probó y no pudo encontrar una configuración que se completara en ese servidor.
Esto es lo que detuvo la mayoría de las sesiones y qué soluciones las resolvieron.
Se agotó el límite de tiempo del servidor
Esta fue una de las razones más comunes por las que ninguna configuración pudo finalizar.
Los hosts limitan cuánto tiempo puede ejecutarse un solo proceso de PHP. Si la copia de seguridad no puede dividir su trabajo en pasos lo suficientemente pequeños para encajar bajo ese límite, el host la detiene a mitad de camino, independientemente de lo que digan los ajustes.
La solución está en su host. Pídales que aumenten el límite de tiempo de ejecución de PHP (max_execution_time), o que se cambien a un plan que no lo limite tan estrictamente.
La Vista General del Servidor de AutoTune muestra el límite de tiempo de PHP de su servidor, para que pueda citarlo en su ticket de soporte.
Se llenó el disco
Un disco lleno detuvo algunas sesiones antes de que pudieran finalizar. Contamos esto por separado, porque ninguna configuración de copia de seguridad soluciona un servidor que se ha quedado sin espacio.
La solución es mantenimiento. Elimine copias de seguridad antiguas que ya no necesite, establezca un límite de retención para que no se acumulen de nuevo, y guarde copias fuera del sitio en lugar de en el mismo servidor.
Las copias de seguridad antiguas que llenan silenciosamente un servidor es uno de los patrones que también encontramos en los tickets de soporte de Duplicator, que cubro en Qué Rompe las Copias de Seguridad de WordPress.
La compilación se detuvo en el navegador
Aproximadamente 1 de cada 5 de las sesiones que no encontraron una configuración que funcionara se estaban ejecutando a través del navegador en lugar de en segundo plano.
Eso sucede cuando un host bloquea que un sitio se llame a sí mismo (una "solicitud de loopback"). Duplicator recurre a dirigir la copia de seguridad desde su navegador, lo que significa que solo avanza mientras una página está abierta. Cierre la pestaña, o deje que la sesión expire, y la compilación se detiene.
La solución es una pregunta rápida para su host: pregunte si las solicitudes de loopback están bloqueadas y si pueden permitirlas para su sitio.
¿Qué deberías hacer con tus propias configuraciones de copia de seguridad?
No necesita memorizar estos datos. Úselos como una razón para probar su propio entorno.
Esto es lo que haría a continuación:
- Actualiza Duplicator. AutoTune está disponible en la versión 5.0 y posteriores, en Lite y Pro.
- Ejecuta AutoTune. Deja que pruebe las configuraciones que tu servidor soporta.
- Crea una copia de seguridad normal después. Las pruebas de ajuste no son copias de seguridad restaurables.
- Verifica la recuperación. Confirma que la copia de seguridad normal se completa y, a continuación, prueba una restauración en un entorno de ensayo o de prueba (no en tu sitio web en producción).
- Revisa el almacenamiento y la retención. Mantén suficiente espacio de trabajo local y una copia de recuperación fuera del sitio.
- Configura la automatización. En Duplicator Pro, configura un programa de copias de seguridad y el destino de almacenamiento elegido.
Lleva el informe de AutoTune a tu proveedor de hosting si nada funciona. La sección Resumen del servidor enumera los límites de PHP de tu servidor, lo que convierte una queja vaga en una solicitud específica.
Preguntas Frecuentes (FAQs)
¿Es Shell Zip más rápido que ZipArchive?
Normalmente, cuando tu servidor lo permite. Shell Zip utiliza las propias herramientas de zip del servidor, que tienden a ser más rápidas que comprimir desde PHP. El inconveniente es la disponibilidad. Necesita los paquetes zip y unzip del servidor, además de las funciones popen y pclose de PHP, y muchos hosts compartidos no los proporcionan. Es probable que por eso solo representara poco más de la mitad de las configuraciones exitosas en nuestros datos.
¿Debo usar mysqldump o PHP para hacer una copia de seguridad de mi base de datos de WordPress?
Usa mysqldump si tu servidor lo soporta. Es la propia herramienta de exportación de bases de datos del servidor, y apareció en aproximadamente 2 de cada 3 configuraciones exitosas en nuestros datos. Si tu host no lo permite, la exportación basada en PHP es la alternativa. Se ejecuta desde PHP, por lo que funciona en muchos servidores donde mysqldump no lo hace, siempre que el servidor tenga suficientes recursos y acceso a la base de datos.
¿Desactivar la compresión soluciona una copia de seguridad fallida?
Raramente. Casi todas las configuraciones exitosas en nuestros datos utilizaron compresión. Es uno de los consejos más repetidos en los foros, pero rara vez es lo que separa una copia de seguridad fallida de una que funciona. Comprueba primero el motor de archivo y los límites de tiempo y disco de tu host.
¿Por qué mi servidor no puede usar Shell Zip?
Lo más probable es que tu host no haya instalado los paquetes zip y unzip, o haya deshabilitado las funciones popen y pclose de PHP. Puedes pedirle a tu host que las habilite. Si no lo hacen, PHP ZIP es la alternativa, siempre que tu servidor tenga habilitada la extensión ZipArchive de PHP.
Antes de tu próxima copia de seguridad, deja que tu servidor elija la configuración
Una copia de seguridad que se detiene a mitad de camino te deja sin nada que restaurar, y es posible que no te enteres hasta que la necesites.
AutoTune te ayuda a encontrar una configuración que se complete en tu servidor sin tener que revisar cada ajuste manualmente. Pero la optimización es solo una parte de la planificación de la recuperación.
Después, crea una copia de seguridad, verifica una restauración y configura un programa, una política de retención y un destino fuera del sitio.
AutoTune está en Duplicator 5.0, tanto en la versión gratuita como en la premium. Actualiza tu plugin hoy mismo.
Duplicator Pro mantiene esa configuración de trabajo en funcionamiento según un horario y envía copias fuera del sitio automáticamente. Más de 1,5 millones de profesionales de WordPress utilizan Duplicator para mantener sus sitios recuperables.
Si esta publicación te hizo pensar en tu configuración de copias de seguridad, estas guías merecen ser leídas a continuación:
- ¿Qué rompe las copias de seguridad de WordPress: lecciones de más de 1400 tickets de soporte?
- ¿Qué revelan más de 8.000 tickets de soporte de WordPress sobre por qué fallan las migraciones?
- ¿Cómo solucionar una copia de seguridad fallida de WordPress: configuración frente a límites del servidor?
- Cómo las copias de seguridad de WordPress afectan el rendimiento del sitio (y cómo solucionarlo)
- Cómo hacer una copia de seguridad de un sitio WordPress grande