🚀 go-pugleaf

In de.comp.os.unix.misc Andreas Edler <aed@cephyr.cid.net> wrote:
> Hallo,

> ich suche eine gute und flexible (und auch moeglichst kostenlose)
> Backup-Software, die mit grossen Datenmengen umgehen kann.  Es geht
> darum, dass von insgesamt ca. 80 GB regelmaessig zyklische Backups
> auf einem 4-GB-Tapelaufwerk gemacht werden muessen.

> Wir fahren das Backup zur Zeit directory-weise.  Das Problem dabei
> ist jedoch, dass es immer mal wieder wechselt, in welchen Ver-
> zeichnissen grosse Datenmengen liegen...

> Hat jemand Tips fuer mich?  (Betriebssystem ist Solaris 2.5.)

> Shalom!
>   .\ndreas

> -- 
>       Die gluecklichen Menschen sind nicht die, die am meisten haben,
>          sondern die, die am meisten danken koennen!  (W.J.Oehler)

ich wuerde dir amanda vorschlagen.... eine sehr flexibeles BackupServer
system, welches auch mit Jukeboxen usw. umgehen und kann Platten als 
netzpuffer bereitstellen.
Im einem Cyclus kannst du auch mehrere rechner gleiczeitig sichern ...
Ich bin jedenfalls begeister .... und es tut und tut......

-- 
	cu ....... Louis


	

pff-louis@crylle.ddns.org wrote:
> 
> In de.comp.os.unix.misc Andreas Edler <aed@cephyr.cid.net> wrote:
> > Hallo,
> 
> > ich suche eine gute und flexible (und auch moeglichst kostenlose)
> > Backup-Software, die mit grossen Datenmengen umgehen kann.  Es geht
> > darum, dass von insgesamt ca. 80 GB regelmaessig zyklische Backups
> > auf einem 4-GB-Tapelaufwerk gemacht werden muessen.
> 
> > Wir fahren das Backup zur Zeit directory-weise.  Das Problem dabei
> > ist jedoch, dass es immer mal wieder wechselt, in welchen Ver-
> > zeichnissen grosse Datenmengen liegen...
> 
> > Hat jemand Tips fuer mich?  (Betriebssystem ist Solaris 2.5.)
> 
> > Shalom!
> >   .\ndreas
> 
> > --
> >       Die gluecklichen Menschen sind nicht die, die am meisten haben,
> >          sondern die, die am meisten danken koennen!  (W.J.Oehler)
> 
> ich wuerde dir amanda vorschlagen.... eine sehr flexibeles BackupServer
>

Wenn Du Geld ausgeben kannst (???) bist Du mit LegatoNetworker mit einer 
kleinen DLT Library (z.B. 5 Tapes a 20GByte) gut bedient.

--
Ruedi Schwitter   e-mail: rschwitt@bluewin.ch
Postfach 8050	          Ruedi.Schwitter@clariden.com
8022 Zuerich      Tel:    +41 1 205 62 88 / Fax: +41 1 205 62 72

In <ygebtpjbrp4.fsf@halut.e.ruhr.de> Matthias Peick <matthias@peick.com> writes:
>aed@cephyr.cid.net (Andreas Edler) writes:

>> Backup-Software, die mit grossen Datenmengen umgehen kann.  Es geht
>> darum, dass von insgesamt ca. 80 GB regelmaessig zyklische Backups
>> auf einem 4-GB-Tapelaufwerk gemacht werden muessen.
>Kann es sein, dass das Verh�ltnis etwas unausgewogen ist? Ihr solltet
>schon mal einen Konkursverwalter bestimmen.

Warum? Amanda kann das wunderpraechtig und vor allem auch mit einem sehr
niedrigen Administartionsaufwand. Einmal einrichten und dann nur noch
taeglich das Band wechseln. Selbst wenn man mal vergisst, das Band zu
wechseln, so ist das auch noch kein Beinbruch, dafuer gibts ja amflush(8).

Am Besten aber laeuft amanda mit einer Jukebox: einmal einrichten und dann
vergessen ;)

-- 
-- Josef Wolf -- jw@raven.inka.de -- Germersheim, Germany --

Josef Wolf <jw@raven.inka.de> meinte:

>Am Besten aber laeuft amanda mit einer Jukebox: einmal einrichten und dann
>vergessen ;)

Aber DLT-Jukeboxen gehen so ins Geld :-)

