Zusätzliche Festplatte an Linux-VPS anhängen

Was das Hinzufügen eines Blockspeichervolumes zu einem VPS umfasst

Das Hinzufügen eines Blockspeichervolumes zu einem VPS umfasst vier Schritte: Ermitteln Sie das vom Anbieter angehängte Gerät, erstellen Sie darauf ein Dateisystem, hängen Sie es unter einem von Ihnen gewählten Pfad ein und tragen Sie es in /etc/fstab ein, damit es einen Neustart übersteht. Die Befehle sind in wenigen Minuten ausgeführt. Die meisten Probleme treten in den letzten beiden Schritten auf: Ein Mount Point mit falschen Besitzrechten verhindert, dass ein Dienst schreibt, und eine fehlerhafte Zeile in /etc/fstab kann den Server vollständig am Booten hindern.

Ein Blockspeichervolume ist eine virtuelle Festplatte, die der Anbieter über sein eigenes Netzwerk an Ihren Server anhängt. Der Kernel erkennt sie wie das Root-Laufwerk als gewöhnliches Blockgerät. Sie wird unverändert bereitgestellt: ohne Partitionstabelle, ohne Dateisystem und ohne Mount Point. Die folgenden Schritte machen aus diesem unveränderten Gerät ein Verzeichnis, das Ihre Software verwenden kann, und sorgen dafür, dass dieses Verzeichnis nach jedem Neustart automatisch wieder eingebunden wird.

Vor den Befehlen sollten Sie zwei Begriffe klären. Ein Dateisystem ist die auf das Gerät geschriebene Struktur, in der Dateien gespeichert werden. Ein Mount Point ist das Verzeichnis, unter dem dieses Dateisystem in Ihrem Verzeichnisbaum erscheint. Formatieren und Einhängen sind getrennte Vorgänge, und jeder davon kann auf eigene Weise fehlschlagen.

Das Gerät ermitteln, statt /dev/sdb zu raten

Binden Sie das Volume im Panel Ihres Providers ein und prüfen Sie anschließend den Server. lsblk listet alle Blockgeräte auf, die der Kernel kennt. lsblk -f ergänzt für jedes Gerät den Dateisystemtyp, das Label und die UUID (universell eindeutige Kennung).

lsblk
lsblk -f

Die Festplatte mit / ist Ihre Root-Festplatte. Das neue Volume ist das Gerät ohne Dateisystemtyp und Einhängepunkt, dessen Größe der bestellten Größe entspricht. Übernehmen Sie keinen Gerätenamen aus einem Tutorial. Die Namen ergeben sich aus der Reihenfolge, in der der Kernel die Festplatten erkennt. Sie beschreiben daher den aktuellen Bootvorgang und sind keine dauerhafte Zuordnung. Wenn Sie das Volume entfernen und erneut einbinden oder ein zweites Volume hinzufügen, kann ein Name nach dem nächsten Reboot zu einer anderen Festplatte gehören. Deshalb verwendet jede dauerhafte Referenz weiter unten eine UUID statt eines Namens.

Viele Plattformen stellen das Volume außerdem unter /dev/disk/by-id/ mit dem Namen bereit, den Sie im Panel eingegeben haben. Das klärt die Zuordnung, wenn zwei Geräte gleich aussehen.

ls -l /dev/disk/by-id/

Setzen Sie das Gerät einmal als Shell-Variable, damit weiter unten kein fremder Gerätename fest codiert ist. Ersetzen Sie den Wert durch das, was lsblk angezeigt hat.

DEV=/dev/vdb
lsblk -f "$DEV"
sudo wipefs -n "$DEV"

wipefs -n meldet, was der Befehl löschen würde, und löscht nichts. Bei einem neuen Volume gibt er keine Zeilen aus. Wenn er eine Signatur ausgibt, enthält das Gerät bereits ein Dateisystem oder eine Partitionstabelle. Halten Sie dann an und ermitteln Sie, welche Festplatte Sie betrachten, bevor Sie etwas formatieren. Auf einigen Plattformen erscheint das Volume stattdessen unter einem Namen im NVMe-Stil. Sobald der Name in $DEV steht, ändert das hier nichts. Der Gerätetyp beeinflusst jedoch, was Sie erwarten sollten. Mit einer Prüfung, ob eine Festplatte echtes NVMe oder ein Netzwerk-Volume ist lässt sich das mit einem Befehl feststellen.

Volume partitionieren oder das gesamte Gerät formatieren?

Beides funktioniert. Ein direkt auf das gesamte Gerät geschriebenes Dateisystem ist gültig. Das gilt auch für eine einzelne Partition, die das gesamte Gerät ausfüllt.

Das gesamte Gerät lässt sich einfacher vergrößern. Nachdem die Plattform das Volume vergrößert hat, bringt ein Befehl das Dateisystem auf die neue Größe. Bei einer Partition vergrößern Sie zuerst die Partition und anschließend das darin enthaltene Dateisystem. Das sind zwei Befehle und zwei mögliche Fehlerquellen.

Eine Partitionstabelle ist sinnvoll, wenn etwas anderes den Datenträger lesen muss oder wenn jemand ihn an eine Maschine anschließen könnte, die eine Partitionstabelle erwartet. Einige Tools erkennen ein unpartitioniertes Dateisystem auf einem vollständigen Datenträger als nicht initialisierten Datenträger und bieten an, ihn einzurichten. Klicken Sie diese Option nicht an. Wenn Sie eine Partition verwenden möchten, erstellen Sie eine Partition, die das gesamte Gerät ausfüllt.

sudo apt update && sudo apt install -y gdisk
sudo sgdisk --new=1:0:0 --typecode=1:8300 "$DEV"
sudo partprobe "$DEV"
lsblk "$DEV"
PART=/dev/vdb1

Übernehmen Sie den Partitionsnamen aus der Ausgabe von lsblk, anstatt ihn anzunehmen. Eine Partition auf einem virtio-Datenträger hängt 1 an den Datenträgernamen an. Eine Partition auf einem NVMe-Datenträger hängt p1 an. Wenn Sie diesen Weg gewählt haben, verwenden Sie überall $PART, wo der restliche Teil dieser Anleitung $DEV verwendet, weil das Dateisystem auf der Partition und nicht auf dem Datenträger liegt.

Dateisystem erstellen

mkfs löscht den gesamten Inhalt des Geräts und fragt nicht zweimal nach. Führen Sie die Prüfung mit wipefs -n unmittelbar vor dieser Zeile noch einmal durch.

sudo mkfs.ext4 -m 1 -L data "$DEV"

-L data versieht das Dateisystem mit einer Bezeichnung, sodass lsblk -f diese später wieder ausgibt. -m 1 ist die Erklärung wert. ext4 reserviert standardmäßig fünf Prozent des Dateisystems für den root-Benutzer. Auch bei einer vollen Festplatte bleibt dadurch Platz für Schreibvorgänge von Systemprozessen sowie für eine Anmeldung, um das Problem zu beheben. Auf einem root-Dateisystem ist dieser Schutz sinnvoll. Bei einem Datenvolume wird er nicht benötigt. Fünf Prozent eines großen Volumes sind Speicherplatz, für den Sie jeden Monat bezahlen, den Sie aber nie nutzen können. Daher reicht ein Prozent aus.

Für XFS, das in der Red-Hat-Produktfamilie standardmäßig verwendet wird:

sudo mkfs.xfs -L data "$DEV"

Beide Dateisysteme können im eingehängten Zustand vergrößert werden. Der später wichtige Unterschied betrifft das Verkleinern: ext4 kann nur im ausgehängten Zustand verkleinert werden, und XFS kann überhaupt nicht verkleinert werden. Block-Volumes werden normalerweise vergrößert und nur selten verkleinert. Daher ist dies ein kleiner Aspekt, den Sie bei der Auswahl trotzdem berücksichtigen sollten.

Einbinden und die Funktion prüfen

sudo mkdir -p /mnt/data
sudo mount "$DEV" /mnt/data
findmnt /mnt/data
df -h /mnt/data

findmnt gibt eine Zeile mit Informationen zur Einbindung aus und wird mit Exit-Code 0 beendet. Wenn die Einbindung fehlt, gibt es keine Ausgabe und der Exit-Code ist 1. Deshalb eignet sich der Befehl für Skripte. df -h meldet etwas weniger als die bestellte Größe, weil Dateisystem-Metadaten Speicherplatz belegen. Schreiben Sie anschließend Daten und lesen Sie sie wieder aus. Eine Einbindung kann auch dann erfolgreich sein, wenn das Gerät an einer tieferen Stelle fehlerhaft ist.

sudo touch /mnt/data/write-test && sudo rm /mnt/data/write-test

Binden Sie das Dateisystem über ein leeres Verzeichnis ein. Wenn /mnt/data bereits Dateien enthält, werden diese für die Dauer der Einbindung verborgen. Nach dem Aushängen sind sie wieder sichtbar. Die verborgenen Dateien belegen weiterhin Speicherplatz auf dem Root-Datenträger. Das ist einer der Gründe, warum df und du unterschiedliche Angaben zur Belegung eines Datenträgers liefern.

Persistieren Sie den Mount in /etc/fstab anhand der UUID mit nofail

Der Eintrag /etc/fstab sorgt dafür, dass der Mount einen Reboot übersteht. Zwei Teile der Zeile sind wichtiger als der Rest: Das Dateisystem wird anhand seiner UUID angegeben, und die Optionen enthalten nofail.

VOL_UUID=$(sudo blkid -s UUID -o value "$DEV")
echo "$VOL_UUID"
echo "UUID=$VOL_UUID  /mnt/data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2" | sudo tee -a /etc/fstab

Lesen Sie die Zeile Feld für Feld. UUID= bezeichnet das Dateisystem anhand eines Identifikators, der zum Zeitpunkt mkfs im Dateisystem geschrieben wurde. Dadurch folgt der Eintrag den Daten, auch wenn der Kernel das Gerät später unter einem anderen Namen führt. /mnt/data ist der Mount-Punkt. ext4 ist der Dateisystemtyp oder xfs, wenn Sie XFS erstellt haben. Auf die Optionen folgt 0 für dump. Das wird heute von keiner Komponente mehr verwendet. Danach kommt die Reihenfolge für die Dateisystemprüfung: 2 für ein nicht als root eingebundenes ext4-Dateisystem und 0 für XFS, das keine Prüfung beim Booten durchführt.

nofail verhindert, dass Sie in einer Recovery-Konsole landen. Ohne diese Option behandelt systemd den Mount als erforderlich für local-fs.target. Wenn das Volume getrennt oder gelöscht wurde oder nur langsam verfügbar wird, schlägt dieses Ziel fehl. Der Bootvorgang wird dann im Emergency-Modus angehalten und fordert ein root-Passwort an. Möglicherweise haben Sie jedoch keinen Zugriff auf diese Konsole. Mit nofail bootet der Server auch dann, wenn das Volume fehlt. Nur dieses Verzeichnis ist dann nicht verfügbar, und Sie beheben das Problem über SSH. x-systemd.device-timeout=10s begrenzt, wie lange systemd auf das Gerät wartet, statt die standardmäßigen neunzig Sekunden abzuwarten.

Testen Sie die Zeile, bevor Sie ihr vertrauen.

sudo findmnt --verify --verbose
sudo umount /mnt/data
sudo systemctl daemon-reload
sudo mount -a
findmnt /mnt/data

findmnt --verify wertet /etc/fstab aus und meldet Probleme, beispielsweise wenn ein Mount-Punkt nicht existiert oder der Kernel den Dateisystemtyp nicht kennt. mount -a mountet alle Einträge in der Datei, die noch nicht gemountet sind. Dadurch werden eine falsche UUID oder ein falscher Dateisystemtyp erkannt. daemon-reload erzeugt die systemd-Mount-Units anhand der Datei neu. Diese Units werden beim Booten tatsächlich ausgeführt.

Führen Sie anschließend jetzt einen Reboot durch, solange das Volume noch leer ist, und führen Sie findmnt /mnt/data erneut aus. Nur das ist ein aussagekräftiger Test. Eine von Ihnen geplante Minute Ausfallzeit ist ein geringer Preis. Dieselbe Erkenntnis während eines Incidents ist es nicht.

Datenverzeichnis auf das Volume verschieben, ohne Berechtigungen zu beschädigen

Deshalb fügen die meisten ein Volume hinzu: Eine Datenbank, die Daten eines Containers oder ein Mail-Speicher ist über die Root-Disk hinausgewachsen. Der Umzug ist mechanisch. Die beiden Fehlerquellen betreffen Berechtigungen.

1. Beenden Sie den Dienst, dem die Daten gehören, damit während des Kopierens nichts geschrieben wird.
2. Mounten Sie das Volume unter /mnt/data und erstellen Sie darunter ein Verzeichnis für diesen Dienst.
3. Kopieren Sie mit rsync -aHAX. Dadurch bleiben Eigentümer, Berechtigungen, Zeitstempel, Hardlinks, ACLs (Access Control Lists) und erweiterte Attribute erhalten.
4. Prüfen Sie die Kopie mit einem Probelauf, korrigieren Sie den Eigentümer des neuen Verzeichnisses und konfigurieren Sie den Dienst anschließend für den neuen Pfad.
5. Starten Sie den Dienst, bestätigen Sie, dass er in den neuen Pfad schreibt, und behalten Sie das alte Verzeichnis, bis Sie sicher sind.

sudo apt install -y rsync
sudo systemctl stop postgresql
sudo mkdir -p /mnt/data/postgresql
sudo rsync -aHAX /var/lib/postgresql/ /mnt/data/postgresql/
sudo rsync -aHAXn --delete --itemize-changes /var/lib/postgresql/ /mnt/data/postgresql/

Der abschließende Schrägstrich am Quellpfad ist nicht optional. Ohne ihn kopiert rsync das Verzeichnis in das Ziel. Dadurch liegt alles eine Verzeichnisebene tiefer als beabsichtigt. Der zweite Befehl wiederholt die Kopie als Probelauf: -n nimmt keine Änderungen vor, und --itemize-changes listet alle Unterschiede auf, die noch korrigiert würden. Keine Ausgabe bedeutet, dass die beiden Verzeichnisbäume übereinstimmen.

Fehlerquelle 1: Kopieren vor dem Mounten. Wenn Sie in /mnt/data kopieren, während das Volume nicht gemountet ist, landen die Dateien auf der Root-Disk, und zwar in dem Verzeichnis, das später vom Volume überdeckt wird. Die Kopie sieht korrekt aus, der Mount sieht korrekt aus, und die Daten sind unsichtbar. Führen Sie findmnt /mnt/data aus, bevor Sie etwas kopieren.

Fehlerquelle 2: Das Root-Verzeichnis eines neuen Dateisystems gehört root. mkfs erstellt das oberste Verzeichnis als root:root mit dem Modus 755. Ein Dienst, der unter seinem eigenen Benutzer läuft, kann dort daher nichts erstellen. Korrigieren Sie das Unterverzeichnis statt des Mountpoints. Übernehmen Sie den Eigentümer vom alten Speicherort, statt einen Wert zu schätzen. stat gibt genau aus, was gesetzt werden muss, und chown ändert Eigentümer und Gruppe gemeinsam.

stat -c '%U:%G %a' /var/lib/postgresql
sudo chown -R postgres:postgres /mnt/data/postgresql
sudo chmod 700 /mnt/data/postgresql

Ein ext4-Dateisystem enthält an seiner Root außerdem ein lost+found-Verzeichnis. Manche Software verweigert den Start, wenn ein Datenverzeichnis nicht leer ist. PostgreSQL ist ein Beispiel dafür. Das ist bereits ein guter Grund, das Volume unter /mnt/data zu mounten und für jeden Dienst ein Unterverzeichnis anzulegen, statt das Volume direkt auf den Datenpfad des Dienstes zu mounten. In PostgreSQL muss dann data_directory in der Konfigurationsdatei auf den neuen Pfad geändert werden.

Unter Fedora, Rocky oder Alma benötigt der neue Pfad außerdem einen SELinux-(Security Enhanced Linux-)Dateikontext. Andernfalls verweigert der Dienst den Zugriff auf Dateien, deren Eigentümer er ist. Die Ablehnung erscheint in ausearch -m avc -ts recent und nicht im Dienstprotokoll. Das macht die Ursache schwer erkennbar. semanage fcontext -a -t <type> '/mnt/data/postgresql(/.*)?', gefolgt von restorecon -Rv /mnt/data/postgresql, setzt den Kontext. semanage stammt auf diesen Distributionen aus dem Paket policycoreutils-python-utils. SELinux-Kontexte auf einem Server verwalten beschreibt, wie Sie den richtigen Typ ermitteln, statt SELinux zu deaktivieren.

Docker verwendet dafür einen eigenen Weg. Führen Sie bei laufendem Daemon kein rsync von /var/lib/docker aus. Der unterstützte Umzug besteht darin, data-root in /etc/docker/daemon.json auf ein Verzeichnis auf dem Volume zu setzen, anschließend den alten Verzeichnisbaum bei angehaltenem docker und containerd zu kopieren und danach den Daemon neu zu starten.

{
  "data-root": "/mnt/data/docker"
}

Wenn sich auf dem Volume nur die Daten einer Anwendung befinden sollen, ist ein Bind-Mount in der Compose-Datei mit deutlich weniger Arbeit verbunden. Der Unterschied zwischen Bind-Mounts und benannten Volumes entscheidet, welche der beiden Aufgaben Sie ausführen.

Wenn ein Dienst seine Daten weiterhin am ursprünglichen Pfad sehen muss, mounten Sie das neue Verzeichnis über das alte, statt die Konfiguration zu ändern. Fügen Sie eine zweite Zeile zu /etc/fstab hinzu:

/mnt/data/postgresql  /var/lib/postgresql  none  bind,nofail  0  0

systemd erkennt, dass sich die Quelle des Bind-Mounts unter /mnt/data befindet, und mountet das Volume daher zuerst. Die Reihenfolge wird dadurch automatisch eingehalten. Für den Dienst gilt das nicht. Eine Unit, die vor dem Mount startet, schreibt in das darunterliegende leere Verzeichnis. Fügen Sie daher mit sudo systemctl edit postgresql ein Drop-in hinzu:

[Unit]
RequiresMountsFor=/mnt/data

Backups auf einem Volume speichern und die Grenzen kennen

Eine weitere häufige Verwendung für ein Volume ist die Speicherung von Backups. Dafür ist es gut geeignet, allerdings mit einer wichtigen Einschränkung: Das Volume ist an denselben Server angeschlossen. Alles, was auf diesem Server root-Rechte hat, kann es daher löschen. Ein falsch eingegebenes rm -rf, ein fehlerhaftes Deployment-Skript oder ein Angreifer erreicht ein eingebundenes Dateisystem genauso einfach wie die Root-Festplatte. Kopien, die nur auf einem angeschlossenen Volume liegen, schützen Sie vor einem ausgefallenen Datenträger, aber nicht vor einem Fehler.

Zwei Maßnahmen verbessern die Situation. Binden Sie das Backup-Volume mit Optionen ein, die ausführbaren Code darauf einschränken: nosuid, nodev und noexec auf einem Daten-Mount kosten nichts und verhindern, dass das Backup-Verzeichnis zu einem bequemen Ort zum Ausführen von Code wird. Bewahren Sie anschließend eine zweite Kopie an einem Ort auf, den dieser Server nicht mit Löschzugriff erreichen kann.

UUID=<your uuid>  /mnt/backup  ext4  defaults,nofail,nosuid,nodev,noexec  0  2

Prüfen Sie, welche Daten der Snapshot Ihres Panels tatsächlich umfasst, bevor Sie sich darauf verlassen. Auf mehreren Plattformen erstellt ein Server-Snapshot nur eine Kopie der Boot-Festplatte. Ein angeschlossenes Volume wird als separates Objekt mit eigenem Zeitplan und eigenen Kosten gesichert. Gehen Sie von nichts aus, denn ein Snapshot und ein Backup beantworten unterschiedliche Fragen und die Lücke zwischen beiden wird meist erst bei einer Wiederherstellung sichtbar. Wenn die Kopie außerhalb des Servers das Ziel ist, vergleichen Sie Block Storage und Object Storage pro Terabyte, bevor Sie ein zweites Volume kaufen.

Führen Sie die Kopie nach einem Zeitplan aus und machen Sie den Vorgang sichtbar. Ein systemd-Dienst mit einem Timer reicht aus und liefert Ihnen systemctl list-timers sowie einen Journal-Eintrag pro Ausführung. Stellen Sie anschließend noch heute eine einzelne Datei in einem temporären Verzeichnis wieder her. Ein Backup, aus dem noch niemand eine Wiederherstellung durchgeführt hat, ist eine Annahme und kein Backup.

Was ein Blockspeichervolume kostet und warum die Region Ihre Optionen bestimmt

Europäische Hoster führen Blockspeicher als eigenen Rechnungsposten. Die Abrechnung erfolgt pro Gigabyte und Monat auf Basis der bereitgestellten Größe, nicht des tatsächlich belegten Speicherplatzes. Ein getrenntes Volume verursacht weiterhin Kosten, bis Sie es löschen. Das ist nach einer Migration die häufigste Überraschung auf der Rechnung. Im September 2026 ist dieses Modell nahezu überall üblich. Dimensionieren Sie das Volume daher anhand einer realistischen Schätzung des benötigten Speicherplatzes, statt aufzurunden, nur weil der Monatsbetrag gering erscheint.

Ein Volume gehört zu einer Region und häufig zu einer einzelnen Zone innerhalb dieser Region. Es kann nur an einen Server am selben Standort angeschlossen werden. Es folgt der Region, nicht dem Server. Wenn Sie Ihre Workload in eine andere Region verschieben, müssen Sie dort ein neues Volume erstellen und die Daten über das Netzwerk kopieren. Ein Regionswechsel und ein Speicherwechsel sind daher eine gemeinsame Entscheidung und nicht zwei getrennte. Die meisten Plattformen erlauben außerdem jeweils nur einen angeschlossenen Server. Ein Volume ist daher kein gemeinsam verwendeter Speicher für mehrere Maschinen.

In der Praxis lässt sich die Größe nur in eine Richtung ändern. Volumes können ohne Ausfallzeit online vergrößert werden. Das Verkleinern wird entweder nicht unterstützt oder erfordert das vollständige Kopieren auf ein kleineres Volume. XFS kann überhaupt nicht verkleinert werden. Wählen Sie zunächst eine Größe, deren Kosten für Sie akzeptabel sind, und vergrößern Sie das Volume, sobald das Dateisystem zu etwa achtzig Prozent belegt ist.

Dateisystem vergrößern, nachdem die Plattform das Volume vergrößert hat

Die Vergrößerung des Volumes im Panel ändert das Gerät. Das Dateisystem wird dadurch nicht geändert. Daher meldet df weiterhin die alte Größe, bis Sie das darauf liegende Dateisystem vergrößern.

lsblk "$DEV"
sudo resize2fs "$DEV"
df -h /mnt/data

