Festplatten unter Linux einbinden gehört zu den Aufgaben, die auf den ersten Blick technisch wirken, in der Praxis aber fast immer nach demselben Muster ablaufen: Du erkennst einen neuen Datenträger, legst darauf eine Partition an, erzeugst ein Dateisystem, wählst einen Mountpunkt und trägst das Ganze sauber in /etc/fstab ein. Wenn du diese Kette einmal verstehst, werden viele spätere Server- und Storage-Anleitungen deutlich einfacher.

Der gefährlichste Fehler dabei ist nicht irgendein komplizierter Linux-Sonderfall, sondern der falsche Datenträger. Wer versehentlich auf dem falschen Device arbeitet, kann produktive Daten löschen. Deshalb gehen wir in dieser Anleitung bewusst Schritt für Schritt vor und prüfen nach jeder Änderung, ob wir wirklich noch auf dem richtigen Laufwerk arbeiten.

Voraussetzungen

Linux-System mit sudo-Rechten oder Root-Zugang
Ein neuer Datenträger oder eine neue virtuelle Disk, die noch nicht produktiv genutzt wird
Werkzeuge wie lsblk, blkid, parted und mkfs.ext4
Für LVM zusätzlich das Paket lvm2

Wichtig vorab: Alle Gerätebeispiele wie /dev/sdb oder /dev/nvme1n1 sind nur Platzhalter. Auf deinem System kann der neue Datenträger einen anderen Namen haben. Genau deshalb prüfst du ihn mehrfach, bevor du irgendetwas schreibst.

Schritt 1: Den richtigen Datenträger sicher erkennen

Bevor du partitionierst oder formatierst, brauchst du absolute Klarheit darüber, welches Device neu ist. Genau hier passieren die teuersten Fehler.

lsblk
lsblk -f
lsblk -d
sudo fdisk -l

Typische Namensmuster:

/dev/sdX für viele SATA-, USB- oder virtuelle SCSI-Laufwerke
/dev/nvme0n1 oder ähnlich für NVMe-Laufwerke

Ein neuer, noch leerer Datenträger fällt oft dadurch auf, dass er zwar in lsblk auftaucht, aber noch keine Partitionen darunter hat.

Verifizieren: Der Schritt ist erfolgreich, wenn du den neuen Datenträger anhand von Größe, Modell oder Zeitpunkt des Anschlusses eindeutig benennen kannst. Wenn du hier noch unsicher bist, gehst du nicht weiter.

Schritt 2: Verstehen, was Partitionstabelle, Partition, Dateisystem und Mountpunkt sind

Bevor wir etwas anlegen, sortieren wir die Begriffe:

Datenträger = das ganze Device, zum Beispiel /dev/sdb
Partition = ein Bereich darauf, zum Beispiel /dev/sdb1
Dateisystem = die eigentliche Struktur, in der Dateien gespeichert werden, zum Beispiel ext4
Mountpunkt = das Verzeichnis im Linux-Dateibaum, unter dem die Partition sichtbar wird
fstab = die Datei, die festlegt, was beim Boot automatisch gemountet werden soll

Wenn du das sauber trennen kannst, wird der Rest deutlich einfacher: Erst wird der Speicher vorbereitet, dann formatiert, dann eingehängt, dann dauerhaft hinterlegt.

Verifizieren: Du hast diesen Schritt verstanden, wenn du sagen kannst: /dev/sdb ist nicht dasselbe wie /dev/sdb1, und ein Mountpunkt wie /mnt/daten ist kein eigenes Laufwerk, sondern nur das Zielverzeichnis im Dateibaum.

Schritt 3: Partitionstabelle und Partition anlegen

Für neue Setups ist GPT in der Regel die sinnvollste Wahl. Im Beispiel arbeiten wir mit einem Datenträger, den wir nach Schritt 1 eindeutig als neuen Datenträger erkannt haben.

sudo parted /dev/sdb mklabel gpt
sudo parted /dev/sdb mkpart primary ext4 1MiB 100%
sudo parted /dev/sdb print
lsblk /dev/sdb

Damit legst du eine GPT-Partitionstabelle und eine einzelne Partition an, die fast den ganzen Datenträger nutzt.

Achtung: Diese Befehle löschen alle bisherigen Daten auf dem angegebenen Datenträger. Genau deshalb darfst du sie nur auf dem zuvor eindeutig identifizierten neuen Device ausführen.

Verifizieren: Der Schritt ist erfolgreich, wenn unter lsblk /dev/sdb jetzt eine Partition wie /dev/sdb1 auftaucht und parted print die neue GPT-Struktur zeigt.

Schritt 4: Dateisystem anlegen

Auf die neue Partition kommt jetzt ein Dateisystem. Für viele Linux-Server ist ext4 ein solider Standard.

sudo mkfs.ext4 -L daten /dev/sdb1

Mit -L daten vergibst du zusätzlich ein Label. Für reine Datenpartitionen kannst du optional den reservierten Root-Anteil reduzieren:

sudo mkfs.ext4 -L daten -m 1 /dev/sdb1

Das ist vor allem bei größeren Datenlaufwerken praktisch. Für Systempartitionen ist das etwas anderes, dort solltest du solche Entscheidungen bewusst und getrennt treffen.

Verifizieren: Prüfe danach mit

lsblk -f /dev/sdb
sudo blkid /dev/sdb1

Erwartung: Die Partition hat jetzt den Typ ext4 und ein Label sowie eine UUID.

Schritt 5: UUID auslesen und Mountpunkt vorbereiten

Für dauerhafte Einbindungen in /etc/fstab arbeitest du am besten mit der UUID. Sie ist stabiler als ein Device-Name wie /dev/sdb1, weil sich die Reihenfolge der Geräte ändern kann.

sudo blkid /dev/sdb1
sudo blkid -s UUID -o value /dev/sdb1
sudo mkdir -p /mnt/daten

Kopiere dir die UUID sauber heraus. Sie wird im nächsten Schritt gebraucht.

Verifizieren: Der Schritt ist erfolgreich, wenn der Mountpunkt existiert und du eine UUID für genau die neue Partition vor dir hast. Wenn blkid keine UUID liefert, wurde in der Regel noch kein Dateisystem angelegt.

Schritt 6: fstab-Eintrag schreiben und sicher testen

Jetzt kommt der wichtigste Sicherheitsabschnitt der ganzen Anleitung. Ein falscher Eintrag in /etc/fstab kann dazu führen, dass ein System beim Boot hängen bleibt oder Mounts nicht mehr sauber funktionieren. Darum arbeitest du hier kontrolliert.

sudo cp /etc/fstab /etc/fstab.backup
sudo nano /etc/fstab

Am Ende der Datei ergänzt du zum Beispiel:

UUID=DEINE-UUID /mnt/daten ext4 defaults,nofail 0 2

Die wichtigsten Felder sind:

Feld	Bedeutung
`UUID=...`	welche Partition gemountet wird
`/mnt/daten`	wo sie im Dateibaum erscheint
`ext4`	welcher Dateisystemtyp erwartet wird
`defaults,nofail`	Standardoptionen, plus toleranter Boot, falls das Gerät fehlt
`0`	kein dump-Backup
`2`	fsck-Prüfreihenfolge für Datenpartitionen

Danach testest du zwingend, bevor du auch nur an einen Reboot denkst:

sudo findmnt --verify
sudo mount -a
echo $?
findmnt /mnt/daten
lsblk -f /dev/sdb

Verifizieren: Dieser Schritt ist erst dann erfolgreich, wenn findmnt --verify keine Fehler meldet, mount -a ohne Fehler durchläuft und findmnt /mnt/daten den aktiven Mount zeigt. Wenn hier Fehler auftreten, gehst du noch nicht weiter und startest das System nicht neu.

Schritt 7: Was LVM zusätzlich löst

Der normale Weg mit Partition plus Dateisystem reicht für viele Systeme völlig aus. LVM wird dann interessant, wenn Speicher später flexibler wachsen soll oder mehrere Datenträger zu einem gemeinsamen Pool zusammengefasst werden sollen.

Das Grundmodell lautet:

PV = Physical Volume, also ein LVM-fähiger Datenträger oder eine Partition
VG = Volume Group, also der Speicherpool
LV = Logical Volume, also das eigentliche nutzbare Volume

Verifizieren: Du hast diesen Schritt verstanden, wenn du LVM als zusätzliche Abstraktionsschicht beschreiben kannst: PVs bilden eine VG, aus der LVs bereitgestellt werden.

Schritt 8: Ein einfaches LVM-Beispiel aufbauen

Wenn du den Datenträger direkt für LVM verwenden willst, sieht ein einfacher Ablauf so aus:

sudo pvcreate /dev/sdb
sudo vgcreate vg_data /dev/sdb
sudo lvcreate -L 50G -n lv_daten vg_data
sudo mkfs.ext4 /dev/vg_data/lv_daten
sudo mkdir -p /mnt/lv_daten
sudo mount /dev/vg_data/lv_daten /mnt/lv_daten
sudo blkid /dev/vg_data/lv_daten

Danach kannst du das Logical Volume wie eine normale Partition auch per UUID in die fstab eintragen.

Verifizieren: Der Schritt ist erfolgreich, wenn sudo pvs, sudo vgs und sudo lvs dein PV, die VG und das neue LV anzeigen und du das Volume unter /mnt/lv_daten mounten kannst.

Schritt 9: LVM-Volume vergrößern und Ergebnis prüfen

Der große Vorteil von LVM zeigt sich später beim Vergrößern:

sudo vgdisplay vg_data
sudo lvextend -L +100G -r /dev/vg_data/lv_daten
df -h /mnt/lv_daten

Mit -r wird das Dateisystem direkt mitvergrößert. Das spart einen zusätzlichen manuellen Schritt.

Verifizieren: Der Schritt ist erfolgreich, wenn df -h /mnt/lv_daten danach mehr verfügbaren Speicher zeigt als vorher. Wenn sich die Größe nicht geändert hat, prüfst du zuerst, ob in der Volume Group überhaupt freier Platz vorhanden war.

Troubleshooting

Falscher Datenträger erwischt: Nicht weitermachen. Sofort stoppen und erst prüfen, was genau geschrieben wurde.
Neue Partition erscheint nicht: parted print und lsblk erneut prüfen; in manchen Fällen hilft ein neues Einlesen der Partitionstabelle.
mount -a schlägt fehl: Meist stimmt die UUID, der Mountpunkt oder der Dateisystemtyp im fstab-Eintrag nicht.
System bootet wegen fstab nicht sauber: Deshalb vorher immer Backup und Test mit findmnt --verify und mount -a.
LVM-Befehle fehlen: Paket lvm2 installieren.
LV lässt sich nicht vergrößern: Prüfen, ob die Volume Group noch freien Speicher hat.

Häufige Fragen

Warum sollte ich in fstab lieber UUID statt /dev/sdb1 verwenden?

Weil Device-Namen sich ändern können. Die UUID bleibt für das Dateisystem stabiler und ist deshalb der robustere Weg für dauerhafte Mounts.

Wofür ist nofail gut?

Damit das System beim Boot nicht hart scheitert, wenn ein optionales Gerät einmal nicht vorhanden ist.

Wann brauche ich LVM wirklich?

Wenn Speicher später flexibel wachsen, über mehrere Datenträger verteilt oder leichter verwaltet werden soll. Für eine einfache einzelne Datenpartition ist LVM nicht zwingend nötig.

Warum muss ich fstab vor dem Neustart testen?

Weil ein kaputter Eintrag sonst erst beim Boot auffällt. Dann ist die Situation deutlich unangenehmer als ein kontrollierter Test mit mount -a.

Was ist der Unterschied zwischen Label und UUID?

Ein Label ist menschenlesbar und frei wählbar. Eine UUID ist technisch eindeutiger und meist der stabilere Standard für fstab.

Kann ich auch XFS statt ext4 verwenden?

Ja, wenn es zu deinem Einsatzzweck passt. Für diese Grundlagen-Anleitung nutzen wir ext4, weil es auf vielen Linux-Systemen ein naheliegender und verbreiteter Standard ist.

Fazit

Der sichere Linux-Weg beim Einbinden neuer Festplatten ist immer derselbe: richtigen Datenträger erkennen, Partition anlegen, Dateisystem erzeugen, UUID auslesen, Mountpunkt vorbereiten, fstab sauber schreiben und vor jedem Neustart testen. Genau diese Reihenfolge verhindert die meisten Fehler. LVM ist dann der nächste sinnvolle Schritt, wenn Speicher nicht nur eingebunden, sondern später auch flexibel erweitert werden soll.

Als nächster passender Grundlagenartikel eignet sich unsere Anleitung zu Linux-Benutzern, Gruppen und Rechten, weil Mountpunkte, Datenverzeichnisse und spätere Dienste oft genau daran scheitern. Für periodische Backups oder Wartungsjobs passt danach außerdem Cron und crontab.

Weiterführende Anleitungen und Quellen

Quellen: lsblk(8) ? man7.org, mount(8) ? man7.org, fstab(5) ? man7.org, blkid(8) ? man7.org, lvextend(8) ? man7.org.