Arch Linux Tux

[ENC]BladeXP's Blog

Was die Welt nicht alles braucht!

borgbackup: LZMA, ZLIB und LZ4 im Vergleich

2016-11-12 16:07 | Kategorien: arch debian linux opensource python software ubuntu

Seit einigen Wochen experimentiere ich mit Borg Backup als mögliche Lösung für mein neues, privates, Backup Konzept. Die Ziele dieses Konzeptes würden den geplanten Umfang dieses Artikels sprengen, ich möchte an dieser Stelle daher nur auf einen älteren Artikel von mir zum Thema Datensicherung verweisen.

Im Zuge der Planung für dieses neue Konzept habe ich verschiedene Backup Programme getestet und anschließend rein subjektiv bewertet. Neben einer möglichst einfachen Benutzbarkeit war es mir auch wichtig, möglichst effektiv an meine gesicherten Daten zu kommen und gleichzeitig gut mit inkrementellen Sicherungen arbeiten zu können.

Ohne die Alternativen zu erwähnen, war Borg Backup das Resultat meiner "Forschungsarbeit", es vereint die Möglichkeiten der Kompression, Deduplizierung als auch Verschlüsselung in einem Tool, zusätzlich ist es möglich, ältere Datenstände per FUSE Dateisystem direkt verfügbar zu machen.

Sobald man sich für ein Backup Programm/Tool entschieden hat, geht es jedoch schon an dessen Konfiguration. Ein wesentlicher Aspekt, ist hierbei das verdichten von Daten mittels Kompression, und der sich daraus ergebende Gewinn an Speicherplatz unter Einsatz wertvoller CPU Zyklen. CPU Zyklen kosten Geld, bedingt durch die dafür nötige Energie. Je nach verbautem Prozessor, im für die Datensicherung notwendigen Rechner, wird Wärme erzeugt und Energie beim Energieversorger verrechnet.

Doch nicht nur die ökologischen und wirtschaftlichen Gesichtspunkte sollte man beachten, sondern auch das ein größerer Zeitverbrauch auch bedeutet das die Sicherungszyklen länger werden müssen. Als Referenz dient hierbei die Zeit, welche erforderlich ist, eine inkrementelle Sicherung zu erzeugen. Dauert es 2 Stunden die 500 GiB zu sichernden Daten auf Änderungen zu prüfen, diese zu komprimieren und anschließend zu sichern, dann kann minimal alle 2 Stunden eine neue Sicherung erzeugt werden.

Lange Sicherungszyklen führen dabei automatisch zu einem Zeitfenster in welchem ungesicherte Änderungen im Schadensfall verloren gehen. Die beiden Ziele, eine möglichst gute Kompression zu erreichen, und gleichzeitig möglichst schnell zu sichern, stehen also im Widerspruch. Bei den heute erzielbaren Preisen für zusätzlichen Speicherplatz (€/TB) ist es eine Überlegung wert nicht bestmöglich, sondern stattdessen so gut wie nötig, zu komprimieren.

Zuletzt bestehen unsere heute verfügbaren und sehr großzügig bemessenen Datenmengen auch primär aus Daten, die sich schlecht bis kaum komprimieren lassen. Wer eine große Musik und Filme Sammlung sein eigen nennt, kann hiervon sicherlich ein Lied singen.

Nach all diesen, hier zumindest grob dargestellten Überlegungen, stellte sich mir die Frage aller Fragen: Wie groß ist der Zeit und Platz Unterschied für die von Borg Backup unterstützten Kompressionsmöglichkeiten? Aktuell bietet Borg Backup folgende Möglichkeiten:

Da es sich bei meinem Testsystem um den Homeserver handelt, schwankte die zu sichernde Datenmenge mit jeweils +/- 10 GiB pro Testlauf. Der Einfluss hiervon auf das Gesamtergebnis ist aber deutlich niedriger als erwartet. Hier kurz und schmerzlos die Ergebnisse im Überblick:

Name: 2016-11-02_17:17:43
Fingerprint: e1a2cf764b5e8f1f024507ec1a9149ffa547583c72e56e0ff0c47c95304be368
Hostname: server
Username: root
Time (start): Wed, 2016-11-02 17:17:43
Time (end):   Wed, 2016-11-02 21:54:29
Command line: /usr/bin/borg create --lock-wait 3600 -s -C none /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244822

                       Original size      Compressed size    Deduplicated size
