Re: dd und Dateisystem

Am Freitag, den 04.12.2009, 16:13 +0100 schrieb Oliver Fromme:
> Marc Santhoff wrote:
> > Oliver Fromme wrote:
> > > Ja, das ist vollkommen problemlos. Du kannst sogar das
> > > Image, das Du mit dd(1) erzeugt hast, per mdconfig(8)
> > > mounten. Ein UFS-Dateisystem ist von der Platte und
> > > Slice, in der es sich befindet, unabhängig.
> >
> > Stimmt auffallend, so geht das ja auch mit ISO-Images. Muß man nur dran
> > denken. mdconfig habe ich vor langer >Zeit auch mal benutzt, aber da
> > gibt es IIRC was neues.
>
> Nö, das verwechselst Du wahrscheinlich. Wenn es vor sehr
> langer Zeit war, dann hast Du vermutlich vnconfig(8)
> genommen. Das wurde von mdconfig(8) abgelöst.

Genau.

> > > Außerdem sollte man anmerken, dass dd(1) für Backups nur
> > > in Ausnahmefällen geeignet ist, da es vergleichsweise
> > > ineffizient und unflexibel ist.
> >
> > Ich weiß, aber ich brauche eine Methode für die Sicherung und (leidlich)
> > schnelle Wiederherstellung von mehreren Partitionen im benutzbaren
> > Zustand. Die werden allerdings zum überwiegenden Teil nur sporadisch
> > genutzt und es sind zuviele an Zahl, als daß ich deswegen einen Schrank
> > voller Festplatten horten möchte.
>
> Gut, aber inwiefern spricht das jetzt für dd und gegen
> "typische" Backup-Tools wie cpdup, tar, cpio, oder meinet-
> wegen dump/restore?

Weil dann ein begrenzter Satz Maßnahmen für die Restaurierung besteht,
KISS-Prinzip.

Wenn ich dafür erst großartig Bedienungsanleitungen schreiben und
zwischen OS differenzieren muß, ist es schon zu kompliziert. In diesem
Fall ist die Wartezeit bei Speichern/Zurückspielen kein besonderes
Problem, ein komplexes Reglewerk für verschiedene Sicherungs- und
WIederherstellungsmechanismen aber schon.

> dd ist langsam, denn es liest immer die ganze Platte, egal
> wie voll sie ist. Da hilft auch conv=sparse nicht; das
> hilft maximal beim Schreiben des Images, aber da auch
> nur bei "frischen" Dateisystemen. Sobald ein Dateisystem
> mal eine zeitlang in Benutzung war, sind auch die freien
> Blöcke mit irgendwelchen alten Daten gefüllt, es sei denn,
> Du lässt regelmäßig ein "Scrubbing"-Tool laufen.
>
> Außerdem kannst Du mit dd keine inkrementellen Backups
> machen (die nochmals schneller wären und Platz sparten),
> nur volle Backups. Das führt dazu, dass man das Backup
> seltener macht.

Stimmt natürlich, aber der Anwendungsfall ist etwas "unnormal",
jedenfalls gegenüber typischen BAckup/Restore-Szenarien. Die
betreffenden Images werden auch ein halbes Jahr überhaupt nciht benutzt,
dann für ein oder zwei Tage rausgekramt und erfahren dabei minimale
Änderungen. Diese Änderungen landen in einer Versionsverwaltung, also
kann man die betreffende slice bei Bedarf ohne Bedenken löschen.

Eine neue dd-Kopie wird nur erstellt, wenn eines dieser Images
tatsächlichgeänderet werden muß. Dann muß man aber wie immer auch nicht
daneben sitzen.

Ganz bestimmt werden die Images durch (b)gzip(2) gemangelt, obwohl die
bei zufälligem Datenmüll auch ihre Probleme haben dürften. So gesehen
hast DU recht, ich werde mich in jedem Fall nochmal nach passenden Tools
umgucken, die leere Bereiche ausnullen. Mal gucken wie dann die Relation
zwischen Platzbedarf und Zeitaufwand ist. Alternativ vielleicht vorher
nochmal die gesamte Slice "ausnullen", das könnte sogar schneller gehen
und bei kurzere NUtzungsdauer deutlich wirken.

> > Da aber R/W-Betrieb nötig ist und neben verschiedenen FreeBSD-Versionen
> > auch Windows im Spiel ist halte ich dd momentan für die einzige Lösung.
>
> Verstehe ich nicht. Das Argument spricht eher *gegen* dd,
> denn dd kannst Du bei R/W-Betrieb nicht nehmen. Die mei-
> sten anderen Tools (cpdup, tar, ...) gehen bei R/W-Betrieb.

Unglücklich formuliert, nach dem restore brauche ich ein
R/W-Dateisystem, nicht während der Sicherung.

> (Windows ist natürlich eine ganz andere Geschichte. Aber
> selbst wenn Du für Windows dd hernimmst, heißt das ja noch
> lange nicht, dass man es auch für FreeBSD hernehmen muss,
> vor allem wenn es dafür schlechter geeignet ist als andere
> Lösungen.)

Doch, gerade das - s.o.

> > > Ja. (Du meinst vermutlich Partition, nicht Slice. Norma-
> > > lerweise werden UFS-Dateisysteme innerhalb einer Partition
> > > eines Disklabels angelegt; siehe bsdlabel(8).)
> >
> > Ich spreche normalerweise auch von Partitionen. In meinem Hinterkopf
> > meldetete sich aber die Information "Windows: Partition, FreeBSD: slice"
> > zu Wort. Ist aber im deutschen Sprachbegrauch wohl eher verwirrend.
>
> Der Ursprung des Problems ist, dass DOS und UNIX etwas an-
> deres unter "Partitionen" verstanden. Um Verwirrungen zu
> vermeiden, werden bei (Free)BSD daher die DOS-Partitionen
> "Slices" genannt.
>
> /dev/ad0 <-- Platte
> /dev/ad0s1 <-- Slice
> /dev/ad0s1a <-- Partition

Dann meine ich also doch slices.

> Man kann theoretisch auch BSD-Partitionen direkt auf der
> Platte anlegen, ohne Slice. Das kann dann aber Probleme
> mit dem Booten geben, je nachdem, wie zickig sich das BIOS
> anstellt.
>
> Du kannst sogar ein Dateisystem direkt auf der Platte
> anlegen, wenn Du eh nur ein einziges Dateisystem auf dem
> Datenträger benötigst. Die ist z.B. bei Disketten üblich.
>
> Gruß
> Olli
>

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message