Re: Datensicherung mittels linux dd

Polytropon <freebsd(at)edvax.de> wrote:
> [DVD-RAMs in Caddys]
> Ich sagte ja nicht ausdrücklich "heute". :-) Allenfalls kann
> ich mir vorstellen, daß diese "Video-DVD-RAMs" für die
> Vorläufer (oder Parallelbegleiterscheinungen) von DVD- und
> Festplattenrecordern gedacht waren.

Ja, ich glaube, sowas gab's mal. Naja, es wurden schon
viele komische Kombinationen eingesetzt, ich erinnere nur
an die Sony-Kameras (oder war es Fuji?), die ein 3½-Zoll-
Diskettenlaufwerk eingebaut hatten.

> Ähnlich wie die CDi (wer's noch kennt) hat sich auch dieses
> System nicht durchgesetzt.

Die CDi war damals vom Konzept her einfach unbrauchbar;
als Spielkonsole war es unattraktiv, und als Wiedergabe-
gerät zu teuer. Ich vermute, die meisten CDi-Besitzer
haben es nur zur Wiedergabe von Video-CDs und CDi-Videos
verwendet.

Ich fand damals CDi auch ziemlich behämmert und habe mir
stattdessen einen reinen Video-CD-Player zugelegt (steht
immer noch bei mir herum und funktioniert), der nicht
nennenswert teurer war als ein guter Audio-CD-Player (und
natürlich auch normale Audio-CDs abspielen kann). Das war
lange vor der Erfindung der DVD.

> > Das hat nichts zu sagen, das steht auf praktisch allen
> > Medien drauf. Genau wie auf CD-Rohlingen immer »74min«
> > o.ä. draufsteht.
>
> Muß ich gleich mal gucken... stimmt! Da hatte ich noch gar nicht
> so drauf geachtet, das bezieht sich sicher auf die Spiellänge
> für CD-Audio-Anwendungen (kann man ja dann auf 700 MB hochrechnen,
> Samplingrate, Bitbreite, Kanäle usw.).

Ja, sicher, wobei man dann den Overhead für den dritten
Fehlerkorrekturlayer wieder abziehen muss (CD-ROMs haben
normalerweise drei Layer, Audio-CDs nur zwei).

Bei Audio-CDs hast Du 176400 Byte pro Sekunde, die auf
75 Sektoren zu je 2352 Bytes verteilt werden. Bei Daten-
CDs stehen nur 2048 Bytes pro Sektor zur Verfügung; die
restlichen 304 Bytes werden für den dritten Fehlerkorrek-
turlayer verwendet. Man hat also pro Sekunde Laufzeit
sozusagen nur 153600 Bytes Platz für Nutzdaten.

> Naja, ordentlich gelagerte Disketten können (!) durchaus auch
> so lange leben, ich hab hier noch welche aus den 80er Jahren,
> die in den zugehörigen Laufwerken tadellos laufen.

Naja, »können«. Wenn ich ein Backup in einen Wackelpudding
graviere, _kann_ das auch ein paar Jahre halten, wenn ich
sehr viel Glück habe.

Was ich damit sagen will: Es ist ein Unterschied, ob 100%
aller vorhandenen Medien noch einwandfrei lesbar sind, oder
ob ein geringerer Anteil davon noch gelesen werden kann.
Bei meinen alten Disketten sieht es eher schlecht aus, und
ich habe die gewiss nicht schlecht gelagert.

> > In Rechenzentren mag es natürlich wieder anders aussehen.
> > Dort sind in den großen Tapelibraries in der Regel mehrere
> > Laufwerke verbaut, allein schon weil ein einzelnes Lauf-
> > werk nicht die erfoderliche Backup-Bandbreite liefert.
> > Dadurch hat man Redundanz, und man merkt man schnell,
> > wenn eines der Laufwerke dejustiert ist.
>
> Häufig erlaubt das eingesetze OS dann auch etwas mehr Diagnostik
> auf den Laufwerken, um Fehlern schon möglichst früh zu begegnen.
> Das ist dann häufig der Einsatzpunkt kommerzieller UNIXe oder
> netter IBM-Systeme.

Ich glaube, das hat nichts mit kommerziell oder nicht zu
tun. Laufwerksdiagnostik ist eine Protokollsache (z.B.
via SCSI bzw. SAS), und mit FreeBSD geht das z.B. auch
einwandfrei. Für professionelle Anwendungen, wo es dann
z.B. auch um die Überwachung von Lüftern, Netzteilen,
Gehäusen (Intrusion-detection) usw. geht, gibt es SES
und SAF-TE (siehe ses(4)).

> Ähnlich wirkt ja auch unter Solaris die
> Diagnostik des Arbeitsspeichers.

Ja, wobei das auch Hardware-Support erfordert, d.h. das
kann nicht unbedingt allein das OS leisten. Bei SPARC-
Hardware ist es üblich, dass bei einem Bitfehler der
Chip präzise lokalisiert werden kann; bei einem Wald-
und Wiesen-PC liefert die Hardware diese Info gar nicht.
Ist halt eine andere Liga.

> Teils wird ja aus Kompatibilitätsgründen, gerade im x86-Bereich,
> älterer Anschlußkram mitgeschleppt, wie z. B. der Steckverbinder
> des Diskettenlaufwerks oder der für PS/2-Maus und -Tastatur,
> wenngleich sich heute USB dafür durchgesetzt hat.

Stimmt. Wie ich die alten Festplattenstecker hasse ...
Da hat intel x-mal die PC-Standards umdesignt, aus dem
AT/BAT-Format ATX gemacht, die Mainboard-Stromversorgung
geändert, den ISA-Slot durch PCI ersetzt, serielle und
parallele Schnittstellen abgeschafft usw.usf., aber diese
dämlichen, fingerfressenden Molex-Stecker sind immer noch
da. Allein dafür hasse ich intel.

> > > > Eine 2 Jahre trocken und kühl eingelagerte Festplatte hingegen
> > > > unterliegt hingegen kaum einem Verschleiß.
> > >
> > > Stimmt, besonders dann, wenn sie nur zur Sicherung in Betrieb
> > > genommen wird, also nicht ständig mitläuft
> >
> > Davon würde ich zwingend ausgehen.
>
> Naja, ich kenne genug "Profis", die ihre "Backup-Platte"
> dauerhaft im Rechner mitlaufen lassen.

Dann ist das kein Backup, sondern ein zeitverzögerter
Mirror (wie RAID-1). Hat natürlich durchaus Nutzen (als
Ersatz für ein "undelete", beispielweise), aber wenn
eine Überspannung die Kiste brät, ein Einbrecher das
Ding mitnimmt oder die Mama beim Putzen den Tower kippt,
ist alles weg. Ein Backup ist was anderes. Ein Backup
hat im Regal zu stehen (oder in einem Tresor oder so,
je nachdem, was da drauf ist).

> Ich gebe gern zu, daß eine interne
> Platte üblicherweise schneller ist als eine über USB oder Fire-
> wire angeschlossene, aber dann muß man sich die Zeit fürs
> Backup ruhig mal nehmen.

Da gebe ich Dir prinzipiell recht. Übrigens, wenn man
wirklich Wert auf Geschwindigkeit legt, würde ich zu
einer externen eSATA-Platte raten (nicht USB); die ist
im Prinzip genauso schnell wie eine interne.

Davon abgesehen: Wenn man das Backup als Dateisystem
auf der Platte anlegt (also nicht als dd, dump, tar
oder so), dann braucht man beim nächsten Backup ja nur
die geänderten Dateien zu kopieren, alles andere nicht.
Das dürfte meistens hinreichend schnell gehen.

Und man muss dabei ja nicht davorhocken und zugucken,
wie die Bits durchs Kabel krabbeln. ;-)

