ubuntuusers.de

Ich hab, um einen doch immer größer werdenden Berg an Daten zu managen, auf einem RPI eine externe Festplatte laufen, auf der ich ein Verzeichniss mittels NFS in meinem Desktop mounte. Das klappt auch soweit klaglos und zufriedenstellend.

Irgendwas muss gestern Abend schief gelaufen sein. Mein Desktop sollte eigentlich in den Sleep Mode, heute morgen lief er aber, als ich ins Büro kam. Netzwerk war down, alle Wiederbelebungsversuche scheiterten. Rechner blieb beim Neustart hängen, musste hart neugestartet werden. Soweit blöd, grundsätzlich eigentlich nicht tragisch. Außer: Es war noch ein PDF in qpdfviewer geöffnet, in dem ich per Annotationen grade ein Korrektorat durchführe. Diese Datei hatte ich gestern abend noch gespeichert (jeden Tag unter einem neuen Namen, sicher ist sicher). Und genau diese, beim Rechner-Maleur noch offene Version der Datei ist im Eimer, lässt sich mit nix öffnen. Da muss also irgendwas zwischen Desktop und Pi in die Hose gegangen sein.

Meinen Export hab ich mit

(rw,sync,subtree_check)

angelegt, "sync" eben mit dem Blick auf erhoffte bessere Datensicherheit. Hat ja offenbar nicht so recht funktioniert.

Kann mir jemand nen grundlegenden Tip geben, wie ich da strukturell nachbessern kann? Klar ist schonmal, dass ich in Zukunft Dokumente vor dem Sleep immer schließen werde, zudem steht für nächste Woche die Einrichtung eines Backups per borg auf dem Server an, dann sollte da nix mehr wildes passieren. Aber sonst so?

So, dann hätten wir hiermit den Worst Case: Eine Katze hat den RPI runtergeschmissen, wodurch das Stromkabel und das Anschlusskabel der Festplatte rausgerissen wurden. Die Festplatte lässt sich jetzt nicht mehr mounten. Ich hab ein nicht allzu altes Backup, von daher ist das jetzt nur so mittelschlimm. Aber WAS hätte ich bei der Einrichtung dieser Sache anders machen können? SO ist das ganz offensichtlich nicht lauffähig, viel zu gefährlich.

Jemand ne Hilfe, auch wenn die Antwort ist "NFS ist für den Anwendungsfall ungeeignet"?

thom_raindog schrieb:

Eine Katze hat den RPI runtergeschmissen

What?!? ... Ähm, Computer katzensicher verstauen?! 🙄

Ich hab ein nicht allzu altes Backup

Das ist gut, essentiell und immer noch die zuverlässigste Strategie gegen Datenverlust.

SO ist das ganz offensichtlich nicht lauffähig, viel zu gefährlich.

S.o.: alles katzensicher machen 😉

Jemand ne Hilfe, auch wenn die Antwort ist "NFS ist für den Anwendungsfall ungeeignet"?

Generell mal zu NFS: das läuft sehr zuverlässig, - wenn die Infrastruktur stabil ist! Es ist nicht dafür gedacht in einem instabilen Umfeld zu laufen. IdF ist der "sync" sogar kontraproduktiv, weil sich NFS darauf verläßt, dass es immer und sofort schreiben kann. Wichtige Dateien sofort auf's NFS schreiben ist jedenfalls suboptimal, wenn du nicht die Stabilität gewährleisten kannst. Das bemerkst du schon daran, dass der NFS-Client beim Hochfahren ordentlich rumzickt, wenn der NFS-Server nicht verfügbar ist.

Vllt wäre es besser, wenn du lokal arbeitest, und dann (automatisiert oder händisch) ein Backup anlegst. Mit rsync geht sowas prima, auch über's Netzwerk. Vorteil rsync: wenn das Netzwerk nicht verfügbar ist, bricht es einfach ab und macht nichts kaputt.

Danke für die Antwort. Ja, das "Setup" war von vorne herein eher suboptimal, da hätte ich gleich besser planen müssen. Man lernt aus Fehlern.

Als schreibt "sync" sofort, no_sync sammelt erst, und schreibt dann? Wie liefe das denn im Falle eines Disconnects vor dem Schreibvorgang?

