hab nicht alles gelesen, aber was fuer einen Sinn machen „Backups“, die auf der gleichen Platte liegen?
Wenn ein Kursleiter so doof ist, seinen Kurs leerzuraeumen, dann kriegt er von mir zunaechst erstmal keine Backups zurueckgespielt und wenn die Platte stirb bzw. das Betriebssystem Mist baut, dann ist sowieso alles weg.
Ich schaufel Nachts die Aenderungen per rsnapshot auf einen Server in der Schule, hab aber noch nie(!) irgendwas zurueckspielen muessen.
Ich hab mich schon immer gefragt, was diese naechtlichen Kursbackups bringen sollen, ich brauch die Datenbank und den moodledata-Kram, Rest ist Schall und Rauch.
Schau doch mal wo die fetten Brocken liegen:
ncdu /
Falls das jemand schon alles geschrieben hat, ueberlesen.
Gruss Harry
@liv_uo Das ist jedenfalls ein günstiges Angebot, das einzige was mir da spontan negativ auffällt ist die Traffic-Begrenzung.
Ich hoffe, dass ich meinen Speicherverbrauch durch das manuelle Löschen wieder in den Griff bekomme. Meine Ursprüngliche Backup-Lösung war: mit sqldump die Datenbank auslesen und das Datenverzeichnis mit tar sichern… vielleicht kehre ich dahin zurück.
Die mbz-Daten werden gegenwärtig automatisch auf einen anderen Rechner kopiert…
Ich denke, dass heute Nacht einige GBs frei werden… Wenn das funktioniert werde ich morgen die restlichen Backups löschen. Ich berichte hier.
Wie macht ihr das denn grundsätzlich mit der Archivierung von alten Kursen am Ende eines Schuljahrs? Wir überlegen, dass sich geneigte Kollegen ihre Kurse in einer gesetzten Frist runterladen können und dann wird alles gelöscht.
Das ist ein Auszug meines alten trivialen Scripts, was ich per cron ausgeführt habe
sudo mysqldump -u moodledbuser --password='sehrgeheim' -C -Q -e --create-options moodle > /backup/moodle-database.sql
sudo tar cfvz /backup/moodle-database.tar.gz /backup/moodle-database.sql
sudo tar cfvz /backup/moodlehttp.tar.gz /var/www/html
sudo tar cfvz /backup/moodledata.tar.gz /data/moodledata
und dann schiebe ich die Dateien mit scp auf einen anderen Server.
Und das Wichtigste: man kann mit diesen Daten den Server 100%ig wiederbeleben. Wär ja auch doof, wenn nicht. (u.a. habe ich ihn aus Spaß mal auf einem Raspberri Pi wieder erweckt… das war nicht leicht.)
Das ist clever, Du schiebst automatisch jeden Tag/jede Nacht per scp (zeritikatsbasiert?) drei gzip-Container auf einen externen Server, immer der gleiche Name, keine Generationen.
Wenn es Dir eine Stunde vorher die Datenbank verspult, ueberschreibst Du den noch guten Datenbankcontainer mit einem defekten und mit diesem willst Du den Server dann 100%ig wiederbeleben? Vielleicht hab ich auch was uebersehen, aber das wird schwierig.
Und bekommst Du irgendwie mit, wenn dieser Automatismus mal schief laeuft? Leere Backups ueber reale echte Backups schreibt? Sich drueben der Fingerprint aendert und scp nicht durchlaeuft?
Die Katastrophe hat alle Zeit der Welt.
Es gibt jede Menge Backuploesungen, die mit Hard-Links und Generationen arbeiten, brauchen kaum mehr Platz und sind sicherer.
Schnell nicht, aber hast Du schonmal einen Kurs aus einem Backup zurueckgespielt? Bei mir kam das noch nie vor und wenn das mal so wichtig waere, dann wuerde ich mein Spielzeugmoodle in meiner VM mit den Daten fuettern und den Kurs halt exportieren, waere dann das Disasterrecovery, hatten wir glaube ich letzte Woche in einem anderen Thread schonmal, von wegen: „an untested backup is not a backup“
rsnapshot ist grossartig, obwohl ich da die Versionierung eigentlich auch noch nie gebraucht habe beruhigt trotzdem, dass ein kaputtes Backup lediglich erstmal den letzten Tag ueberschreibt und nicht alles - man koennte also noch nach vorgestern zurueck, falls der Katasrophenfall eintritt.
Ein Problem bei den Hard-Links gibt es allerdings, will man das Ganze nochmal wegkopieren, dann loesen sie sich auf und dann wird’s gross - man sollte also nur bestimmte Generationen wegschaufeln und nicht den ganzen Ordner mit daily.0, daily1…
Ist ja auch alt… und es werden immer zwei Versionen vorgehalten… steht aber nicht im Auszug…
Ich habe den Eindruck, dass die Moodle-Settings nicht das tun, was sie sollen. Habe gestern nur noch einen Backuptag (Sonntag 2A.M.) angegeben und alle Backups (nach vorheriger Sicherung) gelöscht… und heute morgen sind sie alle wieder da… Die Dokumentation ist auch alles andere als optimal.
seit Jahren sichere ich privat und in der Schule alle Daten mit (einem kleinen Skript basierend auf) Rsnapshot. Die Versionierung habe ich schon oft gebraucht („Letzte Woche war die Datei noch da …“).
Die Sicherung eines einzelnen Moodle-Kurses ersetzt das nicht, aber natürlich sehr gut im Zusammenspiel mit den täglichen automatischen Sicherungen.
Und ganz wichtig: Auch wenn man viele Backup-Versionen hat, so liegt jede Datei doch genau einmal vor. Ist die irgendwann im Backup defekt, sind alle „Versionen“ der Datei weg. Auch das ist mir immer mal passiert: Irgendein Sektor auf der Festplatte war nach x Jahren einfach defekt. Ich sichere immer auf 2-3 Medien im Wechsel, so war das nie ein Problem.
Hi zusammen.
Zwei Tipps zu sehr gut funktionierenden Backuplösungen:
Der erste Tipp kommt von Gerd (@gpeter), den er hier vor einiger Zeit mal vorgestellt hatte:
Wir haben mittlerweile eine VM mit BackupPC, in die das Home-Verzeichnis des Servers inkrementell für die letzten 14 Tage gesichert wird. So ist ein direkter Zugriff + Restore von Einzeldateien jederzeit möglich!
Hier mal zwei Screenshots, wie das im Webinterface von BackupPC aussieht:
Und hier sieht man dann den Zugriff auf die Dateiebene – wir haben gleich den ganzen Pfad /srv/samba/schools/default-school/ gewählt. Noch einfacher kann man Einzeldateien, die z.B. versehentlich gelöscht wurden imho nicht so schnell zurückholen…?!
Befolgt von Euch jemand die „2“? Wir hatten vor Jaaaarhen mal einen SCSI-Streamer, der die Backups auf ein Band gelegt hat. Das hat aber ewig gedauert…
ganz viele Plugins gehen fehlerhaft (also anders als vorgesehen) mit dem Cache um. Deshalb die goldene Moodle-Regel: Nach allen Änderungen an irgendwelchen Einstellungen den gesamten Cache löschen! Insbesondere die geplanten Tasks bekommen Änderungen an den Einstellungen oft nicht mir. Ich hatte schon an meinem Verstand gezweifelt, bis ich das Problem durchschaut hatte.