Datenlaufwerk einhängen und vor dem Dienststart prüfen

Wenn sich ein Datenlaufwerk nicht einhängen lässt, meldet die Anwendung unter Umständen nicht sofort einen Fehler. Der vorgesehene Einhängepunkt /srv/data bleibt als gewöhnliches Verzeichnis auf dem Systemlaufwerk bestehen. Der Dienst kann dort weiterschreiben, bis auf dem Systemlaufwerk kein Platz mehr ist. Nach Wiederherstellung des Mounts werden diese Dateien verdeckt. Dadurch entstehen zwei Datenbestände, die sich nur schwer auseinanderhalten lassen. Bei der Abnahme vor dem Produktivbetrieb muss deshalb das Dateisystem hinter dem Pfad geprüft werden – nicht nur, ob das Verzeichnis existiert.

1. Datenlaufwerk identifizieren und Grenzen der Eingriffe festlegen

Diese Anleitung verwendet Ubuntu Server 24.04 LTS und eine Datenpartition mit bereits vorhandenem ext4-Dateisystem. Eine Partitionierung oder Formatierung wird nicht durchgeführt. Die Befehle werden per SSH auf dem Server ausgeführt. Die Zugangsdaten von CloudSFP sind nach der Zahlung in der Konsole einsehbar. Werden mehrere Adressen angezeigt, verwenden Sie die erste.

Die Standardausstattung umfasst zwei direkt angebundene 1TB-NVMe-Laufwerke ohne Hardware-RAID. Aus der Gerätenummer lässt sich weder ableiten, welches Laufwerk das System- oder Datenlaufwerk ist, noch ob Redundanz besteht. Ist bereits ein Software-RAID oder eine andere Speicherschicht eingerichtet, muss das Dateisystem auf dieser übergeordneten Schicht eingehängt werden. Die Schicht darf nicht durch das direkte Einhängen eines Mitgliedslaufwerks umgangen werden.

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
sudo blkid
findmnt -T /
findmnt -T /srv

Identifizieren Sie die Zielpartition anhand von Kapazität, Dateisystemtyp, vorhandenen Einhängepunkten und Installationsaufzeichnungen. Notieren Sie anschließend ihre UUID. Eine UUID ist stabiler als ein durch Geräteenumeration vergebener Name, aber nicht zwangsläufig eindeutig: Beim Klonen eines Dateisystems kann auch dessen UUID kopiert werden. Beheben Sie doppelte UUIDs, bevor Sie einen Eintrag in die Startkonfiguration aufnehmen.

Die folgenden Änderungen müssen vorgenommen werden, bevor das Datenlaufwerk produktiv genutzt wird. Auf einem bereits produktiv eingesetzten Server sind zunächst alle Schreibzugriffe zu stoppen sowie Backups und Wiederherstellungsweg zu prüfen. Hängen Sie kein aktiv genutztes Dateisystem allein zu Testzwecken aus.

2. Mount testen, dann in fstab eintragen

Legen Sie einen leeren Einhängepunkt an und prüfen Sie, ob darin bereits Dateien liegen. Berücksichtigen Sie auch versteckte Dateien. Ist das Verzeichnis nicht leer, klären Sie zuerst die Herkunft der Dateien. Löschen oder überschreiben Sie sie nicht.

sudo mkdir -p /srv/data
sudo find /srv/data -mindepth 1 -maxdepth 1 -print
read -r -p 'Filesystem UUID: ' DATA_UUID
sudo blkid -U "$DATA_UUID"
sudo mount -t ext4 -o ro "UUID=$DATA_UUID" /srv/data
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID

Führen Sie den Mount erst aus, wenn die Ausgabe von blkid mit den Aufzeichnungen zur Laufwerksidentität übereinstimmt. Der erste, schreibgeschützte Mount dient der Inhaltsprüfung und ist kein Verfahren zur Reparatur eines beschädigten Dateisystems. findmnt -M prüft hier den exakten Einhängepunkt. findmnt -T ermittelt dagegen das Dateisystem, auf dem ein Pfad liegt. Ist das Datenlaufwerk nicht eingehängt, kann dabei das Root-Dateisystem zurückgegeben werden. Ein erfolgreicher Rückgabestatus allein bestätigt daher keinen korrekten Mount.

