DB-Backup per Cronjob?

[DreamPromise]

oder den SP bitten diese Funktion zu aktivieren.
Das hatte ich adamals glaub ich auch machen lassen...

DP

[uwe.ha]

hast du denn mal mein Script benutzt?
Ich bin auch bei all-inkl. und hab solche Probleme nicht.

Noch nicht ... dein und deren Script (http://www.all-inkl.com/index.php?sek=a ... dump-email) sind ähnlich.
Aber beide Scripts (laufen als php- und nicht als perl-Script) kommen ab bestimmten DB-Größen ab 200, 300 oder 400 MB in den Bereich rein, wo sie auch durch ein timeout abgebrochen werden.
Und gerade da setzt ja das MANUELLE mySqlDump (MSD) an, dass es eben dieses timeout umgeht.
Allerdings kann all-inkl (zumindest bei eigenen Servern, also nicht bei shared Servern) die Zeit bis zum timeout hochsetzen, so dass es auch bei "größeren" DBs noch problemlos läuft.
... und Dank der neuen Funktion "Automatisches Löschen > seit dem letzten Zugriff" kann ich alle Beiträge, auf die seit 2 (oder3) Jahren nicht mehr zugegriffen wurde (also alles, was die Welt nicht mehr braucht ) automatisch Löschen lassen, wodurch die DB-Größe nicht ins unermessliche wächst und hoffentlich immer unterhalb des timeouts bleibt.

... warum muss alles nur sooo kompliziert sein

[DreamPromise]

Moin moin

wenn man größere Datenbanke hat mag das ja sein.
Meine sind alle höchsten 15 MB

DP

[uwe.ha]

DreamPromise, exec() wird von den meisten Providern aus Sicherheitsgründen deaktiviert. Über die Console (bzw. exec) ist sicher die beste Methode (wenn es denn geht).

Ja, bei mir ist exec auch deaktiviert; zumindest steht im phpbb-ACP:
"disable_functions: exec ..." ... das beudeutet wohl, dass es deaktiviert ist, richtig?

Auch eben hat nochmal der all-inkl-Support gesagt, dass exec zu aktivieren nicht so sicher wäre.

Statt dessen läuft deren script (als Dateiname soll man die Erweiterung *.phpx) wählen, dann wohl (wegen des x) über cgi, was somit angeblich "sicher" wäre.
Und auch in cgi könnte man dann die timeout-Zeit ggf. individuell anpassen.

[uwe.ha]

Hmmm ... das Script funktioniert leider nicht -> timeout-Problem; es werden die (bisher) 170 MB nur ca. zur Hälfte gesichert, danach bricht das Script ab ... schade, wäre mit Cronjob eine schöne automatisierte Lösung

Was mich dabei nur wundert ist, dass die phpbb-eigene Backup-Funktion problemlos funktioniert und kein timeout-Problem hat. Weiß jemand was das "Besondere" am phpbb-Backup ist?

Noch was unverständliches: Wenn ich über phpMyAdmin ein Backup mache (inkl. "Senden") funktioniert es UNkomprimiert problemlos. Wenn ich aber - egel welche - Komprimierung einstelle, sind die Dateien als zip nur 135 Bytes, und als gzip genauso groß wie unkomprimiert und ebenfalls fehlerhaft (von 7-zip als Archiv) nicht lesbar.

Ok, aber wie geht es nun weiter?
Automatisiert (über Cronjob) wird wohl nicht gehen, oder hat noch jemand eine Idee?
Alternativ (wie auch vom all-inkl-Support) angeboten wäre MySqlDumper (MSD) oder HeidiSql. MSD hört man ja öfters und schein auch - im manuellen Betrieb - sehr gute Arbeit zu leisten.
Was ist mit HeidiSql? Kennst das jemand? Wo ist der Unterschied zu MSD?

Danke!
Uwe

[uwe.ha]

Hab gerade nach mysqldumper und heidisql gegoogelt und war fast erschrocken, dass mein letzter Beitrag von gestern Abend (siehe oben) heute Morgen schon bei Google gelistet war ... reife Leistung

Aber zum Thema: Ich habe (auch hier im Forum) mittlerweile gelesen, dass ein Nachteil von HeidiSql wäre, dass es etwas "unsicher" sei, da es ja extern (über meinen lokalen PC) auf die DB zugreift, und das Erlauben externen Zugriffs auf dem Server immer ein Sicherheitsrisiko darstelle.

Andererseits denke ich mir, dass wenn ich MySqlDumper benutze zwar der "externe Zugriff" entfällt, dafür aber MSD selbst ein "Sicherheitsleck" sein könnte.
Also egal ob ich direkten oder indirekten Zugriff auf die DB habe, Risiken bestehen (auch über phpbb selbst) immer.

Also - da ich die verschiedenen Sicherheitsrisiken nicht einschätzen kann: Was ist unsicherer MSD oder Heidisql, bzw. wieVIEL unsicherer ist das eine oder andere?

DANKE!

[planlos.]

mit shell-zugriff gehts auch ganz einfach:

per MachMirBackup.sh über cron
die komplette strucktur des mysql-verzeichnisses in einen backupordner kopieren

Code: Alles auswählen

#! /bin/sh

cp -pr /var/lib/mysql /*path*/Backup/.

exit

das ist sicherlich die einfachste methode, ohne gzip, ohne dump, ohne datem etc.

hat aber den vortel:
hat man ein problem mit einer datenbank oder nur einer(!) tabelle, kann man die datenbank zb. unter einem neuen namen in die bestehende mysql-strucktur packen (rechte richtig setzen) und dann geziehlt eine zerstörte oder fehlerhafte tabelle innerhalb der datenbank ersetzen.
dauert keine 2 minuten.

um ein backup über mehrere wochen mit verschiedenen tageszuständen zu sichern, braucht man nur das ganze verzeichnis durch gzip zu hagen und einen entsprechenden namen mit datum zu vergeben.

gruss planlos

[bantu]

Die wenigsten Hostingprovider bieten Shellzugriff. Damit wäre es natürlich am einfachsten und auch am saubersten.

Als ich Shared Hosting hatte, habe ich den MySQLDumper einfach von Hand benutzt. Dann konnte ich wenigstens sehen, dass das Backup durchgelaufen ist. Bei den meisten Providern ist dann allerdings schon gleich das nächste Problem parat: Bei mehreren/vielen Datenbanken braucht man jeweils eine eigene MySQLDumper-Installation, da die Zugänge jeweils nur für eine Datenbank gelten bzw. MySQLDumper damit (noch) nicht umgehen kann. Zumindest laut meinem Kenntnisstand bzw. als ich ihn zuletzt verwendet habe.

HeidiSQL ist ein MySQL-Client und Software für den Desktop. Das Programm stellt eine direkte Verbindung zum MySQL-Server her, sofern der entsprechende Port geöffnet ist. Bei einigen Hostern ist dieser aus Sicherheitsgründen geschlossen. Bei all-inkl soweit ich weiß nicht. Mit einem MySQL-Client sollten sich auch vernünftige Backups erstellen lassen. Allerdings braucht man dazu zwingend einen Clientrechner.

[uwe.ha]

Hallo,

auch wenn mysqldumper (mittlerweile) wohl mehrere DB's sichern kann (unter Funktionen steht: Multidump - sichern mehrerer Datenbanken nach Konfiguration), habe ich mich für HeidiSQL entschieden, weil es einfach ist und besonders bei meinen beiden großen Datenbanken problemlos funktioniert!

Zum "Sicherheitsrisiko" des Remote-Zugangs hat mir der all-inkl-Support erklärt, dass zwar grundsätzlich JEDER Zugang ein theoretisches Risiko bedeutet, aber dieser Remote-Zugang (wie ihn HeidiSQL oder auch diverse Shopsysteme zum Datenabgleich benötigen) eher unproblematisch ist. WENN Seiten gehackt wurden, dann eher durch Sicherheitslücken in Scripts, als durch Remote.
Remote ist - für mich als Laie - auch nur ein einfacher Zugang zur DB genauso wie ein FTP-Zugang zum Webspace oder ein SMTP-Zugang zum Webspace.

... und letztendlich klingt "Heidi" doch viel symatischer, als "Dumper"

DANKE für euren Imput!

[bantu]

auch wenn mysqldumper (mittlerweile) wohl mehrere DB's sichern kann (unter Funktionen steht: Multidump - sichern mehrerer Datenbanken nach Konfiguration)

Ja, das wird unterstützt. Aber All-inkl hat für jede Datenbank auch neue Zugangsdaten. D.h. es wird pro Benutzer nur eine DB angezeigt. Folglich kann man nur eine sichern.