El problema es el siguiente, al hacer backups del phpbb 3 tanto desde panel de control del CMS como desde el phpmyadmin, estos salen de distinto tamaño, yo "acepto" que el backup está ok cuando es igual o mayor a 6,4 MB en formato gzip , el tema es que ayer y hoy al hacer copia de seguridad navideña, (uno nunca sabe si con esto de los indignados a santa claus le da por hackear foros ) estos no alcanzan nunca ese tamaño y no hay menos contenido en el foro, (usuarios, mensajes, temas, todo está igual) .

Alguna idea de que puede estar pasando, en general entiendo que siempre es más seguro hacer el backup desde el phpmyadmin por lo que me gustaría me orientaran pensando en ello.

Otro dato el CMS dice que la base de datos tiene un tamaño de 52.5 MiB

Gracias

Ya estoy rumbeando a dormir, mañana intentaré hacer alguna prueba desde el phpMyAdmin.

Fíjate si tienes alguna restricción en tamaño:

- configuración de tamaño de RAM para Php.

- configuración de tamaño de archivo del servidor web

datos que obtienes desde PhpInfo.

y eso está en ?

gracias

Es una función de PHP.

Crea un fichero .php y pon esto:

<?php
phpinfo();
?>

lo sospeché desde un principio

Va la captura

Pareces el Chavo del 8.... (perdon, imaginé que conocías del asunto).

Hice una prueba con el PhpMyAdmin pero no tengo ninguna base de datos de semejante tamaño. No experimente ningun problema.

Aprovecho para agregar otras variables que pueden estar afectando el proceso, son estas, el buscador del browser las detecta fácilmente (CTRL+F):

en PHP Core:

max_execution_time (el backup se debe terminar de ejecutar antes de este límite)
memory_limit (límite de la memoria para Php+datos)
post_max_size (tamaño máximo de cada archivo de backup en disco)

en mysql:

mysql.connect_timeout (tiempo límite para que se ejecute el proceso de backup)

En definitiva, lo que debes buscar es que:

- post_max_size: debe ser mayor que cada archivo de backup.

- max_execution_time, mysql.connect_timeout: (el menor) debe ser mayor que el tiempo necesario para crear el backup.

- memory_limit: debe ser mayor que el tamaño del mayor archivo más el script (esta va algo difícil) porque puede que el script esté manejando los niveles de error de Php o bien truncar la operación antes que lanze un error y plante la ejecución.

entiendo muchas cosas, mas se muy pocas

Revisaré eso que dices y les cuento .

Estos es lo que dices que busque , pero no entiendo nada ...

gracias

Estas imágenes son mas chicas que la anterior y leer es rápido.

Las 2 variables de configuración que más comprometen al backup son:

- max_execution_time (otorga 30 segundos), puede resultar poco.

- memory_limit (tienes 70MBytes), esta -en principio- parece la más holgada pero -en este caso- no lo es. Tu esperas un backup comprimido (gzip) de algo más de 6 MBytes, pero eso se logra luego de comprimir (aproximadamente) unos 60 o 70 MBytes (asumiendo que la tasa de compresión llega a un 10% del descomprimido); así que 'opino' que es la que más afecta: 60 o 70 MB de datos + 6.xxx de comprimidos + espacio del script y variables que necesita el script: script crash.

Intenta detectar la(s) tabla con mayor espacio (en PhpMyAdmin selecciona tabla->apartado 'Espacio utilizado'-> Total) y hazles backup individual (al resto las agrupas a conveniencia).

Me quieres decir que 6,4 MB es mucho para el mysql? que dirías si el backup antes de hacer el cambio de versión pesaba más de 100 MB ? que pesaba eso...

La solución , por lo que veo pasa entonces por hacer respaldos por grupo de tablas

Gracias

Así es, esta suma (no es sólo 6 MB de comprimidos, sino todo lo demás que el script debe tener en memoria supera la capacidad de RAM puesta a disposición).

Divide y vencerás.

PD: quizás en versiones anteriores para que el sctipt pueda manejar 100 Mb descargaba (liberaba) memoria con cada tabla, o cada tantos registros... pero es solo suposición.

PD2: amplío, los 6MB no son mucho para MySql, todo ese cálculo es sobre lo que tiene permitido manejar Php.