Dateien in Gigabyte-Größe füllen das Verzeichnis /var/univention-backup und bringen das Dateisystem zum Überlaufen. Wie kann ich das besser bzw. richtig steuern?
lsof zeigt mir einen bzip2-Prozess, der fleißig diese Datei schreibt.
Hat das etwas mit der sysvol-Replikation zu tun? Im Moment würde ich mir mit einem cron-Job helfen, der die älteren bz2-Archive löscht, aber das ist doch sicher nicht im Sinne des Erfinders, oder?
Das scheint neu zu sein seit meinem Upgrade. Aus updater.log:
Starting univention-upgrade. Current UCS version is 3.2-1 errata102
da waren tatsächlich Dateien vorhanden, die dort nichts zu suchen hatten. Die sind jetzt entsorgt. Was hat es denn mit dem täglichen sysvol-Backup auf sich? Ist das für manuelles Recovery von Richtlinien gedacht, oder werden die bz2-Archive noch anderweitig verwendet?
Wie kann ich verhindern, dass User auf diesem Volume etwas ändern? In einer Samba4-Mailingliste habe ich den Hinweis https://lists.samba.org/archive/samba/2012-December/170402.html auf “samba-tool ntacl sysvolreset” gefunden. Muss ich die ACL’s noch damit nachpflegen?
Dies lässt sich alles über die Univention Configuration Registry steuern.
ucr/backup/enabled
Ist diese Option aktiviert, wird durch einen Cronjob täglich eine Sicherung der Univention Configuration Registry-Daten nach '/var/univention-backup/ucr-backup_.tgz’ durchgeführt. Ist die Variable nicht gesetzt, erfolgt keine Sicherung.
backup/clean/max_age
Automatisches Löschen von Backup-Dateien in /var/univention-backup, die älter als backup/clean/max_age sind. Wenn diese Variable nicht gesetzt ist, werden keine Dateien gelöscht. Wenn weniger als backup/clean/min_backups Backup-Dateien existieren, werden keine Dateien gelöscht.*
samba4/backup/cron Diese Variable konfiguriert den Zeitpunkt/Intervall, zu dem eine Sicherung des Samba Provision Verzeichnis durchgeführt wird. Das Format ist unter ‘man 5 crontab’ dokumentiert. Ist die Variable nicht gesetzt, erfolgt keine Sicherung.