Da verwurstet moodle.org seine Zeit damit, für mobile Endgeräte eine automatische Erkennung zu basteln, damit diesen gesonderte Themes angeboten werden können, aber das wirklich kritische Problem, dass Moodle einem jede Nacht mitteilt, das Backup sei ohne Fehler durchgelaufen während nichts (im Sinne von gar nichts) gesichert wurde … darum kümmern sie sich nicht. Moodle kotzt mich gerade an.
Sachlicher ausgedrückt: Meine Backupprobleme bleiben auch bei Moodle 2.1 bestehen. Das ist ein Blocker! Wer kann, sollte bei Moodle 1.9.x bleiben.
(C) CDWaldi sxc
Veränderungen in einem TrueCrypt Container gehen in den Grundeinstellungen von TrueCrypt nahtlos an der mtime der Datei vorbei. Dies führt dazu, dass die Container nicht von Programmen wie BackinTime oder anderen auf rsync basierenden Backuplösungen gesichert werden. Mit den folgenden Einstellungen klappt es dann doch:
In den Einstellungen den Haken bei “Preserver modification timestamp of file containers” entfernen und
einen Haken bei “Do not use kernel cryptographic services” setzen, damit die vorher getroffene Einstellung wirksam werden kann.
Jeden Tag schickt mir mein Moodle brav eine Mail, in der steht, dass alle Kurse erfolgreich gesichert worden seien:
Beschreibung
==================================================
Kurse: 178
OK: 178
Übersprungen: 0
Fehler: 0
Noch nicht abgeschlossen: 0Sicherung erfolgreich abgeschlossen
Leider eine glatte Lüge. Das dumme Ding sichert überhaupt nicht, sondern wirft nur mit Fehlermeldungen um sich, die es dann aber nicht verschickt, sondern nach
/moodledata/temp/backup
wirft, damit auch ja niemand drauf kommt, dass überhaupt was schief geht.
In diesem Verzeichnis finden sich nun aberhunderte von Logs mit dem schlichten Inhalt
[warn] backup_auto_failed_on_course coursename
und das für jeden Kursraum. Ergo: Mal wieder einen Bugreport losgetreten.
Die Grundeinstellungen von Moodle2 erlauben es einem Trainer (editingteacher) nicht, dass dieser Nutzerdaten sichert, was dazu führt, dass in den exportierten Kursräumen immer nur Teile des Raumes enthalten sind … was dann wiederum dazu führt, dass der Administrator der Moodle2-Installation das leidige Backupgeschäft nicht an die Trainer in den Kursräumen delegieren kann.
Es reicht leider nicht, als Administrator die Backupeinstellungen vernünftig zu wählen – z.B. wie im Bild oben – so dass diese dem Datenschutz ja durchaus gerecht werden, weil ein Export von Nutzerdaten nur anonymisiert möglich ist und der Export von Logdaten überhaupt nicht. Die Trainerrolle selbst muss angepasst werden.
Dazu als Administrator an der Moodle2-Installation anmelden und im Bereich /Website-Administration /Nutzer/innen /Rechte /Rollen verwalten auf den Eintrag für die Trainer klicken.
Im Bereich “Kurs” sind auf dieser Einstellungsseite zwei Checkboxen auf “Erlauben” zu setzen – was in Kombination mit den globalen Einstellungen für die Kursraumsicherung dazu führt, dass nun der komplette Kursraum vom Trainer gesichert werden kann, ohne dass der Datenschutz über die Wupper geht.
Die Nutzerdateien können nun Teil des Kursraumexportes sein und dieser ist damit so umfänglich sicherbar, dass eine Delegation des Backupgeschäftes und vor allem der Backupverantwortung an Trainer OK erscheint.
Meinen Bug-report hab ich einstampfen dürfen.
(C) forwardcom @ sxc
Da meine Moodle 2 Installationen im Moment noch nicht vollständig in backup2l integriert werden können, darf ich die Kursräume händisch sichern. Das nervt, wenn man das nicht automatisieren kann.
Auf dem Server schreibt das in Moodle 2 integrierte Backup die Kursräume jede Nacht in das Verzeichnis
/server/dir/mdlbckp/
Aus diesem Verzeichnis sollen dann die Kursraumbackups (im Moodle 2 üblichen mbz Format) auf die lokale Platte in das Verzeichnis
/localpath/bckp_tagmonatjahr/dir1
wandern, wobei dieses Verzeichnis einen “Datumsstempel” im Pfadnamen tragen soll.
Ich hab das mal so gelöst:
#!/bin/bash
# Datum in Variable schreiben
d=$(date +%d%m%Y)
# Lokales Verzeichnis mit Zeitstempel anlegen
mkdir -p /localpath/bckp_$d/dir1
# Moodle Kursraumbackups vom Server holen
scp -r user@server.de:/server/dir/mdlbckp/* /localpath/bckp_$d/dir1
Für jedes zu sichernde Moodle 2 auf dem Server wird das Skript dann um einen mkdir -p Aufruf und den entsprechenden scp -r Befehl ergänzt.
Wenn scp Dank public key Verfahren auf den Server zugreifen darf, dann ist das Skriptchen – über einen cronjob aufgerufen – nun wenigstens ein workaround.
Eigentlich dumpe ich jede Nacht alle Datenbanken auf dem Server und verpacke diese zusammen mit den Webserververzeichnissen in Archive – bzw. backup2l macht das für mich. Diese Archivdateien rsynce ich am frühen Morgen auf meine lokale Platte bzw. auf meinen Backupserver in der Schule.
Jahrelang ging das glatt. Moodle 1.x.y legte brav nur die Dateien in die Unterverzeichnisse von /moodledata, die von den Nutzern hochgeladen wurden. Moodle 2 benimmt sich komplett anders – wie, genau, weiß ich noch nicht. Da komm ich gerade erst dahinter. Auf jeden Fall fressen die frisch installierten Moodle 2 langsam den Plattenplatz auf dem Server und auf den Backupservern auf, weil sich jede Nacht gleich pfundweise Dateien und Verzeichnisse innerhalb von /moodledata verändern und so die Archive aufblähen.
Nachdem in den Foren auf moodle.org zu dem geschilderten Problem keine Reaktion kam, trug ich einen bug report ein. Jetzt kommt Bewegung in die Sache … aber eine saubere Lösung steht wohl noch für einige Zeit aus.
Im Moment packt backup2l nur noch die WordPresse und DokuWikis sowie die Moodle 1.9.x Installation – nicht aber Verzeichnisse, die ein Moodle 2 enthalten – ein. Moodle 2 Backups gibt es nur noch ein paar mal im Monat – und da dann lediglich von den von Moodle 2 selbst angelegten Kursraumbackups.
Was für ein Gewürge.