Meine Sorge wäre auch, dass jemand, bei dem das Backup
möglichst schnell gehen soll, sich auch nicht die Zeit
nimmt, es ab und zu mal zu prüfen (zumindest Stichpro-
ben).

> Kommt auch, wie ich eingangs erwähnte, immer darauf an, WAS
> man sichert bzw. wie groß die Datenmengen werden sollen. Im
> Zeitalter von DV, MP3 und anderem Zeux sind die Bänder von
> damals natürlich keine Alternative mehr.

Tja, meine mp3s sichere ich zum Beispiel überhaupt nicht,
da ich sie jederzeit wieder von meinen Audio-CDs erzeugen
kann, wenn nötig. Kaufen tue ich mp3s nicht; ich will
schon was haben, was ich in der Hand halten kann, mit
vernünftigem Cover und so. Und um kundenfeindliches DRM
mache ich eh einen großen Bogen.

Aber Deine Argumentation stimmt natürlich trotzdem im
Prinzip. Ich denke da nur an Photos: Bei heutigen
Digitalkameras sind die Bilddateien auch bereits so groß
wie durchschnittliche mp3-Dateien. Und meine Urlaubs-
erinnerungen und andere Bilder sind unersetzlich, daher
werden sie gebackuppt.

> Ich kann mich noch gut daran erinnern, das waren meine Linux-Einstiegs-
> zeiten (so bin ich ja zu FreeBSD gekommen), da konnte man mit
> /dev/rft0 son Unsinn machen wie es z. B. als "Musikkassetten"
> gebrauchen...

Nunja, dem Laufwerk und dem Treiber ist es egal, ob man
einen dump oder einen PCM-Stream draufschreibt. Dafür
war sogar ein Floppystreamer noch gut genug; die normalen
500 kbps (minus Overhead), die ein HD-Floppycontroller
schafft, genügen für 22 kHz 8bit stereo. :-)

> So, dann wünsche ich schonmal höchst vorsorglich allen Mitlesern
> einen guten Rutsch ins Neue Jahr!

Dem schließe ich mich an!

Gruß
   Olli

PS: Wäre schön, wenn Dein Mail-Programm den Reply-To:-
Header nicht ignorieren würde. Da ich die Liste über
ein Gateway direkt lese, brauche ich nicht von jeder
Mail eine weitere Kopie in meinem Inbox-Folder.

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"Share your knowledge.  It is a way to achieve immortality." -- The Dalai Lama
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message