Schlagwort-Archive: backup

Duplicity auf Ubuntu 12.04 LTS

Um es kurz zu machen: Ein Backup mit duplicity über SCP von einem 12.04 LTS Server auf einen 14.04 LTS Backupserver funktioniert nicht mit der Version, die in den Ubuntu-Repos für 12.04 LTS steckt. Das als default verwendete Backend python-paramiko will nicht kooperieren und ein Update desselben über PPAs wollte mir nicht gelingen, weil ich in eine infernalische Abhängigkeitshölle geriet. Was dann half war ein Update von duplicity selbst auf Version 0.6.23 was über das folgende PPA möglich ist:

https://launchpad.net/~duplicity-team/+archive/ppa

In der dort angebotenen duplicity Version ließ sich paramiko als Backend ersetzen durch pexpect. Der Aufruf von duplicity kann dann in einem Skript so aussehen:

export PASSPHRASE=geheim

/usr/bin/duplicity remove-older-than 7D –ssh-options „-oIdentityFile=/pfad/zum/.ssh/identity-file“ –ssh-backend pexpect scp://benutzer@server.tld/backup >> /var/log/duplicity/backup.log

/usr/bin/duplicity –ssh-options „-oIdentityFile=/pfad/zum/.ssh/identity-file“ –ssh-backend pexpect /home scp://benutzer@server.tld/backup >> /var/log/duplicity/backup.log

unset PASSPHRASE

Diese Unpässlichkeit scheint neueren Datums zu sein.

Hoffnungsschimmer

Es besteht wieder Hoffnung: Der neueste Moodle 2 Build erstellt doch tatsächlich auch Backups. Daran war auf Grund meiner bisherigen Erfahrungen [1, 2] zu zweifeln gewesen. Noch werde ich meinen Bugreport nicht auf gelöst setzen – erst in ein paar Tagen.

Moodle Backupproblem ungelöst

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.

Truecrypt Zeitstempel

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.

Moodle 2 Backup kaputt

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: 0

Sicherung 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.

Moodle 2 Backupeinstellungen

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.

Dumbobackup

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.

Moodle frisst Server

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.