Tsch�
T�ns
-- 
_o)
 /\\ pgp fingerprint: 9B AC A5 CB C8 CC FC DC  25 B5 26 9A 5D 28 C0 3D
_\_V 

In <yge90kew4uh.fsf@halut.e.ruhr.de> Matthias Peick <matthias@peick.com> writes:
>jw@raven.inka.de (Josef Wolf) writes:
>> >> darum, dass von insgesamt ca. 80 GB regelmaessig zyklische Backups
>> >> auf einem 4-GB-Tapelaufwerk gemacht werden muessen.
>> >Kann es sein, dass das Verh�ltnis etwas unausgewogen ist? Ihr solltet
>> >schon mal einen Konkursverwalter bestimmen.
>> Warum? Amanda kann das wunderpraechtig und vor allem auch mit einem sehr
>Unabh�ngig von Amanda oder anderer Software: Das Verh�ltnis ist f�r
>ein Produktionssystem ung�nstig.

Was ist daran unguenstig? Und was hat das alles mit dem Konkursverwalter
zu tun?

-- 
-- Josef Wolf -- jw@raven.inka.de -- Germersheim, Germany --

In <ygezpcf5726.fsf@halut.e.ruhr.de> Matthias Peick <matthias@peick.com> writes:
>jw@raven.inka.de (Josef Wolf) writes:
>> Was ist daran unguenstig? Und was hat das alles mit dem Konkursverwalter
>> zu tun?
>Der Verlust wichtiger Firmendaten hat binnen weniger Tage den Konkurs
>zur Folge. Der Verlust von Entwicklerdaten verz�gert den Vorgang um
>einige Wochen.

Fein! Wissen wir alle... Jetzt musst Du nur noch erklaeren, warum man
zwangslaeufig Firmendaten verliert, wenn man Backups auf 4GB-Tapes macht...
Und was hat das mit dem Verhaeltnis Gesamtdaten zu Mediengroesse zu tun?

-- 
-- Josef Wolf -- jw@raven.inka.de -- Germersheim, Germany --

Josef Wolf <jw@raven.inka.de> wrote:
> In <ygezpcf5726.fsf@halut.e.ruhr.de> Matthias Peick <matthias@peick.com> writes:

> >Der Verlust wichtiger Firmendaten hat binnen weniger Tage den Konkurs
> >zur Folge. Der Verlust von Entwicklerdaten verz�gert den Vorgang um
> >einige Wochen.

> Fein! Wissen wir alle... Jetzt musst Du nur noch erklaeren, warum man
> zwangslaeufig Firmendaten verliert, wenn man Backups auf 4GB-Tapes macht...
> Und was hat das mit dem Verhaeltnis Gesamtdaten zu Mediengroesse zu tun?

Wenn ich mich recht erinnere, dann handelte es sich um Datenmengen in der
Groessenordnung von einigen dutzend GB und DAT-Baendern zu 4 GB.
Die Probleme fangen doch dann schon an, wenn man ueber Nacht nicht mehr
genuegend Zeit hat, alles zu sichern weil die Bandlaufwerke zu langsam sind.
Darueberhinaus ist DAT erstens fuer grosse Datenmengen nicht nur zu langsam
sondern auch zu unsicher, als dass man guten Gewissens das Schicksal einer
Firma dranhaengen sollte,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Josef Wolf <jw@raven.inka.de> wrote:
>> jw@raven.inka.de (Josef Wolf) writes:
>>> Was ist daran unguenstig? Und was hat das alles mit dem
>>> Konkursverwalter zu tun?
>> Der Verlust wichtiger Firmendaten hat binnen weniger Tage den Konkurs
>> zur Folge. Der Verlust von Entwicklerdaten verz�gert den Vorgang um
>> einige Wochen.

> Fein! Wissen wir alle... Jetzt musst Du nur noch erklaeren, warum man
> zwangslaeufig Firmendaten verliert, wenn man Backups auf 4GB-Tapes
> macht... Und was hat das mit dem Verhaeltnis Gesamtdaten zu Mediengroesse
> zu tun?

