Zum Inhalt

Zwei Festplatten in einem btrfs raid1 zusammenführen

Ein btrfs raid1 ist eine Datenspiegelung auf Dateisystemebene. Wer schonmal Daten mit btrfs verloren hat, kennt die unangenehmen Meldungen beim btrfs scrub.

Wer noch Platz auf einer anderen Festplatte übrig hat, kann über einen btrfs raid1 auf Dateisystemebene diese Probleme umgehen. Der folgende Artikel beschreibt den Migrationsweg.

Warum btrfs statt mdadm für raid1 verwenden?

Nun, dafür gibt es einige Vorteile.

Zum einen ist eine Prüfung auf Dateisystemebene einfacher, weil Metadaten und Daten gespiegelt werden. Die Prüfung ist zwar CPU-Intensiver, aber so lässt sich auch feststellen, welche der beiden Kopien in Ordnung ist.

Zudem werden btrfs-Dateisysteme bei initrd-Support automatisch erkannt, beide Partitionen werden dann zu einem btrfs-Volumen quasi konfigurationsfrei zusammengefügt. Außerdem ist die Umsetzung recht einfach.

Nachteile sind etwa: Hoher CPU-Verbrauch während der Prüfung und das manuelle Anlegen von Prüfjobs ( btrfs scrub ).

Festplatte bzw. btrfs-Partition für raid1 vorbereiten

Für ein btrfs raid1 sollten die beiden Ziel-Partitionen auf beiden Geräten gleich groß sein. Es muss also der kleinste gemeinsame Nenner gefunden werden. Das geht am einfachsten über die Anzahl der Sektoren über fdisk:

In Zeile 10 sieht man die Anzahl an Sektoren. Dieses ist die wichtige Zielgröße. Wir nutzen diese nun für die neue Partition /dev/sdc1  (in meinem Fall). Mit dem Befehl sudo cfdisk /dev/sdc  lässt sich über eine schöne GUI die neue Partition erstellen. Als Größe habe ich entsprechend  1465145344S eingegeben. Wichtig ist das S am Ende! Ein Formatieren der zweiten Partition mittels mkfs.btrfs  ist nun nicht notwenig. Allenfalls kann man mittels sudo partprobe  die Partitionstabellen neu einlesen.

Partitionen mounten

Nun mounted man die Partitionen, angefangen mit dem existierenden Dateisystem.

Als nächstes fügt man die neue Partition hinzu. Btrfs kennt dazu den folgenden Befehl:

Das btrfs raid1 erstellen

Aber Achtung! Wir sind nun noch nicht fertig! Derzeit hätten wir ein JBOD (»Just a bunch of disks«), also ein großes Dateisystem von (hier) ca. 1200 GiB. Die Konversion in ein Raid1 funktioniert gut und ohne Datenverlust mittels zweier Befehle. Übrigens: Man kann auch beide Befehle kombinieren, aber das ist interessanterweise weniger performant.

Metadaten auf Raid1 konvertieren

Im ersten Schritt werden die Metadaten als raid1 geklont, im zweiten Schritt die echten Daten.

Erklärung:

  • fi balance  (kurz für filesystem balance ) ist ein Befehl, der die Daten über ein Profil neu anordnen lässt.
  • -m  ist die Option, um mit Metadaten zu arbeiten.
  • -mconvert  ist entsprechend die Option, ein neues Profil auf die Metadaten des Diskarrays anzuwenden.
  • raid1,soft  ist das Profil btrfs raid1. soft  sorgt dafür, dass es sich nur auf Daten auswirkt, die noch nicht diesem Profil entsprechen. Bei der ersten Ausführung sind das alle Daten.

Nutzdaten auf raid1 konvertieren

Um auch die Nutzdaten zu spiegeln, verwendet man analog folgenden Befehl:

Dabei steht -dconvert=  entsprechend für ein neues Profil auf die Nutzdaten des Diskarrays zu legen. Dieser Befehl dauert etwas länger.

In einer zweiten Shell kann man auch mit folgendem Befehl zugucken:

Finaler Test

Festplattennutzung und single chunks

Nach dem Erstellen des neuen Profils auf dem btrfs raid1 Dateisystem könnten trotzdem noch einzelne Chunks nur auf einer physischen Festplatte liegen. Diese sind aber in der Regel null Bytes groß, da ja alle tatsächlichen Daten konvertiert wurden. Zu erkennen ist das wie folgt:

Diese leeren (aber dennoch Speicher reservierenden) chunks lassen sich auch schnell vom btrfs raid1 entfernen.

Der obrige Befehl führt ein Balancing auf Chunks aus, die keinen Platz belegen.

Mount-Optionen

Ein Mount der btrfs-Devices funktioniert automatisch, sobald man eines der devices mountet. Wer aber ganz sicher gehen möchte oder wessen initrd kein btrfs detect  ausführt, kann alle devices in der Datei /etc/fstab  per Hand eingeben. Ich verwende hier zum Teil Devicenamen, besser wären aber UUIDs.

Die UUIDs findet man wie folgt heraus (sind aber optional):

Prüfen des Devices

Wer ganz sicher gehen will, der kann schauen, ob beide Devices (und die Partitionen auf diesen) wirklich dem neuen btrfs raid1 volume zugeordnet sind:

Hier ist etwa zu erkennen, dass zwei Devices (bzw. Partitionen) genutzt werden, die jeweis knapp 700 GiB groß sind. Es sind ca. 120 GiB Nutzdaten darauf, die aber zusammen mit Metadaten etc. auf jeder physischen Partition 123 GiB belegen.

Die genaue Belegung lässt sich mit folgendem Befehl anzeigen:

Wie zu sehen, findet man die Werte hier wieder, allerdings die 123 GiB aufgeteilt auf Data, Metadata und System.

Wartung mittels btrfs scrub

Nun aber zum wichtigsten Vorteil: btrfs scrub .  Sollten mal Daten nicht korrekt sein, muss das btrfs ja auch irgendwie merken. Dieses geschried mittels btrfs scrub , welches selbstverständlich auch auf einem btrfs raid1 korrekt arbeitet und dabei Fehlerhafte (Meta-)daten erkennt und von der noch heilen Partition restauriert. Den Befehl kann man mittels cron oder systemd-Timer laufen lassen. Ich habe mich hier für systemd-Timer entschieden – einen wirklichen Grund zu dieser Lösung gegenüber cron hatte ich aber nicht.

systemd-Unit und Timer installieren

Die Sourcen findet man hier in diesem Gist auf github: https://gist.github.com/gbrks/11b9d68d19394a265d70. Allerdings muss eine Datei verändert werden, dazu mehr.

Die Dateien legt man wie folgt ab:

  • /usr/local/bin/btrfs-scrub
  • /etc/systemd/system/btrfs-scrub.service
  • /etc/systemd/system/btrfs-scrub.timer

In der Service-Datei nutzt man noch den Type=oneshot  statt Type=simple, da der Prozess sich nach getaner Arbeit beendet. Zur Anpassung der Erinnerungs-E-Mail bitte weiter unten lesen.

Aktivierung der systemd-Services

Den Service und den Timer muss man nun in systemd nachladen und aktivieren. Das geschieht mittels folgender Befehle.

Der erste Befehl lässt systemd die Konfigurationsdateien neu einladen. Danach werden der Service (der keine Startanforderung besitzt), sowie der Timer aktiviert. Nun muss man den Timer einmalig starten.

Anpassen der E-Mail-Benachrichtigung

Die E-Mailbenachrichtigung kann man anpassen. Ich habe mich dafür entschieden, nicht (wie in der Vorlage) Mailgun zu verwenden, sondern meinen Gmail-Account.

Zunächst legt man die Datei /root/.netrc wie folgt an:

Wenn man nicht sein Standard-Passwort nutzen möchte (sollte man auch nicht!), so kann man hier ein App-Passwort erstellen. Das ist bei 2-Stufiger Authentifizierung sogar zwingend notwendig.

Als nächstes ersetzt man das obrige Gist durch die Änderungen, die ich in meinem Fork dokumentiert habe.

Fehlerkorrekturen per Mail

Werden Fehler in dem btrfs raid1 volume gefunden und korrigiert, so sieht de Mail dann aus wie bei Oracle beschrieben.

Wie man nun sieht, hat man nun endlich korrigierbare Fehler.

Fazit

Mit btrfs hat man auf Dateisystemebene eine leichtgewichtige raid1-Implementierung, die relativ zügig umgesetzt ist. Nachteile sind unter anderem die manuellen Wartungsskripte und teilweise hohe CPU-Last beim Scrub auf dem btrfs raid1.

Published inHow Tos

Schreibe den ersten Kommentar

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.