Textdateien kann man nicht entpacken, jedenfalls ich nicht… 
Meine Dateien haben korrekt die Endung “.sql.gz” und sind, wie schon von Jogi beschrieben, genau so erstellt worden. Der Unterschied liegt nur im Ergebnis… 
Moin,
[quote=“White-Tiger”]also auf meinem Server genau wie hier waren die GZip dateien .sql (text dateien) die nur die endung .gz hatten.
Sprichst du auch von PHPMyAdmin auf bplaced bzw. allgemein[/quote]
Es geht um phpmyadmin auf bplaced vorinstalliert (über das Userpaneel oder direkt aufgerufen),
um Datenbank-Dumps die unter der Option “gepackt mir GZIP” gesichert werden.
bei mir (bei Interceptor aber nicht) sind sie genauso groß sind wie unge-gzip-t.
Es geht darum, daß sie dann lokal als defekt gemeldet werden.
miro hat auch Recht, wenn man die Endung “.gz” entfernt, stellen sie sich als ungepackte, aber vollständige Dumps heraus.
Fehlermeldungen sind keine enthalten, nur das Dump selber.
Die zu kleinen Backups die Interceptor erhält können nicht vollständig sein,
das Problem hatte ich auch und zwar direkt vor dem Problem das gz nicht gzip-gepackt sondern ungepackt ist.
Es fehlten dann darin einfach eine unbestimmte Zahl an Tabellen, so als ob das Dump vor dem Ende abgebrochen wurde.
Vollständiger kann man´s kaum zusammenfassen
[quote=“jogi”]
um Datenbank-Dumps die unter der Option “gepackt mir GZIP” gesichert werden.
bei mir (bei Interceptor aber nicht) sind sie genauso groß sind wie unge-gzip-t.[/quote]
Jetzt habe ich das Problem seit vorgestern auch, daß die Datei als gzip genauso groß ist wie ohne Kompression. Das ist ja merkwürdig… 
Moin,
ja stimmt, das Problem, daß gzip in phpmyadmin nicht komprimiert obwohl es die Endung “gz” anhängt, besteht nach wie vor.
mit gzip und mysqladmin scheinen nicht nur hier (bei bplaced) probleme aufzutreten.
auf meinem paidwebspace kann ich die gezippten backups z.b. nur mit rar korrekt öffnen, mit anderen packern wird fehlerhaft entpackt, eine erklärung dafür hat mir dafür bis heute niemand geben können.
andererseits sind meine datenbanken dort so gross, dass ich schon vor längerer zeit probleme mit dem timeout bekommen habe (beim wiedereinspielen) und deswegen seit jahren entweder bigdump oder mysqldumper benutze.
Um von mir aus nochmal aufmerksam zu machen,
bzw. zu Fragen:
Das ganze hier lief ja nun in phpMyAdmin ab.
Wäre es mit dem MySQL Dumper in dieser Situation nicht viel einfacher?
Bei dem waren meine Backups noch nie Fehlerhaft.
Gzip geht dort auch (die nehm ich sogar immer) und ansich bietet der Dumper sogar mehrere und bessere Funktionen noch, als ein manuelles Backup über phpMyAdmin…
Wenn du den Dumper dann per htaccess schützt kann dort eigentlich nichts passieren und ich denke das ist hier kein Problem einfach den Dumper zu nehmen.
phpMyAdmin habe ich noch nie für Backups genommen.
Liebe Grüße
Jan
Hi Jan,
sicherlich wäre es kein Problem, den Dumper zu nehmen. Aber das würde ja nichts dran ändern, daß es hier in phpMyAdmin wohl einen Fehler zu geben scheint. Und es ist ja Sinn der Sache, diesen Fehler zu finden und zu beheben.
Dabei meine ich nicht mal unbedingt, daß im Moment gzip nicht komprimiert (vorher funktionierte es ja), sondern daß bei gzip in komprimierter Form die DB 1,6MB hat, wenn sie korrekt erstellt wurde, und manchmal nur ca. 900KB. Wo ist da der Fehler?