Bl�de Frage. Wenn Du ein Full-Backup machen mu�t, dann brauchst Du daf�r
20 B�nder, wenn die Daten nicht weiter komprimierbar sind. Selbst im
Falle einer noch m�glichen Kompression sind es immer noch 12 oder mehr
B�nder (Erfahrungswerte). Das geht bereits nicht mehr automatisiert, da
der gr��te DDS-Wechsler max. 12 B�nder hat, aber nach 8 B�ndern schon
ein Reinigungsband erforderlich sein kann. So einen Wechsler hast Du
sicherlich ohnehin nicht, und wenn, dann k�nntest Du ihn nicht
unbeaufsichtigt �bers Wochenende laufen lassen. Au�erdem dauert so ein
Backup dann mehrere Tage, es kann also kein "snapshot" der Daten
angefertigt werden, das Backup l�uft w�hrend der Arbeitszeit. Offene
Dateien sind dann nicht oder fehlerhaft im Backup.

Die recover-Zeit bei Verlust der Platten ist ja dann die Zeit des
Full-Backup plus die Zeit f�r die inkrementellen Backups. Deren Anzahl
ist dann sehr wahrscheinlich gro�, da das Full-Backup ja so umst�ndlich
ist. So kann es dann sein, da� Du 30 oder 40 B�nder wieder einspielen
mu�t, was Dich etwa eine Woche besch�ftigt, inklusive zweier
Wochenenden. Der Rest der Kollegen macht dann Betriebsferien. Und wenn
sie wiederkommen, hat der Gerichtsvollzieher bereits die T�r plombiert.
Eine Woche ohne Gesch�ftsbetrieb kann heute keine Firma mehr ab. Das
kannst Du nur noch im RZ einer Hochschule loslassen, au�erhalb der
Vorlesungszeit nat�rlich.

Wenn ein Band des Full-Backup defekt wird oder verloren geht bzw.
versehentlich �berschrieben wurde, ist das Full-Backup mitsamt der
Inkremente f�r die Tonne. Du hast dann gar kein Backup mehr. DDS-B�nder
haben eine Lebensdauer von vielleicht 10-20 Benutzungen, dann werden sie
unzuverl�ssig. Jedes Einlegen und Auswerfen z�hlt schon, selbst wenn
eigentlich nichts gelesen oder geschrieben wurde. Das Einf�deln alleine
stre�t das Band mechanisch bereits so.

Das kann man dann noch etwas eingrenzen, wenn man Clones, Band-zu-Band-
Kopien erstellt. Das erfordert zwei Bandwechsler. Das Clonen mu� aber so
schnell ablaufen, da� die Laufwerke beim n�chsten anstehenden Inkrement
damit fertig sind, oder Du brauchst 4 Bandwechsler. Die sind dann teurer
als 2 DLT7000-Laufwerke. Die schreiben 40 GB auf ein Band, mit 5 MB/sec.
So ein Full-Backup l�uft dann in 4.5 Stunden, B�nder brauchst Du erst
hinterher wechseln, und bei richtiger Planung kannst Du ein
Komplett-Recover in 8 Arbeitsstunden erledigen, machst nicht einmal
�berstunden. Und DLT-B�nder halten etwa 500 statt 20 Kassettenwechsel
aus. Die Herstellerangaben sind nat�rlich wesentlich h�her, aber das ist
Marketinggeschw�tz. Ich hatte n�mlich auch schon verschlissene
DLT-B�nder im Full-Backup...

-hgw 

In <1dfoliv.1n3mpf11lm5x4iN@deck45.wiesbaden.netsurf.de> hgweigand@wiesbaden.netsurf.de (Hans-Guenter Weigand) writes:
>Josef Wolf <jw@raven.inka.de> wrote:
>> Fein! Wissen wir alle... Jetzt musst Du nur noch erklaeren, warum man
>> zwangslaeufig Firmendaten verliert, wenn man Backups auf 4GB-Tapes
   ^^^^^^^^^^^^^
>> macht... Und was hat das mit dem Verhaeltnis Gesamtdaten zu Mediengroesse
>> zu tun?

>Bl�de Frage.

Bloede Antwort! Die Behauptung "alle Autos sind rot" kannst Du nicht
damit belegen, dass Dein Nachbar ja ein rotes Auto hat. Du hast (ohne
nach Hintergruenden zu fragen) behauptet, dass eine Firma, die 80GB Daten
auf 4GB-Baender speichert zwangslaeufig kurz vor dem Konkurs steht.
Nun hast Du ein Szenario geschildert, wo es tatsaechlich so waere (was
ich ja auch nie bestritten habe). Das heisst aber noch lange nicht, dass
es immer so sein muss. Hier ein anderes Szenario:

Du verwaltest ein Netzwerk von 25 Workstations. Jede WS hat 2 Dateisysteme
mit jeweils 2GB Daten. Dicke Server hast Du nicht. Das macht insgesamt
100GB Daten. Jetzt nimmst Du 50 Baender zu jeweils 4GB. Dein Backupsystem
ist so clever, dass es die Full-Backups aller Dateisysteme ueber alle
verfuegbaren Baender ausbalanciert. Der Rest der Baender wird mit
incrementals aufgefuellt. Jede Nacht wird nur _ein_ Band beschrieben.
Ein Band enthaelt also (grob geschaetzt):
- Fullbackups von 2 Dateisystemen (zusammen ca 2GB komprimiert).
- Incrementals der anderen 48 Dateisysteme.

Sind die Daten (moeglichst gleichmaessig) auf viele Dateisysteme verteilt,
so kann man nach diesem Verfahren die Menge der zu sichernden Daten nahezu
beliebig steigern. Du musst lediglich die Anzahl der Baender erhoehen.
Und: ganz gleich, welche Kiste Dir abraucht, Du brauchst maximal 4
Baender um diesen Rechner wiederherzustellen.

BTW: Dieses Verfahren ist auch bestens dazu geeignet, kostenguenstig
Langzeitarchivierung zu betreiben. Mit nur einem 4GB-Band pro Tag kannst
Du (vorausgesetzt Du ueberschreibst die Baender nicht mehr, sondern nimmst
stattdessen immer wieder neue Baender) _jeden_ beliebigen Deiner Rechner
auf _jedes_ beliebige Datum in der Vergangenheit zurueckstellen.


 Wenn Du ein Full-Backup machen mu�t, dann brauchst Du daf�r
>20 B�nder, wenn die Daten nicht weiter komprimierbar sind.

Du machst den fatalen Fehler, dass Du von allen Daten gleichzeitig
einen Full-Backup machen willst.

>Selbst im
>Falle einer noch m�glichen Kompression sind es immer noch 12 oder mehr
>B�nder (Erfahrungswerte). Das geht bereits nicht mehr automatisiert, da
>der gr��te DDS-Wechsler max. 12 B�nder hat, aber nach 8 B�ndern schon
>ein Reinigungsband erforderlich sein kann.

Mit obigem Verfahren geht das sehr wohl (fast) automatisiert. Und das ganz
ohne Wechsler. Du brauchst lediglich jeden Tag das naechste Band einzulegen.
Amanda ist sogar so nett, Dir zu sagen, welches Band Du einlegen sollst.
Solltest Du das zB bis um 11:00 nicht getan haben, so erinnert Dich amanada
per Mail daran. Solltest Du es bis 12:00 nicht getan haben, so kriegt Dein
Stellvertreter eine Mail. Um 13:00 der Abteilungsleiter usw usf. Sollte
zum Zeitpunkt des Backups immer noch nicht das richtige Band einliegen
(weil evtl alle auf der Betriebsversammlung waren), so werden die Backups
auf die sogenannte 'holding-disk' geschrieben und Du kriegst eine Mail,
die Dich bittet diese Daten per 'amflush' auf das Band zu spielen. Da
kann man sich daran gewoehnen.

>So einen Wechsler hast Du
>sicherlich ohnehin nicht, und wenn, dann k�nntest Du ihn nicht
>unbeaufsichtigt �bers Wochenende laufen lassen.

Nein, habe ich nicht. Und brauche ich auch nicht. Ich ziehe intelligente
Software Deiner Brute-Force-Methode vor. Ich waere mal gespannt, wie Du
_wirklich_ grosse Datenmengen (terabytes) sichern wuerdest. Vermutlich
wuerdest Du Dich auf die Suche nach einem Wechsler in ebensolcher
Groessenordnung machen. ;)=

[... noch viel Unfug geloescht, den Du wahrscheinlich nicht geschrieben
 haettest, wenn Du (wie Dir nahegelegt wurde) Dich ueber Amanda informiert
 haettest...]

-- 
-- Josef Wolf -- jw@raven.inka.de -- Germersheim, Germany --

Josef Wolf <jw@raven.inka.de> wrote:

> In <1dfoliv.1n3mpf11lm5x4iN@deck45.wiesbaden.netsurf.de>
> hgweigand@wiesbaden.netsurf.de (Hans-Guenter Weigand) writes:
>
...
>Hier ein anderes Szenario:
> 
> Du verwaltest ein Netzwerk von 25 Workstations. Jede WS hat 2 Dateisysteme
> mit jeweils 2GB Daten. Dicke Server hast Du nicht. Das macht insgesamt
> 100GB Daten. Jetzt nimmst Du 50 Baender zu jeweils 4GB. Dein Backupsystem
> ist so clever, dass es die Full-Backups aller Dateisysteme ueber alle
> verfuegbaren Baender ausbalanciert. Der Rest der Baender wird mit
> incrementals aufgefuellt. Jede Nacht wird nur _ein_ Band beschrieben.
> Ein Band enthaelt also (grob geschaetzt):
> - Fullbackups von 2 Dateisystemen (zusammen ca 2GB komprimiert).
> - Incrementals der anderen 48 Dateisysteme.

Wahnsinn. Du brauchst 2 MONATE f�r ein einziges full backup! Von
Rechnern, die noch nie ein full backup bekommen haben, kannst Du keine
Inkremente schreiben. Wie sieht die recovery-Zeit aus, wenn Euch die
Bude abbrennt? Neue Maschinen sind in ein paar Tagen da, aber die
Daten...

BTW, ich 'habe' *nur* dicke Server (am Hals)...

...

> Du machst den fatalen Fehler, dass Du von allen Daten gleichzeitig
> einen Full-Backup machen willst.

Das ist definitiv KEIN Fehler. Ich arbeite halt nicht in einer
�berschaubaren Firma, sondern ich arbeite bei einem Dienstleister und
betreue hier im Raum etwa 30 Kunden. Nur bei 2 Kunden ist vor Ort ein
Administrator, den man ohne Reue ans Backup lassen darf. Wenn wir bei so
einem Kunden neue Maschinen installieren, dann mu� ich ein full backup
dieser Kisten haben, bevor ich sie an den Kunden �bergebe. Da kann ich
nicht etwas von "warten sie ein paar Wochen, bevor sie die Mitarbeiter
dranlassen" murmeln.

...
 
> >So einen Wechsler hast Du sicherlich ohnehin nicht, und wenn, dann
> >k�nntest Du ihn nicht unbeaufsichtigt �bers Wochenende laufen lassen.
> 
> Nein, habe ich nicht. Und brauche ich auch nicht. Ich ziehe intelligente
> Software Deiner Brute-Force-Methode vor. Ich waere mal gespannt, wie Du
> _wirklich_ grosse Datenmengen (terabytes) sichern wuerdest. Vermutlich
> wuerdest Du Dich auf die Suche nach einem Wechsler in ebensolcher
> Groessenordnung machen. ;)=

Da gibt es nichts zu lachen. Wenn der Kunde solche Datenmengen an einem
Server hat (Videoschnitt z.B.), dann mu� auf jeden Fall sichergestellt
werden, da� binnen 48 Stunden die Daten *vollst�ndig* wiederhergestellt
werden k�nnen. Das verlangt die Versicherung. Und der Kunde mu� sich
versichern in diesem Gewerbe, denn ein paar Tage ohne Produktion kann er
finanziell nicht aus eigener Kraft �berbr�cken. Und jetzt rechne einfach
mal selbst aus, welche Materialschlacht das bei 800 GB Festplatten ist.
Wie gesagt: 48 Stunden. Mit allen Inkrementen. Bei solchen Anwendungen
ist dann auch die Datenfluktuation gro�. An guten Tagen sind das auch
schon mal 60-80 GB. Das w�re dann ein einziges Inkrement. Das mu�
zwischen Sp�tschicht (endet um Mitternacht) und Fr�hschicht (ab 4 oder 5
Uhr) auf Band sein. 

Jukeboxen mit 200 oder 500 B�ndern sind Stand der Technik, da brauchst
Du nicht zu suchen. Intelligente Software nutzt Dir nichts, wenn Du die
recovery-Zeiten im worst case nachweisbar (!) einhalten mu�t.

Tip: La�' Dir mal die Backupserver der Deutschen Bank AG in Frankfurt
zeigen.

> [... noch viel Unfug geloescht, den Du wahrscheinlich nicht geschrieben
>  haettest, wenn Du (wie Dir nahegelegt wurde) Dich ueber Amanda informiert
>  haettest...]

Kein Unfug. Au�erdem hat man nicht *mir* Amanda nahegelegt. Lies bitte
auch die Namen im thread. Amanda nutzt mir nichts, wenn der Kunde Legato
Networker haben will oder schon seit Jahren benutzt. Das sind
unternehmensweite Entscheidungen, da kann man nicht aus privater
Vorliebe (und vielleicht auch aus eigenem Verst�ndnis) bei einer
Maschine eine andere (bessere) Software einsetzen. Und was eben z�hlt
ist nicht die Eleganz der Software, sondern das schnelle recover, auch
(und gerade) beim gro�en Server.

-hgw

Josef Wolf <jw@raven.inka.de> wrote:

: Sind die Daten (moeglichst gleichmaessig) auf viele Dateisysteme verteilt,
: so kann man nach diesem Verfahren die Menge der zu sichernden Daten nahezu
: beliebig steigern. Du musst lediglich die Anzahl der Baender erhoehen.
: Und: ganz gleich, welche Kiste Dir abraucht, Du brauchst maximal 4
: Baender um diesen Rechner wiederherzustellen.

Wie geht denn das ? Wenn ich 25 Rechner habe, und jede nacht nur einen
per full backup gesichert bekomme, dann kann ich doch die anderen 24
Tage nur incremental Sichern? Das bedeutet doch, dass ich dann 24 Tage
lang nur die Aenderungen zum Vortag sichere. Damit komme ich dann auf
24 Baender zur Rekonstruktion des Rechners, wenn er genau an dem Tag
vor dem naechsten full backup den Geist aufgibt; oder habe ich irgendwo
etwas nicht richtig verstanden?

Gerade bei DAT wuerde ich mich nicht darauf verlassen 4 Baender im
Ernstfall fehlerfrei lesen zu koennen (erst recht nicht 24). Bei Problemen
bleibt Dir dann nur das Backup von dem 2. Satz und das ist dann der
Stand von vor fast einem Monat. Wenn die Daten wichtig sind wuerd ich
mir moeglichst schnell zumindest ein 2. Laufwerk kaufen und das Ding
als mirror benutzen. Und da ist man dann auch schon fast in der
Preisregion von DLT Laufwerken; dafuer hat man dann auch weniger Stress
und ein geringeres Risiko.

: BTW: Dieses Verfahren ist auch bestens dazu geeignet, kostenguenstig
: Langzeitarchivierung zu betreiben. Mit nur einem 4GB-Band pro Tag kannst
: Du (vorausgesetzt Du ueberschreibst die Baender nicht mehr, sondern nimmst
: stattdessen immer wieder neue Baender) _jeden_ beliebigen Deiner Rechner
: auf _jedes_ beliebige Datum in der Vergangenheit zurueckstellen.

Du solltest Dir mal die Spezifikationen von Bandlaufwerken durchlesen,
bevor Du sowas schreibst (das geht ja noch nicht einmal, wenn Du die
4GB in Stein meisselst!). Mir geht jedenfalls immer der Hut, wenn ich
sehe, dass Leute, denen man gesetzlich vorschreibt Daten fuer 10
Jahre zu archivieren, mit DAT arbeiten. Sowas geht nur "vernuenftig" mit
DLT oder QIC ("vernuenftig": weil man auch seine DAT-Baender alle 3 Jahre
umzukopieren koennte; und selbst das wird von den Leuten nicht gemacht).
Es ist schon eine riesen Sauerei, wie sich einige Leute ueber Vorschriften
hinwegsetzen, um ein paar Mark zu sparen.

-- 
Marcus, der nie verstehen wird, warum fast alle Leute DATs nehmen

In article <6v0mpu$ime@wizard.imp.priconet.de>, Marcus Maskos writes:
> 4GB in Stein meisselst!). Mir geht jedenfalls immer der Hut, wenn ich
> sehe, dass Leute, denen man gesetzlich vorschreibt Daten fuer 10
> Jahre zu archivieren, mit DAT arbeiten.

Ein Kunde von mir (Krankenhaus) macht das auch so. Aber auf DAT gehen nur
die Backups, die Archivierung wird auf CD-R gemacht. Du solltest aus der
Verwendung von DAT fuer Backupzwecke nicht schliessen, dass kein
Archivierungskonzept existiert.

Holger

-- 
RedHat 5.1(i386) / 5.0(m68k) fuer 18 DM: http://linuxservice.de