Backup schlägt fehl

Global Community Deutsch
#1

Hi,

ich habe auf einen Server zwei CheckMK Sites (1.6.0p19) auf der einen Site läuft das Backup problemlos durch auf der anderen Seite erhalte ich diese Fehlerlemung:

2020-12-02 14:00:21 — Starting backup (Check_MK-dsmon-dsmon-cifsBackup to cifsBackup) —
An exception occured:
Traceback (most recent call last):
File “/omd/sites/dsmon/bin/mkbackup”, line 560, in mode_backup
do_backup(opts)
File “/omd/sites/dsmon/bin/mkbackup”, line 594, in do_backup
complete_backup()
File “/omd/sites/dsmon/bin/mkbackup”, line 1243, in complete_backup
info = create_backup_info()
File “/omd/sites/dsmon/bin/mkbackup”, line 310, in create_backup_info
files = get_files_for_backup_info()
File “/omd/sites/dsmon/bin/mkbackup”, line 363, in get_files_for_backup_info
(f, os.path.getsize(backup_path + “/” + f), file_checksum(backup_path + “/” + f)))
File “/omd/sites/dsmon/bin/mkbackup”, line 370, in file_checksum
with open(path, “rb”) as f:
IOError: [Errno 116] Stale file handle: ‘/mnt/backup/checkmk/Check_MK-dsmon-dsmon-cifsBackup-incomplete/site-dsmon.tar.gz.enc’

Habt Ihr eine Idee warum das eine einen Fehler ausgibt das andere nicht?
Gruß Andreas

#2

Hi,

hast du schon mal darüber nachgedacht, ob dein CIFS Mount von der Fehlerhaften Site nicht genutzt werden darf, weil die andere Site ihn blockiert? Da würde ich mal die Freigaben prüfen.

Viele Grüße, Christian

#3

H Christian,
Danke für den Hinweis. In /tmp liegt eine mkbackup.lock Datei der anderen Site.

Gruß Andreas

#4

Hallo Andreas,

vor einem sehr ähnlichen Problem stand ich auch. Ich habe 3 Sites (1.6p18 RAW) und hatte bei jeder Site das Backup konfiguriert. Die Site die zuerst das Backup startet legt die mkbackup.lock an (ich glaube als site:omd 664). Nach erfolgreichen Backup der ersten Site bleibt das Lock-File aber erhalten und das Backup der anderen Sites bricht ab weil schon ein Lock-File existiert.
Das kannst du einfach prüfen, in dem du das Lock-File mal löschst, und dann das Backup der anderen Site anstartest. Der Fehler trat bei mir aber nur im WATO auf. Ein Backup über via omd backup funktionierte bei mir ohne Fehlermeldung.

Bitte korrigiert mich, wenn ich falsch liege.

Ein Blick in die Datei /omd/sites/SITENAME/bin/mkbackup, ca. Zeile 160 brachte mich dann auf den Workaround, jeder Site ihr eigenes Lock-File zur Verfügung zu stellen.

def acquire_backup_lock():
global g_backup_lock_f
lock_file_path = "/tmp/mkbackup_%s.lock" % os.environ.get("OMD_SITE")

Ich schaue morgen (oder besser gesagt “nachher”) mal nach wie die genaue Syntax war.
Der Kommentar darüber

# Es gibt ein globales Backup-Lock, das bei modifizierenden Aktionen
# geholt wird. D.h. es kann Systemweit immer nur ein Backup oder Restore
# zur Zeit ausgeführt werden.

hat mir irgendwie auch nicht weiter geholfen. Das Lockfile kann ja nach erfolgreichen Backup nicht gelöscht werden, da CheckMK sonst den letzten Start des Backups nicht auswerten kann.

Viele Grüße,
David

#5

Hallo David,

Danke für die Analyse. Ich frage mich ja nur warum die mkbackup.lock nach dem der Backup-Job durchgelaufen ist (egal ob erfolgreich oder nicht) nicht wieder gelöscht wird?

Gruß Andreas

#6

Hi,
vielleicht sollte man das mal als Bug an checkmk senden?
Wenn der Zustand auch bei der 2.0 so ist, kann man es über die feedback Adresse mitteilen?!

VG

#7

Das ist ja die Frage: Ist es ein Bug, oder so gewollt weil …[Begründung]…? Wir können ja nicht die ersten sein, die mehrere Sites via WATO sichern wollen :man_shrugging:

#8

Ich hab es mal an die Feedback 2.0 Adresse gemailt. Alleine schon, dass das lock-File da liegen bleibt, obwohl das Backup durch ist… ist aus meiner Sicht ein Bug. Warum soll es da liegen bleiben? :smiley:

#9

Alles klar.
Habs eben mal in der 2.0i durchgespielt - bleibt auch da liegen.

#10

@afineske
Klappt das Backup denn jetzt bei dir mit dem Workaround?

#11

Sorry für die späte Antwort, andere Projekte hatten leider Vorrang.

Ich erstelle die Backup jetzt über einen Cronjob mittels omd backup <sitename>.

Deinen Workaround habe ich nicht getestet.

Gruß Andreas

#12

Habe hier eine Site auf 1.6.0p21 aktualisiert. Dort ist Werk #11868 enthalten.

The site and appliance backup functionality of Checkmk share a global lock which ensures that only a single backup or restore job is running at a time.

However, on current linux distributions, a permission issue may occur when backing up multiple sites on a single Checkmk server. The problem appears when one site creates the global lock file (/tmp/mkbackup.lock), locks it and releases the lock after the backup. The file is kept after that. Once another site tries to lock the file during it’s backup, a “Permission denied” error is raised. This is caused by specific file restrictions in directories where the sticky bit is set.

The lock file has now been moved to /var/lock/mkbackup/mkbackup.lock to solve this issue.

Jedoch klappt seit dem update das Backup nicht mehr, mit der alten Version lief es ohne Fehler.

Lösung: Verzeichnis /var/lock/mkbackup erstellen und der omd Gruppe Schreib Rechte geben.

Wieso liegt das Lock File nicht im Verzeichnis der Site? Hier hätte sie dann auch die nötigen Berechtigungen. Oder der Installer sollte das Verzeichnis von selbst anlegen.

#13

Die lock-Datei sollte bestimmt ursprünglich nicht nach /var/lock sondern ins var des site-Verzeichnisses. Sprich nach /opt/omd/sites/DEINESITE/var/lock. Hast du 2 Sites mit Backups aktiv? Meiner Meinung nach sollte es für das “Zugriffsrechteproblem” keinen Unterschied machen, ob die lock-Datei unter /tmp oder unter /var liegt - lasse mich aber auch gern vom Gegenteil überzeugen.
Vielleicht kommt ja noch was mit .p22 :slight_smile:

#14

Ich glaube die Idee war eher, zu verhindern, dass zwei site backups gleichzeitig laufen.
Damit andere Sites ein bereits laufendes Backup feststellen können, liegt die lock Datei deshalb ja absichtlich nicht im Pfad einer der Sites.