This archive:              532.15 GB            532.15 GB            501.53 GB
All archives:              532.15 GB            532.15 GB            501.53 GB

                       Unique chunks         Total chunks
Chunk index:                  407311               442322
Name: 2016-10-29_20:22:10
Fingerprint: 19e4c5ada051047065cefad817022a72fe6e3dc24bde1ead47c4080fe41749c8
Hostname: server
Username: root
Time (start): Sat, 2016-10-29 20:22:10
Time (end):   Sun, 2016-10-30 01:03:44
Command line: /usr/bin/borg create -s -C lz4 /mnt/backup/weekly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249949

                       Original size      Compressed size    Deduplicated size
This archive:              540.24 GB            533.61 GB            503.59 GB
All archives:              540.24 GB            533.61 GB            503.59 GB

                       Unique chunks         Total chunks
Chunk index:                  414894               450402
Name: 2016-10-30_13:00:22
Fingerprint: da644b0301e9bcc76ecafa5b221ff3382d0525725a6a502b951d466eb433fadb
Hostname: server
Username: root
Time (start): Sun, 2016-10-30 13:00:22
Time (end):   Sun, 2016-10-30 22:58:35
Command line: /usr/bin/borg create --lock-wait 3600 -s -C zlib,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249302

                       Original size      Compressed size    Deduplicated size
This archive:              530.58 GB            515.89 GB            486.54 GB
All archives:              530.58 GB            515.89 GB            486.54 GB

                       Unique chunks         Total chunks
Chunk index:                  410586               446084
Name: 2016-10-31_18:00:11
Fingerprint: 4e0678501bf551fa57458f9762aacb1c2ee13380a18f1612cf930e786fb93061
Hostname: server
Username: root
Time (start): Mon, 2016-10-31 18:00:11
Time (end):   Wed, 2016-11-02 13:28:34
Command line: /usr/bin/borg create --lock-wait 3600 -s -C lzma,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244775

                       Original size      Compressed size    Deduplicated size
This archive:              532.14 GB            514.07 GB            485.11 GB
All archives:              532.14 GB            514.07 GB            485.11 GB

                       Unique chunks         Total chunks
Chunk index:                  407571               442572

Lässt man diese Ergebnisse etwas auf sich wirken, kommt man auf folgendes Ergebnis:

  • Keine Kompression dauert ca. 16606 Sekunden bei 532.15GB zu 501.53GB
  • LZ4 Kompression dauert ca. 16894 Sekunden bei 540.24GB zu 503.59GB
  • ZLIB Kompression dauert ca. 35893 Sekunden bei 530.58GB zu 486.54GB
  • LZMA Kompression dauert ca. 70103 Sekunden bei 532.14GB zu 485.11GB

Die Zeiten hier noch als Tabelle, für den schnellen Vergleich:

KompressionZeit (Sekunden/Minuten/Stunden)Zeit (Differenz)Original vs. Compressed Size
Keine16606 / 276 / 4.61--
LZ416894 / 281 / 4.69+1.73%-1.23%
ZLIB35893 / 598 / 9.97+116.14%-2.77%
LZMA70103 / 1168 / 19.47+322.16%-3.4%

Zu beachten ist, dass ich in der zuerst aufgeführten Liste die Größe inkl. Deduplizierung als Referenz genommen habe, in der Tabelle aber tatsächlich nur die Kompression als solches. Deduplizierung brachte unabhängig von der Kompression ca. 6% an Platz ein, was jede der getesteten Kompressionsmöglichkeiten schlägt.

Meine Empfehlung lautet daher LZ4 als Kompression zu benutzen und sich mit dem Rest erst nicht zu beschäftigen, eine Ausnahme dürften Personen sein, deren Daten weitgehend aus komprimierbaren Inhalten bestehen, also z.B. lokale Kopien der Wikipedia oder Quelltext von Programmen. Beim durchschnittlichen Anwender dürfen jedoch Mediendaten der größte Teil der genutzten Datenmenge sein, welche sich eben nur sehr schlecht weiter komprimieren lassen.


Disk Images platzsparend archivieren

2016-11-12 15:00 | Kategorien: arch debian linux opensource software ubuntu windows

Windows ist bei mir vor allem ein Zweitsystem, es dient für Steam zum Spielen und für Lightroom um meine Fotos zu bearbeiten. Das alte Windows 7 wollte seinerzeit durch Windows 10 ersetzt werden, denn der aktuelle PC soll noch länger genutzt werden als es der Service für Windows 7 gestattet.

