ubuntuusers.de

Guten Tag,

vorab: Ich habe das Problem mit einem Workaround gelöst - es bleibt jedoch die Frage danach, in wieweit sich das Verhalten meines Rechners erklären lässt.

Folgende Situation: Es geht um die Kommunikation zweier Server, die beide hinter derselben Firewall hängen, aber in verschiedenen Subnetzen. Zum einen ein Nextcloud-Rechner in der DMZ - also von "außen" erreichbar. Zum anderen ein Backup-Rechner, der sich in jeder Nacht um die Sicherung der Daten kümmert. Der Backup-Rechner hängt in einem privaten Subnetz, das man durch die Firewall nicht erreichen kann. Der Backup-Rechner baut nachts von innen eine sshfs-Verbindung zum Nextcloud-Rechner auf. Damit der Nextcloud-Rechner weiß, dass die Verbindung steht, hinterlässt der Backup-Rechner im /tmp-Verzeichnis der Nextcloud eine Datei ohne Inhalt - sozusagen als Status-Anzeige. Dies habe ich bislang im Skript über den Befehl touch umgesetzt - also der Backup-Rechner erzeugt in dem eingehängten /tmp-Verzeichnis der Nextcloud mit touch eine leere Status-Datei. Die Anwesenheit dieser Datei wird dann von der Nextcloud überprüft, die dann ihrerseits in den Maintenance-Modus geht und danach die MySQL-Datenbank anhält. Wenn das erfolgreich war, dann legt die Nextcloud ihrerseits eine entsprechende Datei in das /tmp-Verzeichnis, so dass jetzt der Backup-Rechner weiß, dass er nun mit Rsnapshot loslegen kann. Wenn das Backup erledigt ist, wird die Backup-Status-Datei vom Backup-Rechner wieder entfernt. Dies wird dann wiederum vom Nextcloud-Rechner registriert, der im Anschluss wieder den Betrieb aufnimmt. So weit so gut - möglicherweise etwas umständlich, aber seit Jahren äußerst stabil und zuverlässig.

Anfang dieses Jahres gab es dann plötzlich Probleme - der Prozess wollte nicht wie gewohnt in Gang kommen. Es hat ziemlich lange gedauert, bis ich verstanden habe, dass sich nach einer der letzten Aktualisierungen das Verhalten der sshfs-Verbindung verändert hat: Der Versuch, als root mit dem Befehl touch eine leere Datei in einem entfernten und mit sshfs eingebundenen Verzeichnis zu erzeugen mündete mit einem Mal in der Meldung "Speicherzugriffsfehler". Dieses Phänomen ließ sich sowohl direkt aus der Konsole, als auch mit einem Skript reproduzieren. Ich habe nun mein Skript so verändert, dass die Status-Dateien jetzt mit einem in eine Datei umgeleiteten Echo-Befehl erzeugt werden - das läuft tadellos - das Problem ist also sozusagen "gelöst".

Es bleibt aber die Frage, ob andere dieses seltsame Verhalten (also die Weigerung von touch über sshfs) auch schon erlebt haben, und ob es vielleicht dafür eine Erklärung gibt, wie es sein kann, dass ein Skript, das jahrelang problemlos läuft, mit einem Mal ins straucheln kommt.

Mit vielem Dank vorab und herzlichen Grüßen

Hallo,

ich hatte schonmal das Dateien nicht sofort geschrieben wurden weil sie noch im lokalen zwischespeicher waren. Das kann ja bei einer leerdatei auch durchaus der fall sein.

Speicherzugriffsfehler ist entweder ein Bug in sshfs/FUSE (oder sonst einer beteiligten Software), oder ein Nebeneffekt von defekter/übertakteter Hardware (Memtest).

Wenn du unter Ubuntu 22.04 sshfs 3.7.1 verwendest könntest du es mit 3.7.3 von Ubuntu 23.10 versuchen oder 3.6.0 von Ubuntu 20.04.

Oder du verzichtest auf sshfs und findest einen anderen Weg, deine Dateien zu übertragen. rsync?

Danke für die Kommentare!

Ich hatte auch schon über andere Verbindungsoptionen nachgedacht, aber auf die naheliegende Idee, es mit rsync zu versuchen, bin ich nicht gekommen - ich vermute Brett vorm Kopf. Dabei nutzt rsnapshot ja auch rsync und das läuft seit Jahren vollkommen fehlerfrei. Ich werde in den kommenden Tagen mal mit rsync herumexperimentieren - aktuell funktioniert ja glücklicherweise auch mein Workaround.

Einen Nachteil sehe ich bei rsync im Vergleich zu sshfs: Mit sshfs habe ich das entfernte /tmp-Verzeichnis des Nextcloud-Rechners lokal im Backup-Rechner eingebunden, so dass mein Synchronisations-Skript auf dem Backup-Rechner einfach dort lokal nach der Existenz der Nextcloud-Statusdatei (Nextcloud-aus-und-MySQL-gestoppt) schauen muss - und wenn diese Datei existiert, dann den Backup-Prozess starten. Mit rsync hingegen hänge ich ja das entfernte Verzeichnis nicht lokal ein, sondern übertrage lediglich Dateien. Dann muss aber auch der Status-Überprüfungsprozess (von Nextcloud zu Backup - siehe oben) ein anderer werden.

Ich sehe hier zwei Optionen:

• Entweder es gibt eine Fehlermeldung (Datei nicht vorhanden), die ich abfangen und auswerten müsste.

• Oder der Status ist Inhalt der Datei, dann muss ich nicht die Existenz, sondern den Datei-Inhalt überprüfen, damit der Backup-Rechner Informationen über den Status der Nextcloud hat.

Denn die Nextcloud sitzt in der DMZ und der Backup-Rechner hinter der Firewall, so dass die Kommunikation (der Tunnel durch die Firewall) zwischen den Rechnern nur vom Backup-Rechner ausgehen kann.

Sicherlich alles lösbar, aber auch eine schöne Puzzle-Aufgabe für die nächste Zeit ☺

Vielen Dank nochmal für die Anregungen!