Hängen Sie das schreibgeschützt eingebundene Dateisystem nach der Prüfung von Quelle und Inhalt wieder aus. Sichern Sie /etc/fstab, bevor Sie die Datei bearbeiten. Fügen Sie keinen zweiten Eintrag für denselben Einhängepunkt hinzu. Der UUID-Platzhalter im Beispiel muss durch den gerade überprüften tatsächlichen Wert ersetzt werden:

UUID=<已核对的文件系统UUID> /srv/data ext4 defaults,nofail,x-systemd.device-timeout=15s 0 2

Mit diesem Eintrag kann das System auch dann weiter starten, wenn das Laufwerk fehlt. Die maximale Wartezeit auf das Gerät von 15 Sekunden ist eine für dieses Beispiel gewählte Einstellung, keine Zusage zur Bereitstellung oder Wiederherstellung. Soll ein fehlendes Laufwerk den Systemstart verhindern, muss dafür eine eigene Startstrategie entworfen werden. Übernehmen Sie in diesem Fall nofail nicht unverändert.

sudo umount /srv/data
sudo cp -a /etc/fstab /etc/fstab.before-data-mount
sudoedit /etc/fstab
sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo mount /srv/data
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID

Schlägt die Prüfung fehl, korrigieren Sie zuerst die Konfiguration und fahren Sie nicht mit dem Einhängen fort. Hängen Sie nur den Zielpfad ein. Ein pauschales Einhängen aller Dateisysteme kann andere Konfigurationsprobleme verdecken. Auch eine erfolgreiche Syntaxprüfung garantiert nicht, dass das Gerät verfügbar ist. Das tatsächliche Ergebnis des Mounts muss weiterhin geprüft werden.

3. Dienststart an den Mount binden

nofail regelt das Verhalten beim Systemstart, schützt aber nicht die Anwendung. Der Dienst, der das Datenverzeichnis nutzt, muss eine Mount-Abhängigkeit deklarieren. app.service steht im folgenden Beispiel für eine tatsächlich vorhandene Anwendungs-Unit. Ersetzen Sie den Namen durch den realen Unit-Namen und prüfen Sie, ob diese Unit tatsächlich den schreibenden Prozess startet.

Führen Sie sudo systemctl edit app.service aus und ergänzen Sie:

[Unit]
RequiresMountsFor=/srv/data
AssertPathIsMountPoint=/srv/data

RequiresMountsFor startet die für den Zugriff auf diesen Pfad erforderlichen Mounts und legt die Startreihenfolge fest. Die Assertion verhindert den Start, wenn das Verzeichnis zwar existiert, aber kein Einhängepunkt ist. Beide Einstellungen können weder ein falsches Laufwerk erkennen noch die Konsistenzprüfungen der Anwendung ersetzen. Die Prüfung der UUID und ihrer Quelle bleibt daher ein eigenständiger Schritt.

sudo systemctl daemon-reload
sudo systemctl cat app.service
sudo systemctl show app.service -p Requires -p After

Prüfen Sie, ob die Override-Konfiguration wirksam ist und ob das tatsächliche Datenverzeichnis der Anwendung unter /srv/data liegt. Leitet ein Startskript den Pfad an anderer Stelle um, kann die Anwendung trotz korrekter Abhängigkeiten am falschen Ort schreiben. Geplante Aufgaben, manuell ausgeführte Skripte und andere Dienste übernehmen diese Einschränkungen nicht automatisch. Sie müssen jeweils gesondert geprüft werden.

Legen Sie die Unterverzeichnisse für die Anwendung erst nach erfolgreichem Einhängen an. Richten Sie Eigentümer und Zugriffsrechte passend zum tatsächlichen Dienstkonto ein. Gewähren Sie nicht allen Konten Schreibzugriff auf das gesamte Datenlaufwerk und hinterlegen Sie keine Zugangsdaten in der Mount-Konfiguration.

