neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Diskussion rund um unser Wiki.
Antworten
Benutzeravatar
ThorstenS
Beiträge: 2798
Registriert: 24.04.2004 15:33:31

neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ThorstenS » 04.08.2010 17:17:19

Hi Leute,
da ich gerade wieder einen Rechner mit Debianpv 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

Benutzeravatar
Saxman
Beiträge: 4178
Registriert: 02.05.2005 21:53:52
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: localhost

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von Saxman » 11.09.2010 09:01:19

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.

Benutzeravatar
cirrussc
Beiträge: 6567
Registriert: 26.04.2007 19:47:06
Lizenz eigener Beiträge: MIT Lizenz

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von cirrussc » 25.10.2011 20:34:15

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.
  1. 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.
  2. 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?
  3. 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?
  4. 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.
Wenn Du nichts dagegen hast, ändere und erweitere ich zu gegebener Zeit noch einiges. Das sollte doch im Sinne des Wikis sein, oder?
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl

Benutzeravatar
ThorstenS
Beiträge: 2798
Registriert: 24.04.2004 15:33:31

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ThorstenS » 25.10.2011 22:36:14

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.

wanne
Moderator
Beiträge: 5590
Registriert: 24.05.2010 12:39:42

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von wanne » 01.07.2013 21:22:26

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:
  • 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)
Hier mal ein Test mit meiner 285MB boot-Partition auf einem Dualcore:

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
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.
rot: Moderator wanne spricht, default: User wanne spricht.

wanne
Moderator
Beiträge: 5590
Registriert: 24.05.2010 12:39:42

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von wanne » 01.07.2013 22:05:34

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.

Benutzeravatar
ThorstenS
Beiträge: 2798
Registriert: 24.04.2004 15:33:31

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ThorstenS » 18.07.2013 09:38:01

Ich hatte die Tage Debianpigz ins Rennen geworfen, weil es ein paralleles gzip darstellt und für mich die schnellste Art ist images einzudampfen.
Setz deine Ideen ruhig um!

wanne
Moderator
Beiträge: 5590
Registriert: 24.05.2010 12:39:42

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von wanne » 18.07.2013 22:45:34

Hi, ist doch schon eingebaut. Oder?
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
ThorstenS
Beiträge: 2798
Registriert: 24.04.2004 15:33:31

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ThorstenS » 19.07.2013 22:50:12

jo, pigz hab ich eingebaut.

ChronoBoost
Beiträge: 140
Registriert: 29.01.2013 11:03:50

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ChronoBoost » 19.07.2013 23:11:18

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.

wanne
Moderator
Beiträge: 5590
Registriert: 24.05.2010 12:39:42

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von wanne » 19.07.2013 23:20:43

lzop ist zuminest mit dem standardlevel -3 wirklich beintruckend:

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
Ist halt leider auch ein recht komisches Format.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
ThorstenS
Beiträge: 2798
Registriert: 24.04.2004 15:33:31

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ThorstenS » 21.07.2013 11:47:17

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.

wanne
Moderator
Beiträge: 5590
Registriert: 24.05.2010 12:39:42

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von wanne » 21.07.2013 23:56:27

ThorstenS hat geschrieben:wie schauts mit den resultierenden Größen aus?
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.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
ThorstenS
Beiträge: 2798
Registriert: 24.04.2004 15:33:31

Re: neuer Artikel Vollständiges_Sichern_einer_ganzen_Platte

Beitrag von ThorstenS » 23.07.2013 19:31:55

*patsch* danke, mein PatternMatching ist manchmal verbesserungswürdig. :roll:

Eine Gegenüberstellung von den diversen Kompressionsverfahren (inkl. multicore Unterstützung) ist in jedem Fall ein guter Vorschlag.

Antworten