Lokale Daten mit Backup hatte ich ja vorher (aus der Zeit stammen die Backups die mich jetzt hoffentlich retten). Allerdings ist mein Platzbedarf mittlerweile deutlich gewachsen, so dass ich deswegen gerne die Daten auf den Server auslagern wollte. Ist das einfach insgesamt ein etwas wahnwitziger Ansatz, oder ist die Idee an sich solide (wenn mit no_sync UND Backups am Server)?

thom_raindog schrieb:

Als schreibt "sync" sofort, no_sync sammelt erst, und schreibt dann?

Kuck in der manpage von nfs (5) nach.

   Die Einhängeoption »sync«

       Der NFS-Client behandelt die Einhängeoption sync anders als einige andere Dateisysteme (lesen Sie mount(8) für eine Beschreibung 
       der  generischen  Einhängeoptionen  sync  und  async).
       Falls  weder  sync noch async festgelegt ist (oder falls die Option async festgelegt wurde) verzögert der NFS-Client das Versenden 
       von Schreibanforderungen von Anwendungen an den Server, bis eines der folgenden Ereignisse auftritt:

              Speicherdruck erzwingt die Zurückgewinnung von Systemspeicherressourcen.

              Eine Anwendung schiebt explizit die Dateidaten mit sync(2), msync(2) oder fsync(3) raus.

              Eine Anwendung schließt eine Datei mit close(2).

              Die Datei wird mittels fcntl(2) gesperrt/entsperrt.

       Mit anderen Worten, unter normalen Bedingungen können von einer Anwendung geschriebene Daten nicht 
       sofort auf dem Server, der die Datei beherbergt, auftauchen.

       Falls die Option sync am Einhängepunkt festgelegt wurde, werden bei jedem Systemaufruf, der Daten in 
       Dateien unter diesem Einhängepunkt schreibt, diese erst auf den  Server  geschrieben,  bevor der 
       Systemaufruf die Steuerung an den Benutzerraum zurückgibt. Damit wird größere Datenzwischenspeicherkohärenz 
       unter den Clients erreicht, allerdings unter signifikanten Leitungseinbußen.

Das läuft also etwas anders als bei "normalen" Filesystemen.

Ist das einfach insgesamt ein etwas wahnwitziger Ansatz, oder ist die Idee an sich solide?

Wenn der Client beim Runterfahren, bzw beim Schlafenlegen das sauber unmounted, dann sollte es keinen großen Unterschied zu einem lokalen Dateisystem geben. Klar, Netzwerk ist langsamer als lokale Festplatte, das bleibt zu beachten, wenn wirklich große Dateien geschrieben werden.

thom_raindog schrieb:

Kann mir jemand nen grundlegenden Tip geben, wie ich da strukturell nachbessern kann? Klar ist schonmal, dass ich in Zukunft Dokumente vor dem Sleep immer schließen werde, zudem steht für nächste Woche die Einrichtung eines Backups per borg auf dem Server an, dann sollte da nix mehr wildes passieren. Aber sonst so?

Hallo!

• Ich nutze - auch im Heimnetz - dafür FUSE/sshfs mit der Option reconnect (gibt noch einige andere nützliche). Das ist zwar durch den SSH-Weg etwas langsamer, aber ich schiebe maximale Datenblöcke von rund 1 GB durch die Gegend - und das nur ein-, zwei mal im Monat. Beim normalen arbeiten merkt man nicht, dass es extern eingebunden ist.

• Für Dokumente, Scripte, usw. nutze ich einen Nextcloud-Ordner, da dieser den Riesenvorteil hat eine Versionshistorie mitzuliefern. Das kommt meiner Schusseligkeit entgegen ab und an mal den falschen Ordner mit rm -f gelöscht zu haben ☺

• Als Backuplösung habe ich BackupPC am laufen. Das arbeitet auch mit rsync über ssh. Frisst auf den Klienten dann ein wenig Ressourcen, kümmert sich aber selbst um die Backups.

Für deinen Fall "offene Dokumente und suspend" würde ich auf Punkt 2 - Owncloud/Nextcloud verweisen, falls wirklich mal eine Datei dadurch zerstört würde, hättest du die Revisionen.

(Ob das der RasPi alles packt, kann ich nicht beurteilen. Meiner liegt nur in der Schublade.)