Re: Tool für Images?
Am Mon, 7 Oct 2013 09:25:31 +0200
schrieb Bjoern Meier <bjoern.meier@gmail.com>:
> hi,
>
> da Michael sich im Tonfall annäherte, antworte ich ihm auch gern :)
Hurra! \o/
:-p
> Am 5. Oktober 2013 18:42 schrieb Michael Schmitt
> <tcwardrobe@gmail.com>:
>
> > Mit keiner Silbe sprach ich den Energiegehalt
> > an, weil dann wäre nen halbes Pfund pures Fett oder Zucker (je
> > nachdem welche Energie Du willst) das beste.
>
> Mit dieser Silbe schon, mein Bester:
> >> > Fastfood-Software!? Also erstmal grundlegend, der
> >> > "Nährstoffgehalt" ergibt sich *ausschließlich* aus dem
> >> > Verwendungsszenario
Gut, das is wahrlich etwas unvorteilhaft formuliert, aber daher ja auch
in Anführunsgzeichen gesetzt. Die Idee hinter der Aussage war eben
deutlich zu machen, daß andere Aufgaben, gerne andere Lösungswege
brauchen um am Ende nen "nahrhaftes" Endergebnis zu haben. Da können
die einzelnen "Nahrungsmittel" gerne ne miese Energieblilanz haben, das
Zile is dann dennoch enorm Energiereich oder "nahrhaft". Mal ganz
philosophisch, das Ganze is gerne mehr wie die Summe seiner Einzelteile.
> > Gesund definiert sich immernoch
> > durch ein möglichst breites Spektrum an Nährstoffen und nicht auf
> > eine einseitige Zurverfügungstellung einer (Nährstoff-) Komponente.
>
> Exakt. Darauf wollte ich doch hinaus. Das war der einzige Grund, warum
> ich Clonezilla als "Fastfood" bezeichnete. Du hast keine Kontrolle
> über das zugeführte Spektrum.
Was meinst Du da mit "Spektrum"? clonezilla (und partimage) machen was,
dd macht was, in keinen der beiden Abläufe füge ich was hinzu oder
fummel dran rum.
> Natürlich mag ich auch Burger gern, ab und zu muss das einfach sein.
> Doch im Alltag koche ich lieber - viel lieber - selber.
Ich bin so pervers, ich mach sogar Burger ab und an selbst! ;-)
Aber egal, wenn man unbedingt bei dem Vergleich zum Essen bleiben muß,
dann sehe ich clonezilla und Konsorten eher als gutes Gericht in nem
Restaurant und dd eben als das Brot was dazu oder davor gereicht
wird. Beides explizit nicht selbstgemacht, aber zumindest hätte ich
theoretisch die Möglichkeit bei dd und clonezilla dem "Koch" über die
Schulter zu gucken in dem ich in den source schaue.
> >> natürlich ist dd dumm-wie-brot. Das ist Mehl auch und deswegen
> >> genau so vielseitig einsetzbar wie dd.
> >
> > Kein Einwand.
> >
> >
> >> Dennoch würde ich ein selbst gebackenes Brot 10fach vor dem Burger
> >> vorziehen.
> >
> > Man ißt aber nicht nur einmal im Leben, sondern jeden Tag,
> > andauernd, sein ganzes Leben lang. Da wäre weder Brot noch nen
> > Burger geeignet um seinen Nährstoffbedarf damit zu befriedigen. Der
> > Mix machts, da tut auch nen Burger ned weh. Weil da is eh auch nur
> > drin was in anderen Lebensmitteln mit nem besseren Ruf auch drin
> > is, eben nur mit anderen Anteilen. Sprich, auch hier bleibts bei
> > der Logik, mal taugt das eine, mal das andere tool mehr. Wenn Du
> > nur dd brauchst, super, ich (und viele andere offenbar auch) finde
> > das tool eben nicht perfekt um z.B. Images einer Partition in jeder
> > Situation und Aufgabenstellung anzulegen.
> >
> >
> >> Wenn ich ein Backup mit dd mache, weiß ich wie und womit
> >> es gemacht wurde. Das ist bei mir Sinn und Zweck.
> >
> > Wenn ich nen Image mit clonezilla mache, weiß ich wie und womit es
> > gemacht wurde. Ich verstehe so gar nicht worauf Du da hinauswillst.
>
> Ok bei dd weiß ich, dass die Festplatte / Partition byteweise gelesen
> wird. Es werden keinerlei Information interpretiert, die irgendwie
> falsch interpretiert werden könnten.
Bei clonezilla weiß ich ähnliches. Es macht das ganze halt anders,
weils nen anderen Fokus hat. Es guckt was fürn Dateisystem es vor
sich hat und laßt dann z.B. ntfsclone (oder libntfs) bei
NTFS-Dateisyetemen seine Magie vollziehen. Sprich, es liest in dem Fall
die MFT (genauso wie ntfs-3g oder jeder andere NTFS-Treiber) und weiß
daher welche Blöcke es kopieren muß und welche nicht. So lange das NTFS
ned von MS mit nem neuen Feature erweitert wurde und ntfsclone das
nicht kennt, funktioniert das äußerst zuverlässig und stabil. Es
entledigt den Admin natürlich nicht von der Aufgabe selbst zu gucken ob
denn die verwendete ntfsclone Version mit dem aktuellen NTFS was es
beackern soll klar kommt (Doku / changelog lesen). Bei nativen
Linux-Dateisystemen isses ähnlich, es nimmt auch da die passenden libs
mit denen im Zweifel das FS angelegt oder gelesen wird, also
z.B. e2fslibs bei ext2. Das machts also generell so zuverlässig wie
lesen bzw. schreiben auf nen FS unter Linux generell.
> Ich weiß nicht, was Clonezilla
> interpretiert. Was ioch jedoch weiß, ist: dass ich die ersten Windows
> 7 Beta Maschinen mit dd sichern konnte und Clonezilla sich nicht dazu
> überreden ließ.
Kannst Du Dich noch genauer an das ganze Erinnern? Was genau ging
nicht? Imagen, restore, booten? Weil zumindest das letzte mal als ich
nen Win7-NTFS gesichert habe, hatte ich dazu partimage verwendet, was
zu meiner Überraschung (weil länger nicht mehr in aktiver Entwicklung)
super funktionierte. War von mir als eher als Test geplant, ich hatte
mich explizit nicht auf den Erfolg verlassen. Aber nunja, generll gehe
ich momentan eh eher in die clonezilla-Richtung, das wird aktiv
entwickelt.
> Also, wenn es sicher und exakt sein soll nehme ich dd. Weil dd stumpf
> alles sichert, egal was drauf ist. Clonezilla muss sich immer erst
> anpassen.
Klar, wenn ich ne 1:1 Kopie brauche, gewinnt dd, nur braucht man das
fast nie. Zumindest ich habe da keinerlei forensische Ansprüche, die
meisten anderen die so nen Anwendungsfall haben wohl auch nicht. Und
wie / wo muß sich clonezilla anpassen? Du meinst das nen clonezilla aus
2009 nicht mit z.B. btrfs klarkommt? Logisch, das liegt in der
Verantwortung des Admins und is fast nie nen wirkliches Problem.
> Für mich ist das wie Scripting. Alles gut solange es läuft, wenn aber
> Fehler auftreten, bin ich froh wenn ich ein Programm habe, dem ich mit
> gdb bei komme.
Da ich weder den code von dd noch von z.B. partclone.ntfs oder
ntfsclone verstehe (ich bin kein Programmierer), bin ich da eh je auf
den Maintainer bzw. upstream angewiesen. Is sicherlich manchmal
nachteilig, aber so isses halt. Ich habe auch nicht so die Ambitionen
das zu ändern, wobei so ganz ganz langsam... naja... vielleicht.
> >> Zumal bin ich
> >> mittlerweile, mit meiner VM die exakt in 4 sek. in die Konsole
> >> bootet (ein selbst definiertes und Kernel geschnitzeltes LFS) ,
> >> schneller als jede LiveCD die in 5 Minuten bereit ist.
> >
> > Und was hat das mit der ganzen Thematik zu tun? O_o
>
> Das war nur ein Beispiel, mit dem ich aufzeigen wollte, dass ich
> mittlerweile die Systeme mir anpasse. Das ist mir möglich, weil ich
> mich damit auseinander setze.
Wenns Spaß macht. Sicher gibt einem GNU/Linux da alle Freiheiten zur
Not auch mit nem Kochrezept ala LFS alles von Hand aufzubauen. Finde
ich persönlich eher von theoretischem Interesse, aber kaum praktisch
sinnvoll (für zumindest MEINE Anforderungen). Mir reichts vollkommen
z.B. mit debootstrap nen minimales System stricken zu können, zur Not
die initrd auseinandernehmen um nen LVM oder Crypt-Problem
nachvollziehen zu können, ich muß nicht alles selbst gemacht haben, das
geht ja auch so nen bissl dem Konzept einer Distro entgegen. Aber nun,
ich habe mich mit der Distribution auseinandergesetzt, so daß ich diese
im Zweifel verstehe und beherrsche.
> >> Das nur ist mir nur möglich, da ich mich nicht mit "Fastfood" (im
> >> Sinne von schnell mal was fremd entworfenes anwerfen) zufrieden
> >> gebe.
> >
> > Auch hier, was hat das mit der Gegenüberstellung dd vs. z.B.
> > clonezilla zu tun? Und, hast Du etwa dd selbst programmiert? Es
> > sind und bleiben beides Fremdtools, die je nen etwas anderen Fokus
> > haben, mit denen man aber zumindest bedingt hier und da ähnliches
> > anstellen kann.
>
> Gut der Begriff, war falsche gewählt. Clonezilla ist debian extern.
> Zumal fühle ich mich mittlerweile bei den GNU-Tools zuhause.
Selbst WENN es nicht in Debian wäre...
mschmitt@adrastea:~$ apt-cache policy clonezilla
clonezilla:
Installiert: (keine)
Installationskandidat: 3.5.2-2
Versionstabelle:
3.5.2-2 0
500 file:/mnt/mirror/debian/ sid/main i386 Packages
500 file:/mnt/mirror/debian/ testing/main i386 Packages
500 http://ftp.de.debian.org/debian/ sid/main i386 Packages
500 http://ftp.de.debian.org/debian/ testing/main i386 Packages
mschmitt@adrastea:~$
... nutzt man es eh idR von nem Live-System aus. So gibts das bei
diversen Debian-affinen Live-Sytemen ebenfalls. Mit was man sich
allerdings persönlich wohl fühlt, is natürlich nen anderes Ding und da
kann man kaum jemanden reinreden, nech? ;) Ich *vermute* aber mal ne
grundlegende Abneigung gegen so tools wie clonezilla bei Dir (warum
auch immer...), da machts das damit wohlfühlen natürlich unsagbar
schwer.
> >> Warum ich dd empfehle und nicht clonezilla? Ich bin davon
> >> überzeugt, dass man erst einmal die Standard-Tools einigermaßen
> >> sicher bedienen sollte können, denn wenn das "fastfood" mal rum
> >> zickt, hat man zumindest eine Ahnung wie man das beheben kann.
> >
> > Das sind zwei tools die NICHT voneinander abhängen. Ergo gibts auch
> > keinen Grund warum man erst das eine kennen muß, bevor man sich das
> > andere anguckt. Und "Standard" definiert immernoch das üblich
> > verwendete tool in einem Anwendungsbereich.
>
> Naja, es hat seinen Grund, warum es GNU/Linux heißt. Standard in
> diesem Fall heißt, es sind die Grundpfeiler des Systems. Ich würde es
> auch ziemlich merkwürdig finden, wenn jemand statt ls zu benutzen
> jedesmal den Midnight Commander anwirft. Beides führt zum Ziel, aber
> in dem Fall wäre ls effizienter.
Auch wenn ls generell schneller zum Ziel führen dürfte, denke ich hat
mc dennoch einige Anwendungsbereiche wo es gewinnt. Aber davon ab hinkt
der Vergleich dennoch enorm. mc is nen Dateimanager, oder ne
Dateimanager-shell, während ls nen subset einer anderen shell is.
> Bevor du mir wieder den Satz umdrehst. Ich weiß, dass dd nicht in
> jedem Fall effizienter ist. Bei mir aber in den meisten Fällen und das
> ist erfahrungsbedingt.
Ohne jetzt die Details Deiner Umgebung kennen zu wollen, so ist es doch
schön von Dir den Satz mal zu hören. Das es eben für DEIN System passt,
aber eben nicht für alle anderen möglichen Imaging-Szenarien auf diesem
Planeten.
Ich behaupte einfach mal dem durchschnittlichen Benutzer der mal vor
der Aufgabe steht nen System imagen / clonen zu müssen, hat ziemlich
genau die selben Wünsche. Eben möglichst kleines Image, möglichst
schnell erledigt. Es macht sehr oft keinen Sinn 1TB zu kopieren, wenns
auch 5GB sein könnten ohne was auszulassen. Genau so gibts für die
jeweiligen Nachteile des einen Workarounds die die jeweils andere
Lösung nicht braucht. Ob einem die Workarounds nun weh tun oder
überhaupt auffallen... oder eben nicht, bleibt jedem selbst überlassen.
> > Sprich, unsereins verwendet je das für ihn passende
> > tool, bleibe Du von mir aus bei der Einheitskost. Und so am Rande,
> > ich kenne die (grundlegende) Syntax von dd UND clonezilla /
> > partimage, kann also beide Tool-Kategorien "einigermaßen sicher"
> > bedienen, weil ich mal das eine, mal das andere für den angedachten
> > Zweck als sinnvoll erachte und daher deren Syntax gelernt habe.
>
> Jup, so soll es ja auch sein.
Err... und warum diskutieren wir dann hier? Weil man könnte meine
komplette Meinung unter diesem einen Abschnitt dem Du zustimmst
zusammenfassen.
> > Und da zickt auch nix rum. Nur gibts prinzipbedingt natürlich
> > unterschiedliche Fehlerpotentiale, die man je nach Zweck selbst
> > abwägen muß. Beispiel multilayered Datengräber. Klar hat nen
> > Dateisystem direkt auf nem physikalischen Blockdevice nen inherent
> > unkomplexeren Aufbau, trotzdem wurden Partitionen erfunen. Später
> > RAID, dann encrypted blockdevices, LVM, ... einfach is schön, aber
> > nicht um jeden Preis! Manchmal muß es für den angedachten Zweck
> > einfach nen bissl komplexer sein, weil die einfacheren Lösungen da
> > sich nicht gescheit oder so gar nicht applizieren lassen.
> > Von Grub, über mdadm, dm-crypt bis zu den einzelnen LVs, habe ich
> > schon einige male händisch was fixen müssen. So what? Ich kann damit
> > umgehen. Und ich mag heute auf den gebotenen Mehrwert auf gar keinen
> > Fall mehr verzichten, ohne eine so etwas komplexere Lösung jetzt auf
> > jede Kiste anwenden zu müssen oder zu wollen.
>
> ich bin froh für dich, dass du dir einige Sachen aneignen konntest. So
> soll es ja auch sein.
Das erwarte ich im Zweifel von JEDEM der sich mit GNU/Linux
auseinandersetzt, es benutzt. Das meine Erwartung da aber in der Masse
aller Vorfälle maßlos enttäuscht wird, is nen anderes Ding.
> Irgendwie habe ich den Eindruck, du seist der Meinung, ich möchte
> meine Sichtweise aufdrängen oder diskriminiere jeden der nicht gleich
> jedes Tool erst einmal durch den Debugger schmeißt um sich von der
> korrekten Arbeitsweise zu überzeugen. Nein, das ist nicht der Fall.
Na da bin ich aber froh! :-)
> Ich bin lediglich der Meinung, um entscheiden zu können, was im
> welchem Fall nun besser passt, sollte man eben - wie du auch sagtest -
> ein gewisses Portfolio kennen und ich persönlich greife erst einmal
> auf die Dinge zu, die es mir einfach machen zu verstehen und das sind
> Tools die so wenig Intelligenz von Haus aus mitbringen wie es
> zuträglich ist.
"Wie es zuträglich ist"? O_o Aber natürlich, das KISS-Prinzip regelt
prinzipiell, nur eben nicht um des Prinzips Willen alleine. Es is ja
eher der Grundgedanke dahinter Krams nicht "unnötig" zu
verkomplizieren. Und wenn man guckt was z.B. clonezilla macht, erkenne
ich zumindest daran nix kompliziertes, aber natürlich nen komplexeren
Lösungsansatz, aber eben nicht alleine aus dem Prinzip möglichst
komplexer und komplizierter zu sein, sondern um nen faktisch existentes
Problem zu lösen was mit einfachen Mitteln ala dd nicht oder für die
jeweilige Problemstellung nicht genügend gut gelöst werden kann. Im
Zweifel spielt da auch die an anderer Stelle genannte "TCO" ne Rolle,
sozusagen.
> Ich fahre damit bisher extrem gut, darum möchte ich gern andere an
> dieser Erfahrung teilhaben lassen. Was daraus gemacht wird, ist nicht
> mein Bier.
Fair enough. Dann bin ich halt nur der Bub der von clonezilla und
Konsorten schwärmt und anderen dahingehend an meinen Erfahrungen
teilhaben läßt. :)
Grüße
Michael
Reply to: