RAID erweitern: Festplatte hinzufügen ohne Datenverlust

· Zuletzt geprüft Juli 2026

Erweiterung geplant? Vergleiche dein aktuelles Array mit der vergrößerten Variante — gleicher Pool, mehr Platten — bevor du loslegst.

RAID-Rechner öffnen →

Früher oder später trifft jedes NAS auf dieselbe Wand: Der Pool, der vor zwei Jahren riesig wirkte, steht jetzt bei 90 Prozent, und die Frage lautet, ob man einfach eine weitere Platte nachstecken kann oder ob ein kompletter Backup-Löschen-Wiederherstellen-Zyklus ansteht. Die ehrliche Antwort war lange „kommt drauf an, und oft nein" — klassisches RAID war in diesem Punkt berüchtigt starr, und gerade ZFS hat sich zwei Jahrzehnte geweigert, ein RAIDZ-vdev wachsen zu lassen. 2026 sieht das Bild deutlich freundlicher aus: Fast jede Plattform hat inzwischen einen unterstützten Erweiterungsweg, aber jeder bringt seine eigene Mechanik, Wartezeit und sein eigenes Kleingedrucktes mit. Dieser Guide geht die Optionen Plattform für Plattform durch, behandelt dann den Plattentausch-Weg, der überall funktioniert, und zuletzt das Risikomanagement, das aus einer Erweiterung statt eines Glücksspiels eine routinierte Wartungsaufgabe macht.

Platte hinzufügen: Was jede Plattform wirklich unterstützt

Das Anstecken einer neuen Platte an ein laufendes Array heißt Reshape oder Expansion, und die Unterstützung dafür ist leise zum Mainstream geworden. Unterschiede gibt es darin, wie viel davon online passiert, wie lange es dauert und in welchem Zustand deine Daten unterwegs sind.

Die konkrete Erkenntnis: Bevor du irgendetwas annimmst, kläre, welche Schicht deine Redundanz wirklich verwaltet — die Plattformen unterscheiden sich so stark, dass „kann ich eine Platte hinzufügen?" fünf verschiedene richtige Antworten hat, je nachdem, welche Box bei dir steht.

ZFS-RAIDZ-Expansion: Was im Kleingedruckten steht

Weil die RAIDZ-Expansion das neueste und meistgefragte dieser Features ist, verdient sie einen eigenen Abschnitt. Das Feature hängt jeweils eine neue Platte an ein bestehendes RAIDZ1/2/3-vdev und startet dann eine Hintergrund-Umverteilung, die bestehende Blöcke über den breiteren Stripe verschiebt — der Pool bleibt dabei online und nutzbar. Allein das beendet die schmerzhafteste Einschränkung, die ZFS für Heimanwender hatte: Vorher blieb nur, ein komplettes zweites vdev hinzuzufügen oder den Pool zu zerstören und neu aufzubauen.

Das Kleingedruckte hat es aber in sich. Blöcke, die vor der Expansion geschrieben wurden, behalten ihr ursprüngliches Daten-zu-Parität-Verhältnis — ein Block aus der Zeit des 4-Platten-RAIDZ1 belegt weiter Stripe-Platz, als hätte das vdev 4 Platten, auch nachdem du auf 5 erweitert hast. Neu geschriebene Daten nutzen das breitere, effizientere Layout, und alte Daten konvertieren nur, wenn sie neu geschrieben werden (durch normale Fluktuation oder gezieltes Umkopieren von Datasets). Praktisch heißt das: Die nutzbare Kapazität direkt nach der Expansion liegt etwas unter dem theoretischen Wert, den unser Rechner für ein natives 5-Platten-RAIDZ1 zeigt, und nähert sich ihm mit dem Datenumschlag an. Die zpool-attach-Manpage beschreibt dieses Verhalten explizit.

Für die technisch Versierteren: Die Expansion ändert auch das Parity-Level des vdevs nicht — ein RAIDZ1 bleibt ein RAIDZ1, egal wie viele Platten du anhängst. Wenn dein eigentliches Motiv ist, dass der Pool über das hinausgewachsen ist, was Single Parity komfortabel absichert, ist Expansion das falsche Werkzeug; das ist ein Neuaufbau-als-RAIDZ2-Gespräch, und unser RAID-5-vs-RAID-6-Vergleich erklärt, wo diese Grenze verläuft.

Die konkrete Erkenntnis: RAIDZ-Expansion ist real, stabil und ausgeliefert — kalkuliere aber mit weniger sofort freiem Platz, als die naive Rechnung verspricht, und nutze sie nicht als Ersatz für den Wechsel auf Double Parity, wenn Plattenzahl und -größe ihn verlangen.

Der universelle Weg: Platten nacheinander gegen größere tauschen

Wenn kein Einschub mehr frei ist — die Situation, in die jeder 2-Bay- und 4-Bay-Besitzer irgendwann kommt — ist der klassische Erweiterungsweg, jede Platte einzeln gegen eine größere zu tauschen. Die Sequenz ist immer dieselbe: eine Platte ziehen, die größere einsetzen, den vollständigen Rebuild abwarten, dann die nächste. Die zusätzliche Kapazität bleibt gesperrt, bis die letzte Platte getauscht ist; danach lassen mdadm, ZFS (mit autoexpand=on), SHR und DSM den Pool in den neuen Platz hineinwachsen. Synology dokumentiert diese Platte-für-Platte-Prozedur in derselben Erweiterungs-KB, und SHR hat den Extra-Trick, bei gemischten Größen einen Teil der Kapazität schon früher freizugeben — unser Guide zu gemischten Plattengrößen zeigt, wie diese Rechnung funktioniert.

Der Preis dieses Wegs ist Zeit und Risiko multipliziert mit der Plattenzahl. Jeder Tausch ist ein voller Rebuild — bei heutigen Kapazitäten Stunden bis über ein Tag pro Platte, wie unser Rebuild-Zeit-Guide vorrechnet — und während jedes einzelnen Rebuilds läuft ein Single-Parity-Array mit null Redundanz. Vier Platten bedeuten vier separate Fenster, in denen ein weiterer Ausfall oder ein unlesbarer Sektor den Pool beendet. Für RAID 6 oder RAIDZ2 sind das überlebbare Quoten, für RAID 5 mit großen Platten eine ernsthaft unbequeme Wette.

Die konkrete Erkenntnis: Der Tausch-und-Rebuild-Weg funktioniert auf praktisch jeder Plattform und braucht keinen freien Einschub — aber behandle ihn als N aufeinanderfolgende degradierte Phasen, nicht als eine Operation. Und wenn dich dieser Gedanke bei Single Parity nervös macht, sagt dir diese Nervosität etwas.

Wie lange dauert dein Rebuild — und wie riskant ist er? Der Rebuild-Rechner schätzt Dauer und URE-Ausfallrisiko für deine exakten Platten.

Rebuild-Rechner öffnen →

Risikomanagement: Erweiterungen scheitern im dümmsten Moment

Egal welchen Weg du nimmst: Eine Erweiterung bedeutet viele Stunden anhaltender Vollflächen-Plattenaktivität — genau die Last, die aus einer angeschlagenen Platte eine tote macht. Das ist kein Aberglaube, sondern derselbe Mechanismus, der Rebuilds nach einem Ausfall riskant macht, wie in Was passiert bei einem RAID-Ausfall beschrieben. Ein Reshape hat noch eine Extra-Falle: Die Operation hält selbst kritischen Zwischenzustand, weshalb die mdadm-Dokumentation auf der Backup-File-Option besteht und ein Stromausfall mitten im Reshape ohne USV einer der wenigen Wege ist, ein Array wirklich nachhaltig zu zerlegen.

Die Pre-Flight-Checkliste ist deshalb kurz und nicht verhandelbar. Erstens ein verifiziertes, aktuelles Backup — nicht weil Erweiterungen oft scheitern, sondern weil sie, wenn sie scheitern, komplett scheitern; RAID ist kein Backup gilt in Wartungsfenstern doppelt. Zweitens vor dem Start die SMART-Werte jeder Platte prüfen, denn eine Platte, die schon reallocated Sectors loggt, wird einen 20-Stunden-Reshape nicht genießen. Drittens die Erweiterung an einer USV laufen lassen, und viertens vorher einen Scrub durchziehen, damit der Reshape nicht auf halber Strecke über einen latenten unlesbaren Sektor stolpert. Keiner dieser Schritte kostet Geld außer der USV — und alle sind billiger als Datenrettung.

Die konkrete Erkenntnis: Plane eine Erweiterung wie ein kleines Wartungsprojekt — Backup verifiziert, SMART sauber, Scrub erledigt, USV dran — und sie wird auf die bestmögliche Art langweilig.

Wann Erweitern die falsche Antwort ist

Manchmal lautet der ehrliche Rat, das aktuelle Array gar nicht zu vergrößern. Bei einem 2-Bay-NAS ist der Plattentausch die einzige In-Place-Option, und die Ökonomie spricht oft eher für den Umzug auf ein 4- oder 6-Bay-Gehäuse — größere Arrays verteilen den Parity-Overhead auf mehr Platten und geben dir gleich noch einen Erweiterungspfad für die nächste Runde, genau der Trade, den unser Upgrade-Guide von 2 auf 4 auf 6 Bays durchrechnet. Ähnlich gilt: Wenn das Array so alt ist, dass alle Platten auf denselben Verschleißpunkt zulaufen, ist es verkehrt, fünf alternden Platten die Dauerlast eines Reshapes aufzubürden, nur um eine sechste hinzuzufügen; ein frischer Pool auf frischen Platten mit Copy-Migration ist entspannter und lässt dir bis zur Außerbetriebnahme des alten Satzes eine vollständige Rückfallkopie.

Und wenn die Erweiterung in Wahrheit ein verkapptes Redundanz-Upgrade ist — du willst von RAID 5 auf RAID 6 oder von RAIDZ1 auf RAIDZ2 — machen die meisten Plattformen daraus einen Neuaufbau, keinen Reshape (mdadm ist die nennenswerte Ausnahme, die Level langsam in-place konvertieren kann). Dann plane es von Anfang an als Migration. Die konkrete Erkenntnis: Expansion ist das Werkzeug für „gleiches Design, mehr Platz" — wenn du eigentlich ein anderes Design willst, migriere, statt das alte zu dehnen.

Empfehlung nach Plattform

Auf Unraid: Platte einfach hinzufügen — das ist der Partytrick der Plattform, die Kapazität ist sofort verfügbar und die Parity bleibt unangetastet. Auf Synology: den Platte-hinzufügen-Flow des Speicher-Managers für SHR nutzen und DSM den Resync über Nacht laufen lassen; es ist die polierteste Umsetzung im Feld. Auf TrueNAS oder jedem OpenZFS-2.3+-System ist die RAIDZ-Expansion per zpool attach jetzt der offizielle Weg für eine einzelne Platte — mit dem Kapazitäts-Kleingedruckten von oben. Auf einer DIY-mdadm- oder Btrfs-Box funktionieren die Werkzeuge gut, aber lies die Wiki-Prozedur vollständig, bevor du startest, denn die Sicherheitsnetze (Backup-File, Balance-Filter) sind Handarbeit. Und egal welche Plattform: Modelliere das Vorher/Nachher zuerst im RAID-Rechner, damit der Kapazitätsgewinn eine Zahl ist statt einer Hoffnung — und wirf danach einen Blick in den Rebuild-Rechner, um zu sehen, wie das Wartungsfenster wirklich aussieht.

Weiterführende Artikel

NAS Upgrade: 2-Bay → 4-Bay → 6-Bay richtig planen

RAID Rebuild-Zeit: Wie lange dauert der Wiederaufbau?

Kann man verschiedene Plattengrößen im RAID mischen?

Was passiert bei einem RAID-Plattenausfall?

SHR vs traditionelles RAID – Warum Synology es anders macht

Teilen:WhatsAppTelegramFacebookXReddit
📊 Rechner