Ich bin Administrator unseres Schulmoodles bei Belwue, Version 1.6.3.
Seit 5. Dezember 2007 werden unsere Kurse nicht mehr automatisch gespeichert, und seit diesem Datum ist auch eine Sicherung aus den Kursen selbst nicht mehr möglich. Es erscheint die Fehlermeldung:
"An error occurred deleting old backup data"
auch wenn es bei neu eingerichteten Kursen gar keine backupdatas gibt.
Über WINSCP habe ich im Ordner moodlebackup auch für den 5.12. die letzten Sicherungen entdeckt.
Wer weiß Hilfe?
Vielen Dank sagt
Holger Springsklee
Hallo,
es ist sicher nicht die Hilfe, die jetzt erwartet wird, aber generell sollte man ja nicht die BackUp-Funktion von moodle nutzen, was ich hier mehrfach im Forum gelesen habe. Ich sichere die gesamte DB generall als MySQL Dump, das klappt bestens, incl. sogar der Daten in moodledata. Und das alles vollautomatisch.
Grüße
Thomas
Hallo,
könntest du bitte mal posten, wie du den Dump samt Sicherung von moodledata vollautomatisch realisiert hast? Das würde mich - und sicher viele andere auch - sehr interessieren.
Schon mal vielen Dank und
viele Grüße
Steffen Auer
könntest du bitte mal posten, wie du den Dump samt Sicherung von moodledata vollautomatisch realisiert hast? Das würde mich - und sicher viele andere auch - sehr interessieren.
Schon mal vielen Dank und
viele Grüße
Steffen Auer
das lässt sich einstellen bei der Konfiguration unter dem Punkt "Datensicherung konfigurieren". Da werden die Wochentage und die Uhrzeit angegeben und bei "Planung aktiv" "ja" angewählt.
Unten muss das Zielverzeichnis auf dem Server angegeben werden.
Aber leider funktioniert das eben nicht so wie gewünscht.
Unten muss das Zielverzeichnis auf dem Server angegeben werden.
Aber leider funktioniert das eben nicht so wie gewünscht.
Also wenn Du Root bist kanste z.B. für alle Datenbanken machen:
mysqldump --all-databases --allow-keywords -p -u $user >/var/backup/backup.sql
backup.sql kannste dann bequem per scp rueberschieben (auch per cron).
Per Script geht das als nutzer auch "--password[=...]". Du kannst auch die eine moodle-Datenbank statt "all-databases" angeben (siehe "man mysqldump") und den kram dann zyklisch per crontab starten lassen.
Die moodledata-Pfade musste aber auch ab uns zu sichern (rcp, rsync usw.).
S.
mysqldump --all-databases --allow-keywords -p -u $user >/var/backup/backup.sql
backup.sql kannste dann bequem per scp rueberschieben (auch per cron).
Per Script geht das als nutzer auch "--password[=...]". Du kannst auch die eine moodle-Datenbank statt "all-databases" angeben (siehe "man mysqldump") und den kram dann zyklisch per crontab starten lassen.
Die moodledata-Pfade musste aber auch ab uns zu sichern (rcp, rsync usw.).
S.
Vielen Dank für den Hinweis.
Inzwischen bin ich auch über das phpmyadmin dan die Datenbank rangekommen. Beim Export ist eine Datei entstanden mit dem Namen localhost.sql mit einer Größe von 311KB.
Das kann doch noch nicht die gesamte Datensicherung sein?
Über weitere Hinweise würde ich mich freuen, denn ich möchte vor Sonntag abend alles gepeichert haben, denn am Montag wird bei Belwue auf Version 1.8 aufgerüstet und mit einer vorherigen Datensicherung ist mir wohler.
Grüße
Holger
Inzwischen bin ich auch über das phpmyadmin dan die Datenbank rangekommen. Beim Export ist eine Datei entstanden mit dem Namen localhost.sql mit einer Größe von 311KB.
Das kann doch noch nicht die gesamte Datensicherung sein?
Über weitere Hinweise würde ich mich freuen, denn ich möchte vor Sonntag abend alles gepeichert haben, denn am Montag wird bei Belwue auf Version 1.8 aufgerüstet und mit einer vorherigen Datensicherung ist mir wohler.
Grüße
Holger
Ich werde das jetzt mal genau beschreiben - so wie es funktioniert und für jeden verständlich sein dürfte - sicher gibt es auch andere Varianten:
Es gibt zwei php-Scripte, die man nutzen kann:
1) MySQLDumper --> selbsterklärend http://www.mysqldumper.de
Mit diesem Programm sichert man die komplette Datenbank. Wie schon bemerkt, kann es passieren, wenn man unter PHPMyAdmin direkt sichert, dass die Datenbank gesichert viel zu klein - weil unvollständig - ist (TimeOut). Vorsicht Datenverlust!!! Das Backup bricht bei großen Datenbanken vorzeitig ab! Die Lösung wie gesagt heißt MySQLDumper! MySQLDumper schickt einem die DB sogar als eMail zu - wenn man will per ftp sogar auf einen anderen Server.
2) phpMyBackupPro ---> selbsterklärend http://www.phpmybackuppro.net/
Dieses Programm macht auch wie 1) ein Backup, aber man kann auch Verzeichnisse packen und zippen, das kann 1) nicht. Also den Ordner moodledata.
Die Programme downloaden, auf den Webspace hoch, im Verzeichnis online meist die install.php aufrufen.
3) Wie geht das nun automatisch? Beide Programme erstellen eine sogenannte cronjob-Datei, die man ja auch braucht, damit eMails in Foren aus Moodle heraus versendet werden.
Cronjob ist ja nichts anderes als eine Datei, die wie eine BATCH-Datei gestartet werden muss und Anweisungen ausführt, d.h. die Backups der Programme 1) und 2) ausführt. Unter www.cronjob.de kann man kostenlos diese cronjob-Dateien starten lassen, man trägt die URL zur Datei dort ein, und wenn man Lust und Laune hat, flattern einem im 5-Minuten-Takt die Backups per eMail ins Haus ;)
Grüße
Thomas
Leider Gottes blick ich' immer moch nicht!
Ich habe jetzt den mysqldumper runtergeladen, die zip-Datei in unserem Moodle auf "Dateien der Website" gelegt, dort entpackt und bin in dem entpackten Ordner auf install.php gegangen. Dann zeigt der mir eine Textdatei, die ich nicht verstehe, und was muss ich jetzt tun?
Ich habe jetzt den mysqldumper runtergeladen, die zip-Datei in unserem Moodle auf "Dateien der Website" gelegt, dort entpackt und bin in dem entpackten Ordner auf install.php gegangen. Dann zeigt der mir eine Textdatei, die ich nicht verstehe, und was muss ich jetzt tun?
Also bei mir zeigt er eine Seite an, wo ich lauter bunte Länderflaggen sehe und mich zunächst für Deutschland entscheiden muss ;)
PS: Sicherung der DB durch Provider selbstverständlich? Also da habe ich wohl bisher immer den falschen Provider gehabt ;(
Hallo,
mySQLDumper kenne und nutze ich bereits, allerdings ist das bei mir im geschützen Bereich (https mit .htaccess), und daher nur nach Useranmeldung erreichbar.
Ebenso befindet sich das /moodledata nicht im per http erreichbarren Berwich unter /htdoc, sondern in einem übergeordneten Verzeichnis.
Gibt es eine Möglichkeit, automatische Backups dennoch anzulegen und per Cronjob zu starten, oder muss ich dazu alle Programme / Verzeichnisse öffentlich zugänglich machen?
Aus Gründen von Datenschutz- und Datei-Sicherheit halte ich es für untragbar, dass Programme wie phpmyadmin oder mysqldumper (trotz möglicher eigener Passwortabfrage) in einem öffentlichen Ordner ungeschützt und für jeden erreichbar sind.
Gleiches gilt für die Ablage von Datenbankdumps oder dem moodledata-Ordner, die gehen niemanden was an, als dass man diese direkt aufrufen können sollte.
Wer kennt dennoch eine Lösungsmöglichkeit für eine automatisierte Sicherung von Datenbank und moodledata?
Gruß
Steffen
mySQLDumper kenne und nutze ich bereits, allerdings ist das bei mir im geschützen Bereich (https mit .htaccess), und daher nur nach Useranmeldung erreichbar.
Ebenso befindet sich das /moodledata nicht im per http erreichbarren Berwich unter /htdoc, sondern in einem übergeordneten Verzeichnis.
Gibt es eine Möglichkeit, automatische Backups dennoch anzulegen und per Cronjob zu starten, oder muss ich dazu alle Programme / Verzeichnisse öffentlich zugänglich machen?
Aus Gründen von Datenschutz- und Datei-Sicherheit halte ich es für untragbar, dass Programme wie phpmyadmin oder mysqldumper (trotz möglicher eigener Passwortabfrage) in einem öffentlichen Ordner ungeschützt und für jeden erreichbar sind.
Gleiches gilt für die Ablage von Datenbankdumps oder dem moodledata-Ordner, die gehen niemanden was an, als dass man diese direkt aufrufen können sollte.
Wer kennt dennoch eine Lösungsmöglichkeit für eine automatisierte Sicherung von Datenbank und moodledata?
Gruß
Steffen
Im Shared-Hostingbereich ist eine derartige Sicherung schwierig zu realisieren, da du immer auf langsame PHP- oder CGI-Scripten angewiesen bist (wobei das mit Perl wahrscheinlich auch als CGI flott läuft). Vorschläge für ein automatisiertes Verhahren mit Hilfe von PHP findest du hier ja im Thread.
Alle aus meiner Sicht wirklich zuverlässigen Methoden basieren auf Shellscripten. Dafür wird ein Shellzugang mit Zugriff auf mysqldump, einige Linuxtools (mv, cp, tar ...) und natürlich ein externer Backupserver benötigt. All das kostet Geld und gibt es nicht für lau oder 9,99 Euro/Monat.
Bequemlichkeit kostet halt.
Gruß,
Maik
Hallo,
also wenn die Ordner per Passwortabfrage erreichbar sind, sind sie nicht öffentlich. Ich nehme an, Du zweifelst an dieser Sicherheit. Sie sind in meinem Fall per .htaccess geschützt - auch eine Passwortabfrage! Aber man kann nicht durch Direkteingabe einer URL auf die Verzeichnisse zugreifen. Die cronjobs (z.B. www.cronjob.de ) können beim Aufruf die Passworteingabe übernehmen, kommen dann also automatisiert in die geschützten Bereiche. Das wäre möglich.
Zitat:
Die cronjobs (z.B. www.cronjob.de ) können beim Aufruf die Passworteingabe übernehmen, kommen dann also automatisiert in die geschützten Bereiche.
Und wie muss dann die URL für den Skriptaufruf beim Cronsjob aussehen, angenommen das Verzeichnis ist
https://domain.de/xyz/mysqldumper/ ?
Gruß
Steffen
Die cronjobs (z.B. www.cronjob.de ) können beim Aufruf die Passworteingabe übernehmen, kommen dann also automatisiert in die geschützten Bereiche.
Und wie muss dann die URL für den Skriptaufruf beim Cronsjob aussehen, angenommen das Verzeichnis ist
https://domain.de/xyz/mysqldumper/ ?
Gruß
Steffen
Hallo,
bei mir funktioniert es so (über www.cronjob.de !)
http://USER:PASSWORT@www.meinedomain.de/mysqldumper/msd_cron/crondump.pl
Die *.pl Datei erzeugt MySQLDumper, die muss dann per Script so wie angegeben aufgerufen werden.
Gruß
Thomas
ICQ 347369305
bei mir funktioniert es so (über www.cronjob.de !)
http://USER:PASSWORT@www.meinedomain.de/mysqldumper/msd_cron/crondump.pl
Die *.pl Datei erzeugt MySQLDumper, die muss dann per Script so wie angegeben aufgerufen werden.
Gruß
Thomas
ICQ 347369305
"http://USER:PASSWORT@www.meinedomain.de/mysqldumper/msd_cron/crondump.pl"
Auch auf die Gefahr hin, dass ich hier bald als Stänkerer und Klugscheißer da stehe - doch ein, zwei Gedanken dazu:
Gruß,
Maik
Auch auf die Gefahr hin, dass ich hier bald als Stänkerer und Klugscheißer da stehe - doch ein, zwei Gedanken dazu:
- Das ist ein HTTP-Request mit Passworten im Klartext. Der steht bei cronjob.de in der Datenbank, im Webserverlog deines Anbieters, in deinem eigenen Webserverlog und außerdem kann das jeder Rechner im Klartext lesen, über den der Request geroutet wird - und nicht jedes Rechenzentrum sperrt jede IP in einem VLAN ein, sodass eine Karte im "promicious mode" in so einem Netzsegment ausreicht. Ich würde Passworte für Operationen, in denen nicht nur meine Daten betroffen sind, stets irgendwie verschlüsselt senden (SSH, SSL, SCP...).
- Der berechtigte Einwand, dass mit diesen Daten niemand etwas anfangen kann, zieht nur insoweit, wenn man nicht an mutwillige Sabotage denkt. Ich kann das Script ja einfach mehrmals in der Sekunde aufrufen und dann geschehen u.U. seltsame Dinge (es wird aber bestimmt ein Lockfile geben...).
Gruß,
Maik
Hallo Maik,
Deine Beiträge sind gut und treffend - dagegen kann man nun mal nichts sagen ;)
Ich würde gern die Passwörter verschlüsseln, ich befürchte, mir fehlen die technischen Möglichkeiten dazu. Leider haben wir in Sachsen auch keine homogene IT-Struktur im öffentlichen Sektor, so wie das bei vielen IT-Bereichen in BW der Fall ist, ich erinnere da mal nur an landeseinheitliche Verfahren Finanzwesen usw.. Schulhomepages, Moodles entstehen in Eigeninitiative engagierter Lehrer oftmals auf privatem Webspace oder zumindest bei preiswerten Massenprovidern. Als Lehrer und Verwaltungswirt weiß ich, dass es leichter ist, eine hohe Einmalsumme als niedrigere fortlaufende Kosten erstattet zu bekommen. Bildung kostet Geld, Sicherheit kostet Geld - aber diese Diskussion an der Basis zu führen, wäre vergeudete Zeit. Unter 80 Lehrern meiner Schule bin ich mit meinem moodle eh Einzelkämpfer.
"Schulhomepages, Moodles entstehen in Eigeninitiative engagierter Lehrer oftmals auf privatem Webspace oder zumindest bei preiswerten Massenprovidern"
Ich bin auch so einer - so'n engagierter Lehrer. Nur dass ich zufällig etwas von Rootservern verstehe und dadurch andere Möglichkeiten habe. Ich finde deine Lösung nach wie vor prakti- und komfortabel.
Ich bin auch so einer - so'n engagierter Lehrer. Nur dass ich zufällig etwas von Rootservern verstehe und dadurch andere Möglichkeiten habe. Ich finde deine Lösung nach wie vor prakti- und komfortabel.
Gruß,
Maik
Sehr interessanter Thread! 
Wie ist es mit den beiden Programmen MySQLDumper und phpMyBackupPro?
Nutzt du beide parallel?
Eigentlich sollte ja letzteres ausreichen, oder?
Wie ist es mit den beiden Programmen MySQLDumper und phpMyBackupPro?
Nutzt du beide parallel?
Eigentlich sollte ja letzteres ausreichen, oder?
Als Antwort auf Holger Springsklee
Re: Alle Kurse lassen sich nicht mehr sichern
von Ralf Hilgenstock -
Im Normalfall erstellen Provider automatische Serversicherungen, inkl. Datenbanken.
Phpmyadmin hat eine Exportfunktion mit der eine einzelne Datenbank gesichert werden kann (Button oben auf der Seite) . Bitte darauf achten, dass alle Tabellen einbezogen werden. Dies enthält jedoch nicht die Dateien des Moodle-Systems und auch nicht den Moodledata-Ordner. Diese kann man auf dem Server packen oder/und auf den PC kopieren.
Phpmyadmin hat eine Exportfunktion mit der eine einzelne Datenbank gesichert werden kann (Button oben auf der Seite) . Bitte darauf achten, dass alle Tabellen einbezogen werden. Dies enthält jedoch nicht die Dateien des Moodle-Systems und auch nicht den Moodledata-Ordner. Diese kann man auf dem Server packen oder/und auf den PC kopieren.
Als Antwort auf Holger Springsklee
Re: Alle Kurse lassen sich nicht mehr sichern
von Ralf Hilgenstock -
Prüfen Sie bitte, ob auf dem Server gezippte Dateien noch entpackt oder Dateien gepackt werden können. Ist u.U. der Pfad zum Zip-Programm in der Administration falsch gesetzt?
Eine andere Ursache könnte ein voller Festplattenbereich sein. Können noch andere Dateien hochgeladen werden?
Eine andere Ursache könnte ein voller Festplattenbereich sein. Können noch andere Dateien hochgeladen werden?
Als Antwort auf Ralf Hilgenstock
Re: Alle Kurse lassen sich nicht mehr sichern
von Holger Springsklee -
Ja ge- und entzippt kann noch werden und Daten hoch- und runterladen geht auch noch. Ein Pfad zum Zip-Programm ist nicht gesetzt, das haben wir bei der Einrichtung am 19.11.2007 auch nicht getan, und bis zum 5.12. hat die Datensicherung ja auch funktioniert.
Vielen Dank für Ihre Hilfe
Vielen Dank für Ihre Hilfe
Als Antwort auf Holger Springsklee
Re: Alle Kurse lassen sich nicht mehr sichern
von Ralf Hilgenstock -
In diesem Fall helfen, die Logdaten weiter, um zu prüfen, warum die Funktion nicht mehr läuft.
U.U. reicht es aus, vor der manuellen Sicherung den Debug-Modus einzuschalten und die Meldungen dort genauer anzusehen.
U.U. reicht es aus, vor der manuellen Sicherung den Debug-Modus einzuschalten und die Meldungen dort genauer anzusehen.
@Holger,
Du musst den mysqldumper lokal entpacken in die entstandenen Dateien dann per FTP auf den Server legen. Innerhalb von /moodledata nützt der i.d.R. nichts, da dort keine Scripten ausgeführt werden dürfen, wenn Moodle korrekt installiert worden ist.
Die dabei gelieferte Datei (*.sql) musst du ebenso speichern, wie den Ordner /moodledata (FTP). Das war es dann schon.
Deine Kurssicherungen laufen deswegen nicht mehr, weil sie zu viele Serverresourcen beanspruchen. Das ist immer dann der Fall, wenn es zu viele oder zu große Kurse sind. Eine Riesendatei reicht bereits aus.
Als Faustregel gilt, dass eine Datei maximal 2/3 der Größe besitzen darf, die in der php.ini als Wert für "memory_limit" konfiguriert ist. Du kannst diesen Wert unter
Website-Administration => Server => PHP-Informationen
einsehen. Dort suchst du mit dem Browser nach dem Wort "memory_limit". Wenn da z.B. steht "66M", dürfen Kursdateien ca. 44MB nicht überschreiten (grob überschlagen).
Archive (ZIP, tar.gz usw.) müssen bedeutend kleiner sein.
@Ralf:
Entgegen aller Annahmen ist es NICHT der Normalfall, dass Provider Backups vorhalten, so wir davon ausgehen, dass "normal" bedeutet: "das was üblich ist".
Wenn man sich einmal die Mühe macht, den abgeschlossenen Vertrag zu studieren (AGB), dann stellt man fest, dass ein Großteil aller deutschen Provider die Kunden selbst durch einen geeigneten Passus dazu in die Pflicht nimmt.
Es ist sehr aufwendig, wirklich verlässliche Backups zu erstellen. Das muss eigentlich auf einem separaten Server, besser auf zweien in verschiedenen RZs geschehen. Das ist aufwendig und teuer.
@Thomas:
Die von dir vorgeschlagenen Tools sind beide sehr gut. Danke vor allem für den zweiten Tipp. Dazu jedoch ein paar Gedanken:
Gruß,
Maik
Du musst den mysqldumper lokal entpacken in die entstandenen Dateien dann per FTP auf den Server legen. Innerhalb von /moodledata nützt der i.d.R. nichts, da dort keine Scripten ausgeführt werden dürfen, wenn Moodle korrekt installiert worden ist.
Die dabei gelieferte Datei (*.sql) musst du ebenso speichern, wie den Ordner /moodledata (FTP). Das war es dann schon.
Deine Kurssicherungen laufen deswegen nicht mehr, weil sie zu viele Serverresourcen beanspruchen. Das ist immer dann der Fall, wenn es zu viele oder zu große Kurse sind. Eine Riesendatei reicht bereits aus.
Als Faustregel gilt, dass eine Datei maximal 2/3 der Größe besitzen darf, die in der php.ini als Wert für "memory_limit" konfiguriert ist. Du kannst diesen Wert unter
Website-Administration => Server => PHP-Informationen
einsehen. Dort suchst du mit dem Browser nach dem Wort "memory_limit". Wenn da z.B. steht "66M", dürfen Kursdateien ca. 44MB nicht überschreiten (grob überschlagen).
Archive (ZIP, tar.gz usw.) müssen bedeutend kleiner sein.
@Ralf:
Entgegen aller Annahmen ist es NICHT der Normalfall, dass Provider Backups vorhalten, so wir davon ausgehen, dass "normal" bedeutet: "das was üblich ist".
Wenn man sich einmal die Mühe macht, den abgeschlossenen Vertrag zu studieren (AGB), dann stellt man fest, dass ein Großteil aller deutschen Provider die Kunden selbst durch einen geeigneten Passus dazu in die Pflicht nimmt.
Es ist sehr aufwendig, wirklich verlässliche Backups zu erstellen. Das muss eigentlich auf einem separaten Server, besser auf zweien in verschiedenen RZs geschehen. Das ist aufwendig und teuer.
@Thomas:
Die von dir vorgeschlagenen Tools sind beide sehr gut. Danke vor allem für den zweiten Tipp. Dazu jedoch ein paar Gedanken:
- Man sollte eigentlich nie aus einem laufenden Datenbankserver heraus sichern. Das tust du aber mit beiden Tools. In 99,8% der Fälle geht das auch gut. Wenn es drauf ankommt, bin ich mit der Methode schon einmal auf die Fr* gefallen (Murphy lässt grüßen...).
- Beide Tools machen kein Backup. Backup bedeutet, dass man die Daten daraus wiederherstellen kann. Das weiß man aber erst, nachdem man sie wiederhergestellt hat. Die Dateien der Tools sind also zunächst nur Datenmüll. Sie werden erst zum Backup durch ein Restore. Viele denken, dass es reicht, derartige Tools einzusetzen. Es reicht nicht. Man muss hin und wieder aus den Backups auch Systeme wiederherstellen und damit das Backup überprüfen.
Gruß,
Maik
Maik, du hast ja so recht! Danke für den Hinweis.
AGB von Strato:
4.5 Der Kunde erstellt Sicherungskopien von allen Daten, die er auf STRATO Server überspielt, auf anderen Datenträgern, die nicht bei STRATO liegen. Im Fall eines Datenverlustes wird der Kunde die betreffenden Datenbestände nochmals unentgeltlich auf den Server der STRATO übertragen.
ABG von 1&1 Webhosting:
Der Kunde wird darauf hingewiesen, dass es ihm obliegt, nach jedem Arbeitstag, an dem der Datenbestand durch ihn bzw. seine Erfüllungs- oder Verrichtungsgehilfen verändert wurde, eine Datensicherung durchzuführen, wobei Daten, die auf den Servern von 1&1 abgelegt sind, nicht auf diesen sicherungsgespeichert werden dürfen. Der Kunde hat eine vollständige Datensicherung insbesondere vor jedem Beginn von Arbeiten von 1&1 oder vor der Installation von gelieferter Hard- oder Software durchzuführen. Der Kunde testet im übrigen gründlich jedes Programm auf Mangelfreiheit und Verwendbarkeit in seiner konkreten Situation, bevor er mit der operativen Nutzung des Programms beginnt. Dies gilt auch für Programme, die er im Rahmen der Gewährleistung und der Pflege von 1&1 erhält. Der Kunde wird ausdrücklich darauf hingewiesen, dass bereits geringfügige Veränderungen an der Software die Lauffähigkeit des gesamten Systems beeinflussen kann.
AGB von 1blu.de:
3.5 Der Kunde ist verpflichtet, Sicherungskopien von allen Daten, die er auf den ihm bei 1blu zur Verfügung stehenden Speicherplatz überträgt zu erstellen (Sicherungskopien). Diese Sicherungskopien wird der Kunde auf Datenträgern sichern, die nicht physikalisch bei 1blu liegen.
Schau an, schau an. Da war ich doch etwas verwöhnt von einem Provider mit dem ich gerne zusammenarbeite, der selbstverständlich tägliche Sicherungen komplett und DB macht und 2(!) Versionen aufbewahrt.
Und dann ist dies bei uns im Moodle-Hosting eine Selbstverständlichkeit. http://eledia.de
AGB von Strato:
4.5 Der Kunde erstellt Sicherungskopien von allen Daten, die er auf STRATO Server überspielt, auf anderen Datenträgern, die nicht bei STRATO liegen. Im Fall eines Datenverlustes wird der Kunde die betreffenden Datenbestände nochmals unentgeltlich auf den Server der STRATO übertragen.
ABG von 1&1 Webhosting:
Der Kunde wird darauf hingewiesen, dass es ihm obliegt, nach jedem Arbeitstag, an dem der Datenbestand durch ihn bzw. seine Erfüllungs- oder Verrichtungsgehilfen verändert wurde, eine Datensicherung durchzuführen, wobei Daten, die auf den Servern von 1&1 abgelegt sind, nicht auf diesen sicherungsgespeichert werden dürfen. Der Kunde hat eine vollständige Datensicherung insbesondere vor jedem Beginn von Arbeiten von 1&1 oder vor der Installation von gelieferter Hard- oder Software durchzuführen. Der Kunde testet im übrigen gründlich jedes Programm auf Mangelfreiheit und Verwendbarkeit in seiner konkreten Situation, bevor er mit der operativen Nutzung des Programms beginnt. Dies gilt auch für Programme, die er im Rahmen der Gewährleistung und der Pflege von 1&1 erhält. Der Kunde wird ausdrücklich darauf hingewiesen, dass bereits geringfügige Veränderungen an der Software die Lauffähigkeit des gesamten Systems beeinflussen kann.
AGB von 1blu.de:
3.5 Der Kunde ist verpflichtet, Sicherungskopien von allen Daten, die er auf den ihm bei 1blu zur Verfügung stehenden Speicherplatz überträgt zu erstellen (Sicherungskopien). Diese Sicherungskopien wird der Kunde auf Datenträgern sichern, die nicht physikalisch bei 1blu liegen.
Schau an, schau an. Da war ich doch etwas verwöhnt von einem Provider mit dem ich gerne zusammenarbeite, der selbstverständlich tägliche Sicherungen komplett und DB macht und 2(!) Versionen aufbewahrt.
Und dann ist dies bei uns im Moodle-Hosting eine Selbstverständlichkeit. http://eledia.de
Hallo Ralf,
Gruß,
Maik
Ich bin Lehrer. Es ist mein Beruf Recht zu haben 
! (zumindest vormittags). Die LIste der Provider ließe sich noch fast beliebig fortsetzen...
In Deutschland zählt leider zu allererst der Preis. Und das erstaunlicherweise schichtübergreifend und dann auch noch bei Dauerschuldverhältnissen, bei denen man Veträge eigentlich vor Abschluss lesen MUSS, da man an dem MIst 1-2 Jahre zahlt (vgl. DSL-, Handyverträge usw.).
! (zumindest vormittags). Die LIste der Provider ließe sich noch fast beliebig fortsetzen...In Deutschland zählt leider zu allererst der Preis. Und das erstaunlicherweise schichtübergreifend und dann auch noch bei Dauerschuldverhältnissen, bei denen man Veträge eigentlich vor Abschluss lesen MUSS, da man an dem MIst 1-2 Jahre zahlt (vgl. DSL-, Handyverträge usw.).
Gruß,
Maik
Hallo,
wenn man Murphy mit ins Spiel bringt, dann lassen sich wohl auch Hochsicherheitsrechenzentren nicht ausschließen. Die Frage ist, was verhältnismäßig ist, also erforderlich, angemessen und geeignet. Es klingt mir eher philosophisch, wenn "... Backupfiles erst zum Backup werden, wenn daraus ein Restore funktioniert ...". Natürlich KANN es es passieren, dass Backupfiles wertlos sind, wenn man sie nicht gelegentlich testet. Ich lasse mir täglich die sql-Dateien per eMail senden und stelle täglich mein System wieder neu her damit - für mein "Moodle auf dem USB-Stick". Ich habe 7 Backups je Woche, von Datenmüll kann ich da nicht sprechen. Wer natürlich ein Backup im Monat herstellt und sich sicher fühlt - zugegeben, ein Trugschluss. Ich stimme auch der Problematik zu, die Sicherung von einem laufenden System sei problematisch. Doch würde es mein Provider anders tun??? Inzwischen sichert man ja auch schon seinen heimischen PC im laufenden Betrieb - und stellt ihn auch so wieder her. Vielleicht werden die Sicherungssysteme auch besser ;)
Grüße
Thomas
Nenn' mich paranoid - das trifft es. Ich hatte einmal den Fall:
- Anbieter pleite => Server weg
- USB-Stick mit Sicherung drauf - bisher immer tadellos funktioniert - defekte Sektoren
- Dateisystem kopiert und war zu retten (puh!)
- Dump war dann unvollständig - wertlos...
Es kommt immer am dicksten, wenn es am dringendsten ist. Und: Der cronjob von Moodle ist das Letzte, auf das ich mich verlassen würde. Irgendwann ist Scriptlaufzeit zu klein für die Größe der Datenbank oder Kollege x hat ein Monsterarchiv hochgeladen, worauf ulimit deinen PHP-Prozess abknallt - dann nützt auch ein Reload nix - und dann stehst du da...
Ein Backup ist ein Backup, wenn ein Restore möglich ist hat nichts mit Philosophie zu tun. Der Satz ist genauso wahr wie dieser hier:
"Das, was du suchst, findest du immer da, wo du zuletzt nachschaust." (auch ein Murphy...)
Gruß,
Maik
Ein Backup ist ein Backup, wenn ein Restore möglich ist hat nichts mit Philosophie zu tun. Der Satz ist genauso wahr wie dieser hier:
"Das, was du suchst, findest du immer da, wo du zuletzt nachschaust." (auch ein Murphy...)
Gruß,
Maik
Na ich gebe Dir schon Recht. Natürlich lege ich meine Backups auf sichereren Medien ab, als es ein USB-Stick wäre, nämlich DVD-RAM. Vielleicht bin ich dann doch mehr paranoid als Du ;)
Der Cronjob von Moodle - wie kommst du da jetzt drauf - auf den verlasse ich mich natürlich auch nicht. Und die von mir vorgeschlagene Software bricht bei keiner großen Datenbank ab. Das ist ja gerade der Grund, warum ich sie einsetze.
PS: Beim nächsten Suchen werde ich hoffentlich schneller fündig.
In diesem Sinne - hellau und noch einen schönen Abend.
Gruß
Thomas