Option für den dd - Befehl

[khs]

]Ja schon klar, gehe aber davon aus, daß höchstwahrscheinlich nur Nullen im freien Bereich
nicht gesichert sind.

Hatte dazu von einem gparted einer älteren Live-CD schon mal eine Warnung mit den Details
laut angehängtem Screenshut bekommen. Dabei wurde dann der belegte und freie Speicherplatz
gar nicht angezeigt.
Komischerweise hat da das gparted einer aktuelleren Knoppix 7. keine Warnung erzeugt.
Habe jedenfalls vor, daß ich beim verkleinern der Partition und neupartitionieren den
fehlerhaften Bereich nicht belege.

Habe das Bild unter der Bezeichnung "gparted-Warnung" in der Galerie eingestellt,
wie das verlinken geht habe ich noch nicht raus.

Gruß
Hans

[eggy]

gzip kennt --fast, damit sollte er sich nicht mehr so lange an den nicht-Null-Daten aufhalten.

[MSfree]

Ja schon klar, gehe aber davon aus, daß höchstwahrscheinlich nur Nullen im freien Bereich nicht gesichert sind.

Wie kommst du auf diese Idee?
Dateisystem werden nicht von vorn nach hinten aufgefüllt. Leere Bereiche sind auch nicht mit Nullen gefüllt sondern mit Daten, die ehemals Dateien eingenommen haben, die jetzt gelöscht sind. Selbst ein frisch formatiertes Dateisystem besteht nur dann aus Nullen, wenn es eine fabrikneue Platte ist, oder wenn man sie vorher explizit mit Nullen füllt.

Letztlich ist deine Art der "Sicherung" auf jeden Fall mit Datenverlust behaftet und daher völlig sinnlos.

Wenn du nur das sichern willst, was tatsächlich durch Daten belegt ist, dann beschäftige dich mal mit rsync. Deine Versuche mit dd, so wie du das hier schilderst, werden im Notfall, wenn du das "Backup" wirklich mal brauchst, definitiv mit riesigen Krokodilstränen enden.

[eggy]

@MSfree: das mit den Nullen hängt von der Implementierung von defrag ab, wenn ich das richtig in Erinnerung hab, hatte das ganz alte ms(?) defrag mal ne Option für "verschobene Dateien auf der Platte nullen" statt dem normalen "schnellen" Modus "nur zusammenfassen". Kann mich aber irren, dann wirds nen anderes defrag gewesen sein, ist an die 20 Jahre her.
Aber wenn man den Ansatz weiterverfolgen will: sfill -z könnte weiterhelfen, sonst einfach ne sehr grosse Datei nach dem defrag per dd selbst nullen und wieder löschen.

Nichts desto trotz bleibts bei "Nur ein getestestes Backup ist ein Backup" und vielleicht doch lieber ein/zwei zusätzliche Platte/n kaufen.

[MSfree]

@MSfree: das mit den Nullen hängt von der Implementierung von defrag ab

Linux und defrag?

Aber wenn man den Ansatz weiterverfolgen will: sfill -z könnte weiterhelfen, sonst einfach ne sehr grosse Datei nach dem defrag per dd selbst nullen und wieder löschen.

Naja, das würde mir schlicht zu lange dauern. Wenn ich bei einem 1TB-Dateisystem, das zu 40% gefüllt ist, erstmal 600GB Nullen schreiben müßte, damit auch sicher alles genullt ist, würde ich doch vorher ein anderes Backupmittel verwenden, das sich nur um die 400GB sinnvolle Daten kümmert und das nach dem Urbackup inkrementell arbeitet.

Bei mir belegen z.B. im Moment 340 Vollbackups meines 2.5TB Datenbestands 6.5TB physikalischen Plattenplatz auf meinem Backup-NAS. Mit dd-Images wären das 850TB. gzip würde da fast nichts bringen, weil der größte Teil der Daten schon komprimiert ist (mp3, dep, mpeg2/4...).

Nichts desto trotz bleibts bei "Nur ein getestestes Backup ist ein Backup" und vielleicht doch lieber ein/zwei zusätzliche Platte/n kaufen.

dd ist meiner Meinung nach kein Backupwerkzeug. Daher sollte man das auch nicht für Backups einsetzen.

[Tintom]

Ja schon klar, gehe aber davon aus, daß höchstwahrscheinlich nur Nullen im freien Bereich
nicht gesichert sind.

