Wiederherstellen in eine andere Datenbank?

**uses MSD regulary** Joined: 31 Jul 2010 Posts: 15

Leider eben nicht :-( ich besitze nur das Hosting Paket "Homepage Premium" und keinen root server (oder Managed Server wie es bei goneo heißt):
http://www.goneo.de/hosting/hosting.html

Allerdins habe ich noch dieses Topic gefunden:
http://forum.mysqldumper.de/perl-module-selber-installieren-t1224.html

Hier wird beschrieben die Zlib ins eigene Webverzeichnis zu instlalieren (z.B. cgi-bin). Würde das denn überhaupt mit meinen rechten funktionieren?

mir gehören unter meinem Uservezeichnis die folgenden Ordner:

cgi-bin (hier liegen die .pl Dateien des Dumpers)
htdocs (ist selbsterklärend)
logfiles (access logfiles des Servers)

könnte ich das zlib sowie das MIME Modul in den cgi-bin Ordner installieren oder brauche ich trotzdem root, da es eine installation über die shell ist?

zur Info: mit dem Hosting Paket "Homepage Premium" steht mir Shell zugang sowie die ausführung von eigenen CGI Skripten zur Verfügung.

Posted: 2010-08-04, 07:38 (No subject)

Laut der Übersicht des Pakets hast Du Shell-Zugang. Damit sollte die Installation möglich sein.

Da es sich hier aber um Server-Administration handelt und dies nicht mehr das Thema dieses Forums ist, können wir Dir dort nicht weiter behilflich sein. Alle benötigten Anhaltspunkte hast Du jetzt hier bekommen.

**uses MSD regulary** Joined: 31 Jul 2010 Posts: 15

Hallo,

der Hoster hat sich endlich erweicht und die Zlib sowie MIME installiert:

Posted: 2010-08-10, 11:29 (No subject)

Das Perl-Backup ist nicht komplett.
Im Protokoll muss am Ende #EOS (End of Script) stehen ... tut es das nicht, wurde das Script vorher abgebrochen.

Das liegt daran, dass der Dumper per PHP zwar das Zeitlimit umgehen kann, das für Perl aber nicht funktioniert.
Entweder, der Hoster erhöht das Ausführungszeitlimit für Perl-Scripte, oder Du kannst nur per PHP Dumpen (und damit leider auch keinen Cronjob verwenden).

**uses MSD regulary** Joined: 31 Jul 2010 Posts: 15

Mich hat es auch gewundert warum er danach aufhört.. wenn ich aber unter der Backupverwaltung sehe, dann scheint es aber trotzdem zu stimmen:

Script Datum Multipart Tabellen / Einträge Dateigröße
perl(1.24) 10.08.2010 05:04 2 Files 162 / 1.535.911 5.90 MB
php(1.24) 03.08.2010 18:01 4 Files 162 / 1.468.909 10.18 MB

Er hat alle Einträge (die 162 Tabellen mit den Einträgen) erfasst... Die geringere Größe denk ich mal liegt am Perl Skript.. DSB meinte in einem anderen Topic dass das Perl skript besser packen kann als PHP und die größe deswegen variiert. Trifft es hier auch zu oder verwechsle ich da was?

Posted: 2010-08-10, 13:41 (No subject)

Die Anzahl der Tabellen und Datensätze wird zu Beginn des Backups ermittelt (SHOW TABLE STATUS from 'xxx'). Diese Werte werden für die Anzeige in der Verwaltung der Backup-Dateien verwendet. Das hat im Grunde nicht viel mit den wirklich enthaltenen Datensätzen zu tun, denn rein theoretisch könnte ja z.B. auch noch ein weiterer Datensatz in die letzte Tabelle eingefügt werden, während das Backup schon läuft. Der Satz würde dann mit gesichert werden, würde aber in der Anzeige der gesicherten Sätze fehlen.

Wirklich sicher sein, dass das Perl-Backup vollständig ist, kann man sich erst, wenn im Log das #EOS steht.

Ein gutes Indiz dafür, dass das Script abgebrochen wurde, ist der Nicht-Versand der Email.
Denn die Mail kann natürlich erst dann versendet werden, wenn das Backup vollständig ist.

**uses MSD regulary** Joined: 31 Jul 2010 Posts: 15

Du hast recht Jens!
Ich habe jetzt mal versucht die gesicherten Tabellen aus dem Perl Skripts zu restoren:

Multipart-Backup: konnte Datei nicht finden 'db1_1_2010_08_10_05_04_part_3.sql.gz' !

Somit liegt es wirklich an der Laufzeit :-( Wie lange muss die Ausführungszeit für Perl Skripte denn ungefähr betragen? Ich habe jetzt dem Hoster gebeten die Laufzeit zu verlängern.. wenn ich eine genauere Zeit wüsste, könnte ich den Hoster nochmal informieren..

Danke!!

Posted: 2010-08-10, 15:18 (No subject)

Das ist wie mit dem Hubraum bei Autos: mehr ist besser!

Für 1,5 Mio. Datensätze braucht ein Script schon recht lange, um diese auszulesen.
Wenn Dein Hoster Dir den Gefallen tut, soll er das Limit so hoch setzen, wie er es vertreten kann.
Viele Hoster machen das aus Gründen der Fairness nicht, da sie beim shared Hosting sonst nicht eine gewisse Performance für alle User auf dem Server garantieren können.

Wenn Du einen eigenen Server hast, der nur vom Hoster gemanaged wird, dann lass das Limit auf 6000 Sekunden oder etwas adäquates setzen. Dann bist Du selbst für die Performance Deines Servers zuständig und darfst Dich nicht beschweren, wenn während eines Perl-Backups nichts anderes mehr geht.