Ovion schriebKann man mit LVM-Snapshots (oder anderen Möglichkeiten) ein dd bei laufendem System realisieren?
Können ja, in der Praxis gibts aber böse Abzüge in der B-Note (gerade von wegen "schnell und elegant"...)
Nein, ein dd-Imageabzug ist wohl das unökonomischste was es gibt, da ist ja das alte dump/restore um Lichtjahre fortschrittlicher. dd ist absolut sinnvoll, wenn es drum geht ein wirkliches 1:1 Abild eines Blockdevices zu haben, z.B. für forensische Analyse oder Datenrettung ohne das Originalmedium weiter zu beanspruchen.
Aber nicht als Backup. Ein Blockabbild von 6TB, welches gerade mal mit 1TB belegt ist, daß will man mit dd nicht anfassen. Und wenn sich das Abbild nicht mehr zippen läßt (zusätzliche Fehlerquelle!) da im ungenutzte Bereich eben keine "Nullen" mehr sind - dann stehst du am Ende wirklich mit einer 6TB Imagedatei da. Wohin damit? Wie lange dauert das Übertragen auf das Backupmedium/rechner?
Und ich bin kein Freund von Image-basierenden Lösungen, gerade nicht für Datensicherung. Das kommt aus dem frühen Windows-Zeitalter, wo Win-Interna es icht möglich machen/machten alle Dateien zu sichern. Also gab es die (teils propritären) Imageabzüge. Nein, im Ernst - ich habe die ganzen jahre bei keinem "user" eine solche Lösung gesehen, wo es sich lohnte ein irgendwann mal mit viel Elan angefertigtes Image noch zurückzuspielen - um darauf aufbauend ggf, wieder zum gerade verlorenene System zu kommen.
Ich bevorzuge definitiv Lösungen, wo ich im Fall der Fälle (bei der *Rück*sicherung) möglichst einfach und universell an alle oder Einzeldaten rankomme. Ein tar-Archiv mag noch angehen (aber ich brauche eben entweder Platz zum Entpacken oder genug RAM am Backuprechner um socl ein Archiv handhaben zu können).
Ein rsync/cpdup-Lauf (das ökonomischste auf der Quellseite, gerade wenn die Sicherung regelmäßig wiederholt werde soll) läßt sich im Problemfall mit jedem Kopiertool auf datei/Verzeichnisebene wieder zurückspielen - ohne Fragmentierugen und ohne daß (wie bei dd!) Trillionen von "Nullen bzw. Nulldaten") zurückgespielt würden.
Hauptcrux ist IMHO immer noch, daß die meisten Systeme daran kränkeln eben Blockdevices "fester Größenvorgabe" zu haben (egal ob jetzt physikalische Partitionen oder z.B. logische LVM-Volumes). Diese Trennung von Geometrie und Dateisystem verbietet es quasi sinvoll Daten unabhängig von der Struktur blockweise zu sichern/wiederherzustellen.
Erst die neue Generation von Dateisystemen macht das auch in punkto Backup sinnvoll, wenn eben Volumemanagement und Dateiablagesystem "aus einem Guß" sind. Aktuell ist das Paradepferd IMHO da ZFS, ob btrfs diese Möglichkeiten mittlerweile auch hat oder nur auf der Agenda weiß ich gerade nicht.
Mit ZFS (auf der Client- und Backuplösungs-Seite) wäre diese Aufgabe (Sicherung des/im laufenden Systems, um noch mal die Threadkurve zu kriegen <g>) ungefähr:
-Snapshot(punkt) erstellen (dauert ein paar Sekunden)
-zfs send pool/volume@montag (auf der Backupseite: zfs receive backuppool, nun ist die Sicherung über backuppool/volume@montag mountbar als Dateisystem).
Dieser Transport von send/receive erfolgt über Pipes (i.d.R. stdin/stdout), kann also z.B. übers Netzwerk mit netcat o.ä. quasi Bandbreiten-Brutto ohne Overhead erfolgen, oder auch über ssh usw.). Prinzipiell wichtig an dieser Art ist halt: es werden Daten rasant blockweise übertragen und eben nur Nutzdaten. Und da sowohl "Volumegröße" als auch Daten durch ein und das selbe Dateisystem sowohl auf der Quell- als auch auf der Zielseite transparent sind habe ich am Ende wieder mein komplettes Volume *und* die Einzeldateien zur Verfügung - ohne Zusatzaufwand/Tools/Risiken. U.a. dieses Feature wäre es mir wert, mich auch unter Linux mit zfs oder btrfs mal zu beschäftigen.
Ansonsten gilt halt:
* Jedes Backup ist besser als kein Backup (außer man ist so glücklich zu sagen: meine Date scheren mich nicht. Weg? Na und?)
* Backup/Datensicherung ist kein "Programm" sondern ähnlich wie Sicherheit ein Konzept.
* Die Sicherung sollte ökonomisch sein, zeitaufwand im Verhältnis zum Nutzen. Sonst macht man es nämlich nicht regelmäßig.
* Das Mensch sollte den Prozeß begreifen, und zwar nicht als Copy&Paste-Vorgang.
* Obiges gilt umso mehr für den viel wichtigeren Vorgang der Datenrückspielung - etwas, was die meißten Anwender nie ausprobieren...