Mangels Infos hier im Thread bin ich davon ausgegangen, dass die gesamte Festplatte partitioniert und die Partition(en) mit einem Dateisystem belegt ist/sind.
Sofern das zutrifft, verursacht dein vorzeitiger Abbruch beim Wiederherstellen mindestens ein beschädigtes Dateisystem eher jedoch besteht das Risiko eines Datenverlusts.

Wenn du nur das sichern willst, was tatsächlich durch Daten belegt ist, dann beschäftige dich mal mit rsync.

Die Frage war doch, wie man ein 1:1 Abbild einer Festplatte auf einer kleineren Festplatte sichert:

Mein Vorhaben wäre, den kompletten Inhalt einer 500er HDD, die mit weniger als 100 GB an Daten
belegt ist, 1:1 auf einer 120er HDD mit dem dd-Befehl zu sichern.

Bei mir belegen z.B. im Moment 340 Vollbackups meines 2.5TB Datenbestands 6.5TB physikalischen Plattenplatz auf meinem Backup-NAS. Mit dd-Images wären das 850TB. gzip würde da fast nichts bringen, weil der größte Teil der Daten schon komprimiert ist (mp3, dep, mpeg2/4...).

Ich lese den Eingangspost als "ich brauche eine Lösung wie ich einmalig ein Festplattenabbild mache". Von regelmäßigen Backups hat der TE hier nichts geschrieben.

dd ist meiner Meinung nach kein Backupwerkzeug. Daher sollte man das auch nicht für Backups einsetzen.

Das stimmt.

[eggy]

Linux und defrag?

1. Fragmentierung hängt nicht vom OS sondern vom Filesystem ab.
2. e2fsprogs bringt z.B. e4defrag mit, ob mans braucht, steht natürlich auf nem anderen Blatt.

Naja, das würde mir schlicht zu lange dauern.

Ich halt den Ansatz auch nicht für praxistauglich, aber solche Gedankenspiele sind doch ausreichend interessant und es gibt sicher einige Ansätze wie man sowas unter entsprechenden Vorgaben ("keine zusätzliche Hardware, rsync und co existieren nicht") bewerkstelligen könnte.

dd ist meiner Meinung nach kein Backupwerkzeug. Daher sollte man das auch nicht für Backups einsetzen.

Och, ich find schon, dass das nen super Backupwerkzeug ist, wenn ich ne 1:1-Sorglos-Kopie haben will (bzw dd-rescue, wenn man Lesefehler erwartet). Aber ja, in den meisten anderen Fällen gibts sinnvollere Alternativen.

[MSfree]

Och, ich find schon, dass das nen super Backupwerkzeug ist, wenn ich ne 1:1-Sorglos-Kopie haben will

Ich finde 1:1 Kopien nur extrem bedingt sinnvoll.

Wenn ich einen Hardwaredefekt habe, wo ich ein Backup brauche, um das System wieder lauffähig zu bekommen, kann so eine Kopie in Ausnahmefällen sinnvoll sein. Bei einem System, das hochverfügbar sein muß, kann man so die Ausfallzeit minimieren, indem man einfach die Platte mit der dd-Kopie nimmt und die Hardware neu bootet. Hier wäre aber ein Raid-1, das praktisch ständig eine 1:1 Kopie "herstellt" die deutlich sinnvollere Variante, die zudem auch dann noch bootet, wenn eine der beiden Platten nicht mehr reagiert.

In den meisten Fällen ist aber eine Neuinstallation besser, weil man dann auch gleich die neueste Betriebssystemversion installieren kann und sollte. Bei meinem Jessieserver würde ich z.B. gleich mindestens Buster installieren. Wichtig ist, daß der Datenbestand aus einem Backup rekonstriuert werden kann, aber dieses Backup kommt bei mir definitiv nicht aus dd-Kopien, das wäre viel zu aufwändig und Platzfressend.

Wenn man es soweit kommen läßt, daß man dd-rescue einsetzen muß, hat man es verpaßt, sich rechtzeitig um Backups zu kümmern.

dd hat als Werkzeug auf jeden Fall seine Berechtigung, z.B. um Installations-ISOs auf USB-Sticks zu schreiben, oder auch, wenn man eine zu kleine Platte durch eine größere ersetzen will, und dd nimmt, um die alte Platte auf die neue zu klonen. Aber für Backupzwecke halte ich es für gänzlich ungeeignet.

[wanne]

dd ist das mit Abstand bescheuertste Tool:
Nochmal der Vergleich zu e2image:
Beide tools können raw-images Produzieren mit allen Daten die sich einfach wieder mit cp auf die platte schreiben lassen.
Vorteile e2image

• schneller
• belastet ssds weniger
• Weniger fehleranfällig
• Lässt sich besser mit gzip und co komprimieren

Vorteile dd
-
Ich finde da sollte Diskussion eigentlich rum sein.

dd hat als Werkzeug auf jeden Fall seine Berechtigung, z.B. um Installations-ISOs auf USB-Sticks zu schreiben, oder auch, wenn man eine zu kleine Platte durch eine größere ersetzen will

Auch dafür sind andere Tools besser geeignet. Hier ist cp das Tool, dass nur Vorteile aber keine Nachteile hat.

• Einfacher zu bedinenen
• Den meisten Nutzern eh schon bekannt.
• In manchen Fällen schneller. (Aber nie langsamer.)
• In manchen Fällen schonender vor allem wenn auf USB-Sticks geschrieben wird.

Wenn ich bei einem 1TB-Dateisystem, das zu 40% gefüllt ist, erstmal 600GB Nullen schreiben müßte, damit auch sicher alles genullt ist, würde ich doch vorher ein anderes Backupmittel verwenden, das sich nur um die 400GB sinnvolle Daten kümmert und das nach dem Urbackup inkrementell arbeitet.

Auf SSDs kannst du weitestgehend instant mit fstrim alle ungenutzten Teile nullen.

[MSfree]

Auf SSDs kannst du weitestgehend instant mit fstrim alle ungenutzten Teile nullen.

fstrim ist bei weitem nicht instantan. SSDs sind zwar in der Lage, mehrere Blöcke gleichzeitig zu nullen, aber nicht alle, denn das würde viel zu viel Strom ziehen.

Der Grund, warum es dennoch sehr schnell bei SSDs geht ist, daß SSDs ohnehin mit der Option Trim gemountet werden. Wenn man dann noch fstrim aufruft, führt das zu eine Null-Operation, weil nichts mehr zu nullen ist, und das muß natürlich schnell gehen.

[wanne]

Auf SSDs kannst du weitestgehend instant mit fstrim alle ungenutzten Teile nullen. fstrim ist bei weitem nicht instantan. SSDs sind zwar in der Lage, mehrere Blöcke gleichzeitig zu nullen, aber nicht alle, denn das würde viel zu viel Strom ziehen.

Der Grund, warum es dennoch sehr schnell bei SSDs geht ist, daß SSDs ohnehin mit der Option Trim gemountet werden. Wenn man dann noch fstrim aufruft, führt das zu eine Null-Operation, weil nichts mehr zu nullen ist, und das muß natürlich schnell gehen.

Die SSDs verändern nur ihr Mapping. (Alle Adressen zeigen auf den selben Nullblock. Genullt wird später. Das geht meist überraschend schnell. Gerne mal für 250GiB << 1s. (Nachdem zuvor voll belegt war.) Ich Nutze das gerne um VMs zu löschen. Funktioniert hervorragend.

[khs]

Danke für die Antworten.
Damit das ganze nicht zu stark ausufert, noch mal ein paar Infos.
Die Platte ist keine SSD, eine normale Sata.
Darauf ist ein Win7 mit einem regulären MS-Office,
falls einmal was mit Linux nicht gehen sollte oder ein Ms-O
erforderlich wäre.
Vor dem sichern hatte ich mit Win defragmentiert,
mit Linux eine Datei mit lauter Nullen erzeugt
diese dann auf dem freien Bereich vervielfacht
dann gesichert bis zum Abbruch
Hatte auch früher mit anderen Sicherungswerkzeugen Abbruch vermutlich an der gleichen Stelle
Von e2image und dd-rescue habe ich noch nichts gehört
Die Sicherung soll nicht hauptsächlich eigene Daten sichern, sondern zur Wiederhertstellung des
Win falls es einmal nicht mehr booten sollte-
Hat sich eigentlich schon jemand den Screenshut in der Galerie angeschaut?
Geplant ist einmal die große letzte Partition zu verkleineren,
Neue Partitionen anzulegen,
das Win7 updaten auf Win10, weiß aber jetzt noch nicht ob dabei das MS-Office erhalten bleibt.

Gruß
Hans