neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Hi Leute,
da ich gerade wieder einen Rechner mit pv vollständig sichere, habe ich meine Doku dazu ins Wiki übertragen und auf der Startseite unter Grundsatzfragen verlinkt (ebenso den Bacula-Artikel ): http://wiki.debianforum.de/Vollständige ... zen_Platte
Die Erweiterung wäre noch wie man gzip -2 in die pipe schleust, damit bei potenteren Rechnern die Datenrate steigt und das Image weniger Platz verbraucht.
Ich habe den Artikel nur noch in keine Kategorie eingeteilt. Mir würde spontan Grundlagen, backup und Migriert einfallen. Wie sehr ihr das?
da ich gerade wieder einen Rechner mit pv vollständig sichere, habe ich meine Doku dazu ins Wiki übertragen und auf der Startseite unter Grundsatzfragen verlinkt (ebenso den Bacula-Artikel ): http://wiki.debianforum.de/Vollständige ... zen_Platte
Die Erweiterung wäre noch wie man gzip -2 in die pipe schleust, damit bei potenteren Rechnern die Datenrate steigt und das Image weniger Platz verbraucht.
Ich habe den Artikel nur noch in keine Kategorie eingeteilt. Mir würde spontan Grundlagen, backup und Migriert einfallen. Wie sehr ihr das?
Zuletzt geändert von Danielx am 13.09.2010 09:08:17, insgesamt 1-mal geändert.
Grund: Link verbessert
Grund: Link verbessert
- Saxman
- Beiträge: 4215
- Registriert: 02.05.2005 21:53:52
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: localhost
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Ich bin gerade über den Artikel gestolpert und habe ihn als frei zum Review in die Artikelübersicht eingetragen.
"Unix is simple. It just takes a genius to understand its simplicity." - Dennis Ritchie
Debian GNU/Linux Anwenderhandbuch | df.de Verhaltensregeln | Anleitungen zum Review und zum Verfassen von Wiki Artikeln.
Debian GNU/Linux Anwenderhandbuch | df.de Verhaltensregeln | Anleitungen zum Review und zum Verfassen von Wiki Artikeln.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Ich habe mir den auch mal zu Gemüte geführt und gleich etwas auszusetzen
Hab' das mal kurz in die Diskussion zur Seite geschrieben.
Hab' das mal kurz in die Diskussion zur Seite geschrieben.
- Die Empfehlung, dd als Blockgröße die Zylindergröße aufzuschultern ist sicher unschön und in Bezug auf Advanced Format Laufwerke sogar hinderlich (beim Lesen sicher weniger). Ich würde vorschlagen, dass auch ein vielfaches der 512 Byte zu beschränken und das etwas umfangreicher zu erläutern.
- Der Befehl zum Satz "Der folgende Befehl gibt dir die Blockgröße deiner Festplatte (hier /dev/sda) aus" ist insofern falsch, dass hier die Zylindergröße und nicht die Blockgröße ausgegeben wird. Dann noch nötig?
- Als Erweiterung fällt mir noch die Behandlung beschädigter Datenträger ein. So zusagen eine forensische Sicherung. Oder sollte das eher in einen anderen ausgelagert werden?
- Ist es nicht quasi Konvention hier, die Artikel in der 3. Person zu formulieren? Ich glaube das mal in dem großen Thread gelesen zu haben.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
da brauchst du gar nicht zu fragen - natürlich darfst du das alles ändern. Die Weiterentwicklung ist doch Sinn und Zweck von öff. Wikis.
Der Artikel ist vom Stil her sicherlich anders als andere hier, weil er schon älter ist und aus meinem privaten (geschlossenen) Wiki stammt.
Der Artikel ist vom Stil her sicherlich anders als andere hier, weil er schon älter ist und aus meinem privaten (geschlossenen) Wiki stammt.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Hi, ich würde gerne die bzip2 Komponenten rauswerfen und durch gzip eretzen und vielleicht unten bei Komprimierungsfaktor maximieren vielleicht ein verweis auf xz einfügen.
Meiner Meinung nach ist bzip2 mittlerweile in allen Kategorieen geschlagen:
Ansonsten sollte vielleicht noch rein das man das auch mit Partitionen machen kann und ich würde gerene ein paar unnötige pipes/dds entfernen.
Meiner Meinung nach ist bzip2 mittlerweile in allen Kategorieen geschlagen:
- bz2 hat immernoch wenig verbreitung. => Viele kennen die dateiformate nicht.
- bzip2 ist ist sehr langsam. Die kompressionsgeschwindigkeit lässt sich auch nur sehr schlecht duch viele Kerne hochtreiben. Selbst mit einem Quadcore ist gzip wesentlich schneller und nutzt dann nebenbei nur einen Kern. pxz überholt bei vielen Kernen pbzip2 irgend wann. (Allerdings wird der RAM verbrauch dann auch exorbitant.)
- Der Kompressionsfaktor ist nur bei wenigen Dateiformaten wie (UTF-8) Textdateien wirklich merklich besser als der von gzip. xz bitet in mit -1 aber bei wesentlich bessere Kompression bei ähnlicher Geschindigkeit. Und bei der Rate ist mit höheren leveln luft nach oben.
- Das enpaken ist sehr Rechen und speicherintensiv. Die anforderungen für xz oder gzip sind da ein klacks dagegen. (Das ist allerdings eher uninteressant für Backups)
Code: Alles auswählen
# cat /dev/sdb8 | pbzip2 -p1 -c | dd if=/dev/stdin > /dev/null #ein Kern
124529267 Bytes (125 MB) kopiert, 61,8506 s, 2,0 MB/s
# cat /dev/sdb8 | pv -rtb | pbzip2 -c | dd if=/dev/stdin > /dev/null #mit 2 Kernen bei weitem nicht doppelt so schnell.
125777458 Bytes (126 MB) kopiert, 36,3357 s, 3,5 MB/s
# cat /dev/sdb8 | gzip | dd if=/dev/stdin > /dev/null #gzip ist viel schneller
124679526 Bytes (125 MB) kopiert, 10,4256 s, 12,0 MB/s
#bei -1 siehts ähnlich aus
# cat /dev/sdb8 | gzip -1 | dd if=/dev/stdin > /dev/null
125996039 Bytes (126 MB) kopiert, 8,68391 s, 14,5 MB/s
# cat /dev/sdb8 | pbzip2 -c -1 | dd if=/dev/stdin > /dev/null
124976463 Bytes (125 MB) kopiert, 23,811 s, 5,2 MB/s
#pxz komprimmiert wenigstens Besser. Iat aber auch langsamer:
# cat /dev/sdb8 | pv -rtb | pxz -c -1 | dd if=/dev/stdin > /dev/null
122696320 Bytes (123 MB) kopiert, 48,4016 s, 2,5 MB/s
# cat /dev/sdb8 | pv -rtb | pxz -c | dd if=/dev/stdin > /dev/null
120120636 Bytes (120 MB) kopiert, 71,548 s, 1,7 MB/s
rot: Moderator wanne spricht, default: User wanne spricht.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Achso ich habe noch ein paar sachen in die Diskussion geschrieben. guckt's euch mal an und sagt was ihr davon haltet.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Ich hatte die Tage pigz ins Rennen geworfen, weil es ein paralleles gzip darstellt und für mich die schnellste Art ist images einzudampfen.
Setz deine Ideen ruhig um!
Setz deine Ideen ruhig um!
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Hi, ist doch schon eingebaut. Oder?
rot: Moderator wanne spricht, default: User wanne spricht.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
jo, pigz hab ich eingebaut.
-
- Beiträge: 140
- Registriert: 29.01.2013 11:03:50
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Wenn's richtig schnell gehen soll und die Stärke der Kompression nicht eine übergroße Rolle spielt, dann wäre lzop auch noch eine Alternative.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
lzop ist zuminest mit dem standardlevel -3 wirklich beintruckend:
Ist halt leider auch ein recht komisches Format.
Code: Alles auswählen
# cat /dev/sdb8 | pigz | dd if=/dev/stdin > /dev/null
127667271 Bytes (128 MB) kopiert, 7,83141 s, 16,3 MB/s
# cat /dev/sdb8 | pigz -1 | dd if=/dev/stdin > /dev/null
128859009 Bytes (129 MB) kopiert, 5,06084 s, 25,5 MB/s
# cat /dev/sdb8 | lzop | dd if=/dev/stdin > /dev/null
131745662 Bytes (132 MB) kopiert, 1,35464 s, 97,3 MB/s
# cat /dev/sdb8 | lzop -1 | dd if=/dev/stdin > /dev/null
131794551 Bytes (132 MB) kopiert, 1,31527 s, 100 MB/s
# cat /dev/sdb8 | lzop -8 | dd if=/dev/stdin > /dev/null
129620366 Bytes (130 MB) kopiert, 34,8043 s, 3,7 MB/s
rot: Moderator wanne spricht, default: User wanne spricht.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
wie schauts mit den resultierenden Größen aus?
Ich find pigz super, weil es auf meinem Virtualisierungsserver alle 8 Kerne ausnutzt und das Ergebnis trotzdem mit DEM Standardkompressionstool entpackbar ist. lzop schaue ich mir aber gerne mal an.
Ich find pigz super, weil es auf meinem Virtualisierungsserver alle 8 Kerne ausnutzt und das Ergebnis trotzdem mit DEM Standardkompressionstool entpackbar ist. lzop schaue ich mir aber gerne mal an.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
Steht doch da 132MB gegen 128MB von pigz. Ich werde das Beispiel auch so lassen, weil gz einfach super weit verbreitet ist. Aber viellicht gibt's eine Erwähnung im Abschnitt Kompression. Und vielliecht später mal einen vollständigen Benchmakr Artikel mit Kompression.ThorstenS hat geschrieben:wie schauts mit den resultierenden Größen aus?
rot: Moderator wanne spricht, default: User wanne spricht.
Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte
*patsch* danke, mein PatternMatching ist manchmal verbesserungswürdig.
Eine Gegenüberstellung von den diversen Kompressionsverfahren (inkl. multicore Unterstützung) ist in jedem Fall ein guter Vorschlag.
Eine Gegenüberstellung von den diversen Kompressionsverfahren (inkl. multicore Unterstützung) ist in jedem Fall ein guter Vorschlag.