Ein wichtiger Aspekt für große Veränderungen an einem System ist natürlich das Backup, während die Mediendaten, welche ich nutze entweder auf dem Homeserver liegen (Fotos) oder aus der Cloud kommen (Steam) ist das Betriebssystem als solches bei mir nicht im Backupkonzept vorgesehen. Zu groß der Platzverbrauch, zu gering der Profit.

Die einfachste Möglichkeit eine komplette Festplatte 1:1 zu sichern ist ein Disk Image, doch dafür benötigt man Platz mit der gleichen Größe, wie die Quelle von welcher man ein solches erstellen möchte. Die Nutzung einer Festplatte ist aber in der Regel kleiner, meist sogar deutlich, als die tatsächlich vorhandene Kapazität eben dieser. Die Idee ist daher mit möglichst geringem Aufwand, möglichst viel Platz zu sparen.

Windows verkleinern

Zuerst kann man, sofern Windows auf der Quelle ist, die Auslagerungsdateien und die Hibernation Files zu deaktivieren, das allein spart in der Regel schon deutlich Platz. Der nächste Schritt ist die obligatorische und großzügige Datenträgerbereinigung mit dem gleichnamigen Tool.

Jetzt kommt das Wichtigste: Das überschreiben der nicht vom Betriebssystem benötigen Blöcke im Dateisystem mit nullen. Der Hintergrund liegt in der Struktur moderner Betriebssysteme versteckt, den dort werden Dateien und dementsprechend auch Blöcke auf dem Datenträger, nicht mehr gelöscht, sondern lediglich als frei markiert. Ein Verhalten, das gut für die Geschwindigkeit und eventuell erforderliche Wiederherstellungsmaßnahmen ist, aber sehr schlecht um davon ein Image zu machen.

Um zuvor genanntes Problem zu umgehen, kann man sich das Tool sdelete herunterladen, und anschließend in einer Befehlszeile mit Administratorrechten ausführen: sdelete.exe -z c:. Dieser Prozess dauert je nach Geschwindigkeit des zugrunde liegenden Datenträgers etwas. Nach Abschluss sollte man das Betriebssystem herunterfahren und in sein Lieblingslinux booten.

Möglichkeiten

In meinem Fall waren nach dieser Aktion noch ca. 96GiB Nutzdaten (inkl. Betriebssystem) vorhanden, auf einem Datenträger mit einer Kapazität von 250GB. Die Frage, die sich mir nun stellte, war, wie viel Platz benötige ich tatsächlich um die Bruttodatenmenge, also die Kapazität vom Datenträger, als Image zu sichern. Zur Auswahl standen für mich dabei 2 Verfahren:

Nun stelle sich für mich die alles entscheidende Frage: Was ist der Größen und Zeitunterschied zwischen Sparse File mit dd_rescue und lzop?

Sparse File

Mit dem Befehl dd_rescue -a -d -b 32M /dev/sdb sdb_backup.img erzeugte ich zuvor genanntes Sparse File, basierend auf dem Block Device /dev/sdb. Der gesamte Vorgang dauert bei meinem System 9 Minuten und 12 Sekunden, je nach Kombination aus HDD/SSD dauert dies mehr oder weniger lang. Das Ergebnis ist eine Datei die zwar mit 239GiB angegeben ist, aber nur 145 GiB auf dem Datenträger verbraucht:

[root@pc2007:/srv] 21s $ ls -l -h -s
145G -rw-r----- 1 root   root  239G 17. Jun 16:53 sdb_backup.img

LZO Compression

Der nächste Versuch war es mittels lzop < /dev/sdb > sdb_backup.image.lzo ein LZO Komprimiertes Images zu erzeugen. Dieses mal dauerte der Vorgang 10 Minuten und 7 Sekunden, ein marginaler Unterschied, wenn man bedenkt, dass noch eine Kompression der Daten durchgeführt wird. Das Ergebnis in diesem Fall ist eine Datei welche 107 GiB groß ist, also ca. 26% weniger Platz im Vergleich zum Sparse File benötigt:
[stefan:~] 10m32s $ ls -l -h -s /srv/sdb_backup.image.lzo 
107G -rw-r--r-- 1 root root 107G 17. Jun 17:17 /srv/sdb_backup.image.lzo

Fazit