ext4 kann im eingehängten Zustand vergrößert werden. Bei XFS erwartet der Befehl den Einhängepunkt und nicht das Gerät: sudo xfs_growfs /mnt/data. Wenn Sie das Volume partitioniert haben, vergrößern Sie zuerst die Partition und anschließend das darin enthaltene Dateisystem. growpart stammt unter Debian und Ubuntu aus cloud-guest-utils, unter Fedora und RHEL aus cloud-utils-growpart.

sudo apt install -y cloud-guest-utils
sudo growpart "$DEV" 1
sudo resize2fs "$PART"

Wenn lsblk weiterhin die alte Größe meldet, obwohl die Plattform die Größenänderung als abgeschlossen angibt, hat der Kernel die Änderung noch nicht erkannt. Ein Neustart übernimmt die Änderung zuverlässig.

Fehlerzustände und die angezeigte Meldung

Der Server startet nach einem Reboot nicht wieder. Die Konsole zeigt You are in emergency mode, und das Journal enthält Dependency failed for Local File Systems über einem fehlgeschlagenen Mount. Ein Eintrag /etc/fstab ohne nofail, der auf ein nicht vorhandenes Gerät verweist, ist normalerweise die Ursache: ein getrenntes Volume, ein gelöschtes Volume oder eine UUID, die nie übereinstimmte. Öffnen Sie die von Ihrer Plattform bereitgestellte Recovery-Konsole, kommentieren Sie die Zeile aus, führen Sie einen Reboot durch und beheben Sie das Problem anschließend ordnungsgemäß.

mount: /mnt/data: special device /dev/vdb does not exist. Der Name in Ihrem Befehl oder in /etc/fstab entspricht nicht der aktuellen Bezeichnung, unter der der Kernel diesen Datenträger kennt. Führen Sie lsblk aus und verwenden Sie anschließend die UUID. Genau diesen Fehler verhindert die Benennung über die UUID.

mount: /mnt/data: wrong fs type, bad option, bad superblock. Entweder stimmt der Typ nicht mit dem Dateisystem überein, ext4 wurde für ein XFS-Volume geschrieben, oder Sie verweisen auf den gesamten Datenträger, während sich das Dateisystem auf einer Partition befindet. lsblk -f zeigt den vom Kernel erkannten Typ für jedes Gerät.

umount: /mnt/data: target is busy. Ein Prozess hält eine Datei unter diesem Pfad geöffnet, oder eine Shell verwendet den Pfad als Arbeitsverzeichnis. sudo fuser -vm /mnt/data listet die Prozesse auf, und sudo lsof +f -- /mnt/data liefert weitere Details. Auch ein Bind-Mount desselben Dateisystems an einer anderen Stelle hält es fest. Prüfen Sie daher findmnt auf einen zweiten Eintrag.

Der Dienst läuft, aber das Volume bleibt leer. Entweder verweist die Konfiguration weiterhin auf den alten Pfad, oder die Unit wurde vor dem Mount gestartet und hat in das darunterliegende Verzeichnis geschrieben. findmnt /mnt/data bestätigt den Mount, sudo lsof +D /mnt/data zeigt, ob er verwendet wird, und der oben gezeigte RequiresMountsFor=-Drop-in behebt den Fall mit der falschen Startreihenfolge.

Das Volume wird früher als durch die Dateien erklärbar als voll gemeldet. Eine gelöschte Datei, die ein Prozess weiterhin geöffnet hält, belegt ihre Blöcke, bis der Prozess sie schließt. Deshalb stimmen df und du nicht überein, bis der Schreibprozess neu gestartet wird. Die Einstellung für reservierte Blöcke aus mkfs.ext4 -m erklärt eine kleinere, konstante Abweichung in dieselbe Richtung.

FAQ

Wie ermittle ich den Gerätenamen eines neuen Block-Storage-Volumes?

