Backup einer Platte mit dd ?

Homwer

New Member
Hallo,
in meinem Setup habe ich zwei SSD (sda, sdb) als md0 (Boot) (sdd, sdc) md1 (/) und zwei drehende Platten als md2 (Daten)

Vor einem größeren Upgrade des Systems würde ich gerne ein Backup der ganzen Platte machen, statt wie üblich nur der Daten, so dass ich bei Problemen einfach alles zurückspielen kann.

Daher die Frage, ist dd eine valide Möglichkeit? Ich würde dann einfach die komplette SSD (sda) per dd als image sichern, das müsste man dann doch einfach zurück spielen können wenn es Probleme gibt, oder?
 

d3p

Blog Benutzer
Ich würde dann einfach die komplette SSD (sda) per dd als image sichern, das müsste man dann doch einfach zurück spielen können wenn es Probleme gibt, oder?
Theoretisch könnte das klappen.
Das steht und fällt mit den jeweiligen Services die darauf laufen.

Läuft da eine Datenbank drauf und du sicherst die Kiste via dd, ohne dass die Datenbank einen konsistenten Stand hat, bringt dir das nichts.
 

d4f

Müder Benutzer
Falls es nicht bereits so geplant ist - das dd-Image lässt sich generell gut mit "pigz" (gzip mit multithreading) komprimieren.
 

DeaD_EyE

Blog Benutzer
Boote vom Rescue-System, dann kannst du die Platten sichern. Das remounten in read-only funktioniert nicht, solange Prozesse auf das FS zugreifen. Im Betrieb ist das nicht möglich. Das Backup vom Rescue-System aus zu machen, ist besser.
 

Joe User

Zentrum der Macht
Warum zum Teufel will man sein Backup völlig unnötig mit "freiem Speicherplatz" aufblähen und obendrein auch noch potentielle Filesystem-Schäden/-Bugs wiederherstellen und damit das Backup ad absurdum führen?


dd ist kein Backup-Tool, noch nie gewesen und wird es niemals sein!


Ein richtiges Backup beinhaltet ausschliesslich Nutzdaten und grundsätzlich auf einem frisch installiertem und konfiguriertem System eingespielt.
 

Homwer

New Member
Danke für die Hilfreichen Antworten.
Schade dass @Joe User wohl keine Zeit hatte den Beitrag zu lesen und zu verstehen.

Habe mir ein Backup der Platte Offline gemacht und das zurückspielen auf einer anderen Platte ausprobiert. Funktioniert ohne Probleme. Das anschließende Upgrade des Systems auf das aktuelle Debian lief danach problemlos so dass ich das Backup nicht brauchte.
 

DeaD_EyE

Blog Benutzer
Er hat aber schon Recht. Probleme die das FS hat, kopierst du einfach mit. Die Abstraktionsschicht des FS kümmert sich darum, dass die Daten, die du bekommst, auch Konsistent sind. Die Logik gibt es bei dd nicht. Das kopieren vom FS geht auch schneller, als mit dd.

Ist so ähnlich wie ein Script, welches Backups von Datenbanken anlegt, der Inhalt des Backups aber nie geprüft wird.
Man freut sich dann beim Wiederherstellen des kaputten Backups. Da haben schon einige Admins eine hässliche Überraschung erlebt.

Check wenigstens das FS vorher nochmal, bevor du ein "Backup" mit dd machst.
Am besten sind die Tools, die nach dem Kopieren feststellen, ob auch das geschrieben worden ist, was gelesen wurde.
Somit lassen sich Überaschungen vermeiden.

Borgbackup ist z.B. recht bekannt.
Das komplette OS zu sichern soll laut DevOps auch falsch sein. Dafür hat man Tools wie Ansible, Puppet usw.
Richtig konfiguriert können dir die Tools einen kompletten Webserver + DB + EMail einrichten. Das hat den Vorteil, dass man es nur einmal richtig machen muss :-D
 

d4f

Müder Benutzer
Ich mag die hier beschriebene Theorie der automatischen Einrichtung sehr, in der Annahme dass es um Privatserver geht ist das aber oft kein gangbarer Weg. Genau wie man (meistens) für private Bastelprogramme keine Test-Cases entwirft tut man (=ich) das auch für private Bastelserver nicht.

Ein Vollbackup des Systems hat gewisse Nachteile aber auch den Vorteil dass es garantiert known-working ist. Solange das Backup selber nicht schiefgelaufen ist wird eine exakte Rückspielung wieder genau den Stand des Backups wiederherstellen. Sofern es möglich ist sollte man applikationsbasierte Backups zumindest zusätzlich machen. In diesem Fall sehe ich die Grundidee des TE nicht als absolutes no-go an.

Persönlich bevorzuge ich aber zusätzlich Applikation und Hardware zu trennen weil es unter anderem Migration und Performance vereinfacht. In diesem Fall könnte man von dem meistens zugrunde liegenden LV einfach einen Snapshot erstellen. Praktisch wenngleich nicht technisch ist das Resultat aber äquivalent zu einem Vollbackup hier...
 

killerbees19

★ ①③ ④ⓑ ✛ ␀
Das kopieren vom FS geht auch schneller, als mit dd.
Kommt drauf an. Wenn Deine HDD relativ voll ist und hauptsächlich kleine Dateien drauf liegen, wird dd ganz klar gewinnen. :D

Für ein "schnelles" Backup vor solchen Upgrades ist ein vollständiges Image mMn nicht verkehrt. Das geht relativ einfach, schnell und lässt sich problemlos zurückspielen. Ich persönlich lege aber keine HDD-Images mehr an, ohne eine SHA-Prüfsumme zu berechnen und nachher zu vergleichen. Im Idealfall in zwei Durchgängen, damit wirklich nochmals alle Daten verarbeiten werden müssen.

Dass man zusätzlich noch ein anderes Backup haben sollte, ist natürlich immer zu empfehlen.
 

DeaD_EyE

Blog Benutzer
Keine Unit-Tests? Oh ganz böse... Ich habe aber auch ganz oft gesündigt.
Solange die Tools klein sind, hat es kaum einen nutzen.

Wichtig wird es, wenn das Projekt weiter entwickelt wird und man verhindern will, dass es knallt.

Die Tools zur Automatisierung nutze ich selber auch nicht,
da ich nur einen Server habe und den nicht alle Monate neu einrichte.

Gibt es eigentlich Tools, die man mit dd pipen kann und dann z.B. auf stderr den Hash bekommt (ähnlich wie tee)?
Ich könnte mir das auch selbst programmieren, aber vielleicht gibt es da ja was fertiges.
 

Whistler

Blog Benutzer
Ich bevorzuge in solchen Fällen auf "echtem Blech" Acronis. Das macht im Prinzip ein byteweises Backup, ist aber "filesystem-aware" und läßt freie Sektoren aus. Zudem kann man das Backup wahlweise noch verschlüssen und komprimieren.
In virtualisierten Umgebungen ist mein Favorit Veeam, das kann per Change-Block-Tracking zusätzlich noch sehr kompakte Delta-Backups anlegen.
Mit einem entsprechenden Filesystem wie z.B. BTRFS (das neue SuSE-Default-Filesystem) kann man übrigens auch direkt Snapshots anlegen und dann z.B. nach einem mißglücktem Upgrade vom GRUB aus auf einem vorhergehenden Zustand booten.
 

Top