Als kurzes Fazit lässt sich sagen das sich die Kompression mit lzop bewährt hat, vor allem weil ein derartiges Image auch auf Dateisysteme kopiert werden kann, die nicht Sparse fähig sind. Für mein neu geplantes Backup Konzept werde ich einen weiteren Blick auf die Kompression mittels LZO und LZ4 werfen, doch dazu später mehr. Mit anderen Kompressionsmöglichkeiten kann zweifelsfrei eine noch kleinere Datei (Image) erzeugt werden, der Zeitaufwand darf hierbei jedoch nicht unterschätzt werden.


Auswirkung der mkinitcpio Kompression

2016-10-28 12:07 | Kategorien: arch debian linux opensource software ubuntu

Schon länger war es etwas still in diesem Blog, diese stille möchte ich nun vertreiben und regelmäßig neue Beiträge für die digitale Nachwelt erstellen. Den Anfang soll hierbei ein kleines Experiment aus Dezember 2015 machen.

Konkret geht es um die Auswirkung der unterschiedlichen Kompressionsmöglichkeiten von mkinitcpio unter Arch Linux, die Ergebnisse sind aber auch auf andere Distributionen wie Debian, Ubuntu oder Fedora anwendbar. Die Idee ist es die Initial Ramdisk vom Linux Kernel so klein wie möglich zu bekommen, gleichzeitig aber auch die dafür erforderliche Zeit zu berücksichtigen.

Bei den angegebenen Zeiten wurde jeweils gemessen wie lange mkinitcpio -P benötigt um sowohl die Standard als auch die Fallback Ramdisk zu generieren, wir reden hier also immer von der Kompressionszeit. Die Zeit, welche für die Dekompression beim Systemstart erforderlich ist, wurde nicht explizit gemessen, erfahrungsgemäß liegen diese unabhängig vom verwendeten Algorithmus bei unter einer Sekunde.

KompressionFallback (MiB)Standard (MiB)Zeit (s)Prozent (%)
none804018.021100
gzip271419.78734
bzip2251338.67532
lzma188.467.25922
xz188.465.06922
lzop382013.15248
lz439208.67049
Addiert man die Größe, der unkomprimierten Fallback und Standard Ramdisk, kommt man auf 120 MiB, was so auch die 100% Marke in der Tabelle definiert. Wie unschwer zu erkennen ist steht none für keine Kompression.

Nachfolgend möchte ich die Ergebnisse meines Tests basierend auf meiner Erfahrung erläutern:

none
Man würde erwarten, dass keine Kompression am schnellsten ist, dies ist jedoch ein Trugschluss. Zwar wird keine Zeit für eine Kompression benötigt, im Gegenzug aber die Zeit für Plattenzugriffe drastisch erhöht. Ich würde aus diesem Grund davon abraten unkomprimierte Ramdisks zu verwenden.
gzip
Der alte Freund gzip erreicht brauchbare 14 MiB für die typischerweise genutzte Ramdisk, was ca. 20 Sekunden dauert. Wie erwartet gibt es hier keine großen Überraschungen. Insgesamt benötigen wir somit 41 MiB. Vorteil von gzip ist das bis auf wenige Ausnahmen wohl jede Linux Distribution damit umgehen kann.
bzip2
Auch bzip2 ist ein guter alter Freund, der jedoch in diesem Beispiel keine gute Wahl gewesen ist. Insgesamt benötigen wir damit ca. 38 MiB, also lediglich 3 MiB weniger bezogen auf gzip. Gleichzeitig benötigen wir für dieses geringe Ersparnis an Plattenplatz fast doppelt so viel Zeit, und das bei jedem Kernel Upgrade.
lzma / xz
Sowohl xz als auch lzma gelten als gute Kompressionsmöglichkeiten, benötigen dafür aber auch überdurchschnittliche Lange. Da die Kompression unverhältnismäßig lange dauert, würde ich vom Einsatz dieser für derartige Zwecke abraten.
lzop
Durch btrfs hat LZO, und damit auch lzop an Beliebtheit gewonnen. Der Ansatz ist es Daten möglichst CPU schonenden zu komprimieren und dadurch das Nadelöhr Disk-IO / Festplatte zu entlasten. Die Rechnung geht bei modernen Prozessoren voll auf, in der Regel ist die zusätzliche Belastung durch lzo kaum der Rede wert. Immerhin werden noch über 50% des Platzes eingespart, was für diese Anwendung ein brauchbares Ergebnis ist.
lz4
Das in letzter Zeit zunehmend beliebtere lz4 ist eine Art lzop mit Heckspoiler und Ralleystreifen, die Kompressionsraten sind in der Regel marginal schlechter, die Geschwindigkeit jedoch deutlich höher.