Führen Sie nach dem Anhängen des Volumes im Panel lsblk -f auf dem Server aus. Das neue Volume ist das Gerät ohne Dateisystemtyp und ohne Mountpoint in der bestellten Größe. ls -l /dev/disk/by-id/ zeigt häufig den Namen an, den Sie dem Volume gegeben haben. Das ist hilfreich, wenn zwei Geräte gleich aussehen. Prüfen Sie mit sudo wipefs -n, ob das Gerät leer ist: Auf einem neuen Volume wird nichts ausgegeben. Auf einem Gerät, das bereits Daten enthält, werden Signaturen aufgelistet. Verwenden Sie danach nicht mehr den Gerätenamen. Referenzieren Sie das Dateisystem über die UUID aus sudo blkid, weil sich Gerätenamen nach Reboots und erneutem Anhängen ändern können.

Warum wechselt mein VPS nach einer Änderung an /etc/fstab in den Emergency-Modus?

Ein Eintrag ohne nofail wird von local-fs.target als erforderlich behandelt. Wenn das Gerät fehlt, schlägt dieses Ziel fehl. systemd stoppt den Bootvorgang mit You are in emergency mode und fordert das root-Passwort an der Konsole an. Ein abgetrenntes Volume, ein gelöschtes Volume oder eine falsch eingegebene UUID führen dazu. Ergänzen Sie bei jedem Eintrag für ein angehängtes Volume nofail, damit der Server stattdessen ohne diesen Mount startet. Führen Sie vor dem Reboot sudo findmnt --verify --verbose und sudo mount -a aus. Damit erkennen Sie einen falschen Typ oder eine falsche UUID, solange Sie noch eine Shell haben.

Sollte ich ein Block-Storage-Volume partitionieren oder das gesamte Gerät formatieren?

Beides ist möglich. Das Formatieren des gesamten Geräts vereinfacht eine spätere Vergrößerung. Nach der Vergrößerung des Volumes durch die Plattform genügt ein Aufruf von resize2fs oder xfs_growfs. Für eine Partition müssen Sie zuerst growpart und anschließend den Dateisystembefehl ausführen. Dadurch sind zwei Schritte korrekt umzusetzen. Erstellen Sie eine Partition, wenn andere Werkzeuge eine Partitionstabelle erwarten oder wenn der Datenträger möglicherweise an eine Maschine angeschlossen wird, die nicht erkannte Geräte initialisieren möchte.

Warum kann mein Dienst nicht auf das neue Volume schreiben?

Ein neues Dateisystem hat ein Root-Verzeichnis, das root:root gehört und den Modus 755 besitzt. Ein Dienst, der unter einem eigenen Benutzer läuft, kann dort daher keine Dateien im obersten Verzeichnis des Mounts anlegen. Erstellen Sie ein Unterverzeichnis für den Dienst und setzen Sie den Besitz entsprechend dem bisherigen Pfad. stat -c '%U:%G %a' gibt den Besitz des alten Pfads aus. Setzen Sie unter Fedora, Rocky und Alma außerdem einen SELinux-Dateikontext für den neuen Pfad. Die Ablehnung wird über ausearch -m avc -ts recent vom Audit-System protokolliert und nicht vom Dienst. Wenn das Verzeichnis korrekt aussieht, die Daten aber fehlen, prüfen Sie mit findmnt, ob das Volume vor dem Kopieren gemountet war und nicht erst danach.

Ist ein Block-Storage-Volume ein Backup meines Servers?

Nein. Das Volume ist mit dem laufenden Server verbunden. Jeder Prozess mit root kann die darauf gespeicherten Daten löschen, genau wie auf dem Root-Datenträger. Das Volume schützt Sie davor, dass der Boot-Datenträger voll läuft, und bietet einen Speicherort für Kopien. Das ist sinnvoll. Ein Backup benötigt eine Kopie, auf die der Server nicht zugreifen und die er nicht löschen kann. Außerdem müssen Sie die Wiederherstellung tatsächlich getestet haben. Prüfen Sie separat, ob der Server-Snapshot Ihrer Plattform angehängte Volumes umfasst. Bei vielen Plattformen wird ein Volume als eigenes Objekt mit eigenem Zeitplan und eigenen Kosten gesichert.