4. Fehlenden Mount und Wiederherstellung vor produktiven Schreibzugriffen testen

Führen Sie den Test in einer Phase ohne produktive Daten und ohne aktive Schreibzugriffe durch. Stoppen Sie zuerst die Anwendung und anschließend die Mount-Unit des Datenlaufwerks. Den Unit-Namen für /srv/data können Sie mit systemd-escape --path --suffix=mount /srv/data überprüfen. Bei komplexen Pfaden darf der Name nicht von Hand geraten werden.

sudo systemctl stop app.service
sudo systemctl stop srv-data.mount
sudo systemctl mask --runtime srv-data.mount
sudo systemctl start app.service
sudo systemctl status app.service srv-data.mount --no-pager

Die vorübergehende Maskierung der Mount-Unit simuliert einen nicht verfügbaren Mount und verhindert, dass dieser beim Start der Anwendung automatisch wiederhergestellt wird. Erwartet wird ein fehlgeschlagener Start, bei dem kein Anwendungsprozess läuft. Meldet das Aushängen, dass das Dateisystem noch verwendet wird, ermitteln Sie den Verursacher. Umgehen Sie diese Prüfung nicht durch erzwungenes Aushängen oder einen Lazy Unmount.

Prüfen Sie jetzt, ob im darunterliegenden Verzeichnis /srv/data neue Dateien entstanden sind. Heben Sie nach dem Test zuerst die Maskierung auf und stellen Sie anschließend den Mount wieder her:

sudo systemctl unmask --runtime srv-data.mount
sudo systemctl start srv-data.mount
findmnt -M /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS,UUID
sudo systemctl reset-failed app.service
sudo systemctl start app.service

Die Wiederherstellung ist erst abgeschlossen, wenn die Quelle stimmt und die Zustandsprüfungen der Anwendung erfolgreich sind. Stellen Sie zum Abschluss der Abnahme sicher, dass die vorübergehende Maskierung aufgehoben wurde. Startabhängigkeiten schützen vor allem die Startphase; sie erkennen keine Laufwerksausfälle im laufenden Betrieb. Fehlerbehandlung in der Anwendung und Monitoring sind daher weiterhin erforderlich.

5. Nachprüfbare Aufzeichnungen zur Inbetriebnahme führen

Dokumentieren Sie Laufwerksidentität, UUID, Einhängepunkt, Dateisystemtyp, fstab-Änderungen, Dienst-Override und die Ergebnisse des Tests mit fehlendem Laufwerk. Planen Sie einen Neustarttest vor dem Produktivbetrieb ein und bestätigen Sie, dass der Mount abgeschlossen ist, bevor der Dienst startet. Ein einmalig erfolgreicher manueller Mount ersetzt keine Prüfung des Startverhaltens.

Fällt nach dem Einhängen eine ungewöhnliche Belegung des Systemlaufwerks auf, prüfen Sie zunächst, ob alte Dateien vom Mount verdeckt werden. Stoppen Sie die betroffenen Schreibzugriffe und planen Sie eine Untersuchung ein. Hängen Sie das Dateisystem nicht im laufenden Betrieb aus, um anschließend sofort Dateien zu löschen. Führen Sie das darunterliegende Verzeichnis und das Verzeichnis auf dem Datenlaufwerk keinesfalls ungeprüft zusammen.

Die abschließenden Abnahmekriterien lauten: Die Quelle ist korrekt, der Pfad ist tatsächlich eingehängt, die Dienstabhängigkeit ist wirksam, bei fehlendem Laufwerk wird nicht an den falschen Ort geschrieben und nach der Wiederherstellung sind die Zustandsprüfungen erfolgreich. Eine Mount-Konfiguration bietet weder Redundanz noch Backups. Beides muss gesondert geplant und geprüft werden.

Häufig gestellte Fragen