Für mich ist lz4 die Kompression der Wahl für die Initial Ramdisks, eine Ausnahme bilden Systeme auf denen /boot zu klein ist, dort dann je nach Verfügbarkeit xz oder lzma. Bei den heute verfügbaren Systemen mit schnellen HDDs oder SSDs spielt es keine wesentliche Rolle mehr, ob eine Datei 10 oder 20 MiB groß ist, die Zeit welche eine Kompression oder Dekompression benötigt jedoch schon. Insbesondere bei Arch Linux gibt es öfters neue Kernel Versionen, dort stets über eine Minute auf die Kompression zu warten ist in meinen Augen nicht Verhältnismäßig. Hohe Kompressionsraten sollte man wählen, wenn Platz und Bandbreite knapp ist, in anderen Fällen kann man pauschal lz4 oder lzop auf das Problem werfen ohne sich groß sorgen über die Konsequenzen machen zu müssen.

Der Artikel erläutert bewusst nicht genau, wie man die verwendete Kompression umstellt, die unterstützten Kompressionsmöglichkeiten unterscheiden sich je nach Kernel Version und Distribution erheblich, eine falsche Auswahl führt sofort zu einem nicht mehr startenden System. Die oben genannten Ergebnisse wurden Ende 2015 ermittelt, die ermittelten Zeiten und Dateigrößen sind also nur als Richtwert zu verstehen.


Google mag Flash

2015-11-04 18:14 | Kategorien: arch debian linux opensource sicherheit software ubuntu windows

Schon seit einigen Jahren gibt es auf PCs, die ich hauptsächlich benutze, kein installiertes Flash mehr. Wirkliche Einschränkungen hat man dadurch nicht, denn Youtube und gängige Videodienste haben gelernt, wie man mit HTML5 und modernen Browsern umgeht.

Der Verzicht auf Flash ist vor allem ein Sicherheitsvorteil, den noch besser als Click to Play ist es keinerlei Flash Installation zu haben. Zum einen spart dies Updates, zum anderen ist man oft nicht schnell genug in der Lage für das jeweils aktuelle Zero Day Exploit überhaupt einen Patch zu bekommen.

Obwohl viele Unternehmen den Sprung von Flash hin zu besserer Technik geschafft haben, fällt mir vor allem auf das Google noch lange nicht so weit ist. Einige Google Dienste, allem voran Google Finance oder Google Play Music erfordern nach wie vor Flash. Bei Google Finance bekommt man z.B. ohne installiertes Flash nur relativ langweilige Graphen:

Schlimmer sieht es aber bei Google Play Music aus: Der Dienst kann ohne aktiviertes Flash Plugin derzeit keine Musik abspielen, was die Nutzung des Dienstes für sicherheitsbewusste Anwender auf die vorhandenen Smartphones und Tablets beschränkt. Ich denke Google hat hier noch einiges an Hausaufgaben zu machen.


Defekte Festplatten im Linux Software RAID ersetzen

2015-09-06 09:00 | Kategorien: arch debian hardware homeserver linux opensource software ubuntu

In einer idealisierten Welt würden Festplatten nicht ausfallen, aber in der Realität müssen wir damit Leben das von Menschen geschaffene Dinge auch mal kaputt gehen. Ärgerlich ist dies vor allem bei Datenträgern, um hier einen Ausfall zu kompensieren werden auch im SOHO-Bereich zunehmend RAID-Systeme verbaut. Eine gerne verwendete Lösung ist hierbei das in Linux integrierte Software-RAID, es ist zuverlässig und erfordert keinerlei spezielle (und damit teure) Hardware.

Vorwort

Um ein RAID mit einer oder mehreren defekten Platten wieder in den gewünschten redundanten Status zu bekommen sind bestimmte Aktionen erforderlich, diese möchte ich nachfolgend erklären. Wie bei allen Operationen am laufenden System sollte man aber vorher sicherstellen das ausreichend aktuelle und funktionierende Backups vorhanden sind. Wer die nachfolgenden Operationen nicht aus dem bestehenden System heraus ausführen möchte, kann dafür auch eine der vielen Rescue Systeme nehmen, je nach Distribution und verwendeter Hardware kann dies sogar erforderlich sein. Der Vorteil eines Rescue Systems ist das man nicht auf die Bootfähigkeit seines Systems angewiesen ist, um nachträglich noch Korrekturen durchführen zu können.

RAID Status

Den Status eines RAIDs können wir mittels cat /proc/mdstat prüfen:

Personalities : [raid1] 
md0 : active raid1 sdc1[0] sda1[2]
      976628736 blocks super 1.1 [2/2] [UU]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Auf meinem Homeserver ist natürlich alles bestens, wenn eine Platte ausgefallen wäre, würde man in der dritten Zeile statt [UU] ein [U_] oder [_U] sehen, eine ausgefallene Platte wird durch ein _ dargestellt. Wie viele Festplatten ausfallen dürfen, hängt vom verwendeten RAID-Level ab.

Neben dem offensichtlichen Ausfall einer Platte gibt es aber auch noch den schleichenden Tod, dazu zählen z.B. auch die S.M.A.R.T. Werte und Selbsttests einer Festplatte. Gefallen einem die Werte seiner Festplatte nicht mehr kann man diese manuell auf den failed Status setzen:

mdadm /dev/mdX --fail /dev/alt1

Defekte Platten aus dem Verbund entfernen

Im Anschluss können alle Festplatten mit diesem Status aus dem Verbund entfernt werden:

mdadm /dev/mdX --remove failed

Defekte Platte tauschen

Im nächsten Schritt muss die defekte Festplatte aus dem System entfernt werden (physikalisch), dies geht einfach, wenn ein Wechselrahmen mit LEDs vorhanden ist. In diesem Fall genügt es einfach etwas Aktivität auf dem RAID zu erzeugen, die defekte Festplatte ist diejenige, bei welcher die Aktivitäts-LED unbeeindruckt bleibt.

Schwerer wird es, wenn kein derartiger Wechselrahmen vorhanden ist, den dort hilft es oft nur durch smartctl -i /dev/alt1 die Seriennummer der Platte auszulesen und mit dem Aufdrucken auf der Platte zu vergleichen. Wer etwas Feingefühl hat, kann auch mit den Fingern die Platten bei Aktivität erfühlen, eine inaktive Platte brummt gleichmäßig vor sich hin, eine aktive Platte vibriert passend zur ausgeführten Aktion. In jedem Fall sollte es vermieden werden den Server auszuschalten, den nicht jede Distribution fährt mit einem unvollständigen RAID wieder hoch.

Wurde die alte Platte entfernt, kann die neue Platte an das System angeschlossen werden, hierzu genügt zur Not auch ein externes USB-Gehäuse. Eleganter ist natürlich wieder der Wechselrahmen, schneller als USB geht zur Not auch das öffnen des Gehäuses und direktes anschließen der Platte an das Mainboard und Netzteil, zumindest sofern noch ein SATA-Anschluss vorhanden ist.

Partitionierung

Der nächste Schritt ist es die frisch eingebaute Platte mit einer Partitionstabelle zu versehen, da wir faul sind, lassen wir dies natürlich automatisch durch geeignete Tools erledigen:

# MBR/BIOS Partitionstabellen:
sfdisk -d /dev/master | sfdisk /dev/neu
# GPT/UEFI Partitionstabellen:
sgdisk -R /dev/neu /dev/master
sgdisk -G /dev/neu

Im oben genannten Codeblock ist /dev/master eine Platte mit passender Partitionierung, da bei einem RAID meist alle Platten gleich Partitioniert sind, kann jede aus dem Verbund als Master genommen werden. Die Festplatte /dev/neu ist die neue Festplatte. Zu beachten ist natürlich auch, ob GPT oder MBR für die Paritionstabellen verwendet wird.

RAID wiederherstellen

Wenn die Partitionstabellen passend sind, kann man die neue Platte auch schon dem vorhanden RAID-Verbund hinzufügen:

mdadm /dev/mdX --add /dev/neu1

Damit wären alle Arbeiten erledigt, das RAID führt nun einen sog resync durch, das bedeutet, die neue Platte wird mit den Daten bespielt und im Anschluss wäre unser RAID auch wieder redundant. Der resync kann mittels cat /proc/mdstat beobachtet werden. Wenn auf der ausgefallenen Platte auch ein Bootloader installiert war, sollte dieser auch wieder installiert werden, was je nach Bootloader unterschiedlich funktioniert und außerhalb des Umfangs dieses Artikels ist.