Re: Backupplanung
Hallo Patrick, Am 15:58 2003-01-29 +0100 hat Patrick Petermair geschrieben: So, das sind mal meine Favoriten bis jetzt. Hat irgendwer eines dieser Tools im Einsatz und kann mir mit Erfahrungsberichten helfen. Bzw. habe ich das ultimative Backup-Tool in meiner Liste vergessen? Verwende amanda weil es auch mit windows funktioniert... Was ich unbedingt brauche: -) Fähigkeit auf ein Tape (Compaq DLT 20/40) zu sichern Hmm, keine erfahrung, habe nur einen HP Surstore 12000e (zur zeit defekt wegne Blitzeinschlag) -) Full / Inkrementelles Backup Wird von amanda unterstuetzt... -) Mehrere Aufträge auf ein Band - da das inkrementelle Band bei uns immer von Dienstag bis Sonntag durchläuft (Montag ist Fullbackup), müssen die Aufträge logischerweise immer ans Band angehängt und nicht überschrieben werden Der HB- surstore hat 6 DAT's und erschreibt eins voll und danach wechselt er... Somit funktionieren incremental-Backups auf einem Band. -) Schedulemöglichkeit - ob das Programm jetzt ein Script ausspuckst, welches ich per Cron steuere oder das Scheduling selbst übernimmt ist eigentlich egal. Wenn ich aber alles eingestellt habe, soll die Geschichte ohne mein Zutun laufen (bis aufs Wechseln der Bänder, das erledige ich natürlich noch händisch :-) fuer amanda kein problem... ...und Baender wechseln muss ich erst nach 3 Wochen ;-)) -) Logfiles - muß ja schließlich wissen, ob das Backup erfolgreich war oder nicht Werden ebenfals erstellt... Noch eine generelle Frage: Wie schaut es mit der Hardwarekomprimierung aus? Muß ich das im Backup-Tool angeben oder reicht es, das Laufwerk selber auf Hardwarekompr. zu stellen? Oder muß ich sogar beides machen? Also ich habe die Hardware-Kompremierung deaktiviert, da die Software-Kompremierung zweimal staerker ist und auch nich mehr Zeit beansprucht... MfG Patrick Michelle -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
On Wed, Jan 29, 2003 at 03:58:23PM +0100, Patrick Petermair wrote: im Einsatz und kann mir mit Erfahrungsberichten helfen. Bzw. habe ich das ultimative Backup-Tool in meiner Liste vergessen? ja: amanda Seit ein paar Jahren verwende ich amanda, um meinen Server und die Workstation zu sichern. Bisher mußte ich aufgrund einer ausgefallenen Platte einmal meine kompletten Daten zurücksichern, was problemlos funktioniert hat. Gelegentliches Zurückspielen einzelner Dateien war bisher auch kein Problem. Nur die Handhabung des Restoreprogramms ist ziemlich gewöhnungsbedürftig. Was ich unbedingt brauche: -) Fähigkeit auf ein Tape (Compaq DLT 20/40) zu sichern geht -) Full / Inkrementelles Backup geht -) Mehrere Aufträge auf ein Band - da das inkrementelle Band bei uns immer von Dienstag bis Sonntag durchläuft (Montag ist Fullbackup), müssen die Aufträge logischerweise immer ans Band angehängt und nicht überschrieben werden geht afaik nicht Das ist eine extrem schlechte Methode, um Backups zu machen. Wenn Du Pech hast, fährt das Band beim Backup an die falsche Stelle, und die vorherigen Backups sind alle kaputt. Die DAT Bänder sind nun wirklich nicht so teuer, daß sich dieses Risiko lohnt. Mit einem Satz aus mindestens 6 Bändern (1 pro Tag plus eins extra) bist Du viel besser dran, und der reicht ein ganzes Jahr (weil DAT Bänder nur 50mal beschrieben werden sollen). Sowas steigert die Datensicherheit enorm im Vergleich zur Verwendung nur eines einzigen Bandes! (Bei DAT Bändern ist es mit Datensicherheit eh nicht weit her --- wenn das nicht die preiswerteste Variante wäre, würde ich kein DAT verwenden ...) Anstatt nur eines Bandes 6 Stück zu verwenden, ist nichtmal teurer. Da Du das eine Band sowieso alle zwei Monate austauschen mußt, kommst Du damit ebenfalls auf 6 Bänder pro Jahr. Und was machst Du z. B., wenn das Tagesband mal kaputtgeht? Eine ganze Woche Backups ist dann weg: Wehe, wenn Du dann zurücksichern mußt ... Was spricht gegen die Verwendung mehrerer Bänder? ich aber alles eingestellt habe, soll die Geschichte ohne mein Zutun laufen (bis aufs Wechseln der Bänder, das erledige ich natürlich noch händisch :-) Dafür ist amanda ideal! -) Logfiles - muß ja schließlich wissen, ob das Backup erfolgreich war oder nicht Die Logfiles sendet amanda Dir per Mail. Nach der einmaligen Einrichtung brauchst Du wirklich nur noch regelmäßig die Bänder zu wechseln, die Logfiles anzugucken und das Bandlaufwerk jede Woche einmal zu reinigen. Bequemer geht's kaum. Zudem kannst Du über's Netzwerk beliebig Rechner sichern, und amanda schont das Bandlaufwerk durch kontinuierliches Wegschreiben, indem auf Platte zwischengespeichert wird. Ganz unabhängig vom verwendeten Verfahren solltest Du hin und wieder eine Rücksicherung machen, um zu prüfen, ob auch wirklich gesichert wird. Ein paar Dateien reichen für den Test ja schon. Es klingt zwar blöd, ist aber ein Muß. Hardwarekomprimierung aus? Muß ich das im Backup-Tool angeben oder reicht es, das Laufwerk selber auf Hardwarekompr. zu stellen? Oder abschalten Mit amanda kannst Du wahlweise komprimiert oder unkomprimiert sichern. Die unkomprimierte Bandkapazität teilst Du amanda per Konfiguration mit, und die zu sichernde Menge wird automatisch an die Bandkapazität angepaßt --- für gewöhnlich funktioniert das ausgezeichnet. Für die zu sichernden Filesysteme kannst Du sogar Prioritäten vergeben ... GH -- zarathustra is not a registered protocol. -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
Harald Weidner schrieb: Ich würde das Backup auf keinen Fall verschlüsseln. Bei den gängigen Verschlüsselungsverfahren genügt ein einziges gekipptes Bit, um einen ganzen Block oder sogar den ganzen Rest des Backups unlesbar zu machen. Das nur ein Bit-Problem gibt es auch an ganz anderen Stellen. In jedem PC-System muss auch nur ein Bit der 55 AA Kennung am Ende des MBR kippen und der PC, sowie jedes fdisk meint, eine leere Platte vor sich zu haben. Für die meisten Leute ist dann schon Feierabend. Das Bit-Problem lässt sich bei Verschlüsselung und Komprimierug durch Wahl passender Verfahren auf einen Block beschränken. Wobei bei bzip2 der Block leider ca. 900K hat und das Restaurieren ordentlich Platz bräuchte. Von daher kann man entweder afio einsetzen, das jede Datei einzeln behandelt, oder wenn auch die Dateistruktur vertraulich bleiben muss, ein Backup vom Backup machen, also ein passendes Rotations- oder Backup-Prinzip einsetzen. Ein Beispiel: in den meisten Szenarien passen die wirklich wichtigen Daten auf eine CD. Zum Backup kann hier also ein über Loop-Device (loop-aes.sf.net) verschlüsseltes Image auf CD gebrannt werden. Hier wäre der Verlust auf ein Device-Block beschränkt. Darüber hinaus lassen sich solche Images nicht nur regelmässig brennen, sondern auch bequem automatisiert auf andere Systemen duplizieren und auslagern. Seien es eigene Server in anderen Lokationen, ein Root-Server beim Hoster oder bei einem kleinen Image reicht schon Webspace bzw. Mail-Account. Beim Alltags-Backups sollte das Problem also keine Rolle spielen. Bei Archiv-Backups ist das Medienproblem auch ohne Verschlüsseln und Komprimieren vorhanden und man muss sowieso identische Kopien auf mehreren Medien halten. Du siehst, letztendlich kommt es nicht auf die Theorie, sondern auf die praktische Umsetzung an. Oft wird es umgekehrt zum Verhängnis. Die Theorie (z.B. die theoretische Stärke eines Verschlüsselungsverfahren) ist gut, die praktische Umsetztung aber mangelhaft. Für meine Backups verwende ich immer noch das gute alte tar. Restores sind damit selbst auf exotischen Systemen kein Problem. Lies mal die Doku von star. Danach bist Du Dir sicher, gerade wenn es um Portabilität geht, bisher das falsche tar verwendet zu haben. ;-) -- [EMAIL PROTECTED] -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re[2]: Backupplanung
On 29.01.2003 18:37 Jens Benecke [EMAIL PROTECTED]: On Wed, Jan 29, 2003 at 05:25:29PM +0100, [EMAIL PROTECTED] wrote: Schau dir mal 'dump' an. Oder auch ein Uah. Ein Backupprogramm, das - weder auf einem anderen Betriebssystem noch auf ein anderes Dateisystem noch auf das gleiche Dateisystem mit einer anderen Blockgrösse restoren kann, - Spezialfeatures von ext2 nutzt und damit halt weder unter XFS, noch ReiserFS, noch sonst was funktioniert, - und angeblich keine sonderlich gute Verläßlichkeitsgeschichte hat würde ich nicht zum Sichern von Daten benutzen. =;) Musst Du auch nicht! ;-) Ich habe ihm auch nur gesagt was es sonst noch gibt! Es wird sich schon das fuer ihn passende raussuchen... In diesem Sinne... -- Mit freundlichen Gruessen / Best regards Thomas Kroener SVA System Vertrieb Alexander GmbH Thomas Kroener Unter den Eichen 7 65195 Wiesbaden Germany Tel.: +49 (0) 611 - 18 135 - 42 Fax: +49 (0) 611 - 18 135 - 78 Microsoft isn't the answer, Microsoft is the question. And the answer is NO! -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
Rainer Ellinger [EMAIL PROTECTED]: Wenn interessiert schon das Backup, wichtig ist das Restore ;-) Wo er recht hat, hat er recht! CD-R(W)s, Bänder und ähnlich leicht portable Medien sollten möglichst verschlüsselt werden. Es geht primär gar nicht mal um die perfekte Sicherheit. Es reicht schon, wenn jemand, der ein Medium entwendet oder im Müll findet, mit dem Medium alleine keine Daten wieder herstellen kann. Ich würde das Backup auf keinen Fall verschlüsseln. Bei den gängigen Verschlüsselungsverfahren genügt ein einziges gekipptes Bit, um einen ganzen Block oder sogar den ganzen Rest des Backups unlesbar zu machen. Falls die Backups doch verschlüsselt sein müssen, dann sollte man eine Stromchiffre verwenden, bei der sich jedes Bit des Chiffrats aus der XOR-Verknüpfung von Klartext und Schlüssel(-folge) ergibt. Ebenso würde ich Backups nicht komprimieren. Bei den gängigen Verfahren wie bzip2, gzip oder compress genügt ebenfalls ein einziges gekipptes Bit, um den gesamten Rest des Backups unlesbar zu machen. Für meine Backups verwende ich immer noch das gute alte tar. Restores sind damit selbst auf exotischen Systemen kein Problem. -- Harald Weidner [EMAIL PROTECTED] -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
Hallo Harald! Harald Weidner schrieb am Donnerstag, den 30. Januar 2003: Wenn interessiert schon das Backup, wichtig ist das Restore ;-) Wo er recht hat, hat er recht! CD-R(W)s, Bänder und ähnlich leicht portable Medien sollten möglichst verschlüsselt werden. Es geht primär gar nicht mal um die perfekte Sicherheit. Es reicht schon, wenn jemand, der ein Medium entwendet oder im Müll findet, mit dem Medium alleine keine Daten wieder herstellen kann. Ich würde das Backup auf keinen Fall verschlüsseln. Wenn es sich vermeiden laesst nicht, wenn es aber so deponiert ist dass auch Unbefugte rankommen koennen auf jeden Fall (wir haben z.B. keinen extra Backup Safe). Bei den gängigen Verschlüsselungsverfahren genügt ein einziges gekipptes Bit, um einen ganzen Block oder sogar den ganzen Rest des Backups unlesbar zu machen. Du kannst ja Datei-weise verschlüsseln. afio kann man z.B. ein externes Programm mitgeben durch das er alle Dateien durchschicken soll. Damit ist eine Verschlüsselung (und Kompression) auf Dateibasis problemlos moeglich. Mit einem Public Key Verfahren läuft das dann auch von alleine absolut sicher. -- MfG Thomas Mueller - http://www.tmueller.com for pgp key (95702B3B) -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Backupplanung
Hi! In naher Zukunft wird es endlich soweit sein, einer unser Windowsserver wird auf Debian/Linux umgestellt. Es sind soweit alle Aspekte bedacht, lediglich die Frage des Backups steht noch im Raum. Früher haben wir Veritas BackupExec verwendet. War soweit recht komfortabel ... für Linux habe ich mich jetzt auf die Suche gemacht und einige Backupprogramme gefunden. Hier nun meine aktuellen Favoriten: tob Vorteil: kleines, feines Shellscript, ganz in Linuxmanier Nachteil: bis jetzt noch nicht wirklich viel Doku gefunden kbackup Vorteil: übersichtliches Menü, auch für nicht-Linux-Gurus geeignet und eine umfangreiche Dokumentation Nachteil: soweit sehe ich keinen... arkeia Vorteil: eigentlich kostenpflichtig, allerdings gibt es eine gratis Lightversion, die keine für meine Situation betreffende Abschnitte macht (gegenüber der Full). Da es kommerziell ist, gibt es klarerweise auch viel Doku. Nachteil: GUI Programm - und ich mag nicht so wirklich X installieren auf dem Server. Außerdem habe ich in 1,2 Newsgroups-Beiträgen gelesen, dass arkeia nicht ganz so stabil laufen soll. taper Vorteil: wie kbackup ein kleines übersichtliches ncurses Menü und gute Doku Nachteil: ? So, das sind mal meine Favoriten bis jetzt. Hat irgendwer eines dieser Tools im Einsatz und kann mir mit Erfahrungsberichten helfen. Bzw. habe ich das ultimative Backup-Tool in meiner Liste vergessen? Was ich unbedingt brauche: -) Fähigkeit auf ein Tape (Compaq DLT 20/40) zu sichern -) Full / Inkrementelles Backup -) Mehrere Aufträge auf ein Band - da das inkrementelle Band bei uns immer von Dienstag bis Sonntag durchläuft (Montag ist Fullbackup), müssen die Aufträge logischerweise immer ans Band angehängt und nicht überschrieben werden -) Schedulemöglichkeit - ob das Programm jetzt ein Script ausspuckst, welches ich per Cron steuere oder das Scheduling selbst übernimmt ist eigentlich egal. Wenn ich aber alles eingestellt habe, soll die Geschichte ohne mein Zutun laufen (bis aufs Wechseln der Bänder, das erledige ich natürlich noch händisch :-) -) Logfiles - muß ja schließlich wissen, ob das Backup erfolgreich war oder nicht Noch eine generelle Frage: Wie schaut es mit der Hardwarekomprimierung aus? Muß ich das im Backup-Tool angeben oder reicht es, das Laufwerk selber auf Hardwarekompr. zu stellen? Oder muß ich sogar beides machen? MfG Patrick -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
Hi Patrick On 29.01.2003 15:58 Patrick Petermair [EMAIL PROTECTED] wrote: In naher Zukunft wird es endlich soweit sein, einer unser Windowsserver wird auf Debian/Linux umgestellt. Es sind soweit alle Aspekte bedacht, lediglich die Frage des Backups steht noch im Raum. Früher haben wir Veritas BackupExec verwendet. War soweit recht komfortabel ... für Linux habe ich mich jetzt auf die Suche gemacht und einige Backupprogramme gefunden. Hier nun meine aktuellen Favoriten: schnipp /schnipp So, das sind mal meine Favoriten bis jetzt. Hat irgendwer eines dieser Tools im Einsatz und kann mir mit Erfahrungsberichten helfen. Bzw. habe ich das ultimative Backup-Tool in meiner Liste vergessen? Was ich unbedingt brauche: -) Fähigkeit auf ein Tape (Compaq DLT 20/40) zu sichern -) Full / Inkrementelles Backup -) Mehrere Aufträge auf ein Band - da das inkrementelle Band bei uns immer von Dienstag bis Sonntag durchläuft (Montag ist Fullbackup), müssen die Aufträge logischerweise immer ans Band angehängt und nicht überschrieben werden -) Schedulemöglichkeit - ob das Programm jetzt ein Script ausspuckst, welches ich per Cron steuere oder das Scheduling selbst übernimmt ist eigentlich egal. Wenn ich aber alles eingestellt habe, soll die Geschichte ohne mein Zutun laufen (bis aufs Wechseln der Bänder, das erledige ich natürlich noch händisch :-) -) Logfiles - muß ja schließlich wissen, ob das Backup erfolgreich war oder nicht Noch eine generelle Frage: Wie schaut es mit der Hardwarekomprimierung aus? Muß ich das im Backup-Tool angeben oder reicht es, das Laufwerk selber auf Hardwarekompr. zu stellen? Oder muß ich sogar beides machen? Schau dir mal 'dump' an. Oder auch ein apt-cache search backup wird Dir eine nette Liste anzeigen, die Dir evtl weiterhilft. ciao Thomas -- Mit freundlichen Gruessen / Best regards Thomas Kroener SVA System Vertrieb Alexander GmbH Thomas Kroener Unter den Eichen 7 65195 Wiesbaden Germany Tel.: +49 (0) 611 - 18 135 - 42 Fax: +49 (0) 611 - 18 135 - 78 Microsoft isn't the answer, Microsoft is the question. And the answer is NO! -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, On Mittwoch, Januar 29, 2003, at 03:58 Uhr, Patrick Petermair wrote: taper Vorteil: wie kbackup ein kleines übersichtliches ncurses Menü und gute Doku Nachteil: ? kann nur bis 2 GB zuverlässig backuppen - kommt also für Produktiveinsatz kaum in Frage. Ich kann in dieser Hinsicht afbackup empfehlen - gutes Client-Server-System, gute Doku, Debs - ich setze das bereits seit ca. 1 Jahr produktiv ein und bin damit sehr zufrieden. Was ich unbedingt brauche: -) Fähigkeit auf ein Tape (Compaq DLT 20/40) zu sichern -) Full / Inkrementelles Backup -) Mehrere Aufträge auf ein Band - da das inkrementelle Band bei uns immer von Dienstag bis Sonntag durchläuft (Montag ist Fullbackup), müssen die Aufträge logischerweise immer ans Band angehängt und nicht überschrieben werden -) Schedulemöglichkeit - ob das Programm jetzt ein Script ausspuckst, welches ich per Cron steuere oder das Scheduling selbst übernimmt ist eigentlich egal. Wenn ich aber alles eingestellt habe, soll die Geschichte ohne mein Zutun laufen (bis aufs Wechseln der Bänder, das erledige ich natürlich noch händisch :-) -) Logfiles - muß ja schließlich wissen, ob das Backup erfolgreich war oder nicht Alle Anforderungen können mit afbackup erfüllt werden... (Ich sichere auf SLR100 und DAT DDS4) Noch eine generelle Frage: Wie schaut es mit der Hardwarekomprimierung aus? Muß ich das im Backup-Tool angeben oder reicht es, das Laufwerk selber auf Hardwarekompr. zu stellen? Oder muß ich sogar beides machen? ich würde sagen, kommt drauf an, wie schnelle der betreffende Server ist (nicht das das Bandlaufwerk auf Grund hoher Komprimierung nicht mit maximaler Geschwindigkeit schreiben kann) und, ob Dir der Platz auf dem Band nicht ohnehin mit simpler HW-Komprimierung reicht. afbackup ist auch hier ziehmlich flexibel... Hope it helps, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+OAs1nqIBIo4jYbARAlt0AJwJVHu28raB97hv+8nZwHRIjOnNSwCfY/sW k/6sOiOttbVjhFZlAHIp5Jg= =RsUM -END PGP SIGNATURE- -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Backupplanung
On Wed, Jan 29, 2003 at 05:25:29PM +0100, [EMAIL PROTECTED] wrote: Schau dir mal 'dump' an. Oder auch ein Uah. Ein Backupprogramm, das - weder auf einem anderen Betriebssystem noch auf ein anderes Dateisystem noch auf das gleiche Dateisystem mit einer anderen Blockgrösse restoren kann, - Spezialfeatures von ext2 nutzt und damit halt weder unter XFS, noch ReiserFS, noch sonst was funktioniert, - und angeblich keine sonderlich gute Verläßlichkeitsgeschichte hat würde ich nicht zum Sichern von Daten benutzen. =;) -- mfg, Jens Benecke http://www.hitchhikers.de: Europas Mitfahrzentrale seit 1998 Fahren Sie zusammen, sparen Sie Geld - unkompliziert und schnell! NEU: Jetzt mit kostengünstiger, umfassender Unfallversicherung! msg34297/pgp0.pgp Description: PGP signature
Re: Backupplanung
Patrick Petermair schrieb: So, das sind mal meine Favoriten bis jetzt. Hat irgendwer eines dieser Tools im Einsatz und kann mir mit Erfahrungsberichten helfen. Bzw. habe ich das ultimative Backup-Tool in meiner Liste vergessen? Wenn interessiert schon das Backup, wichtig ist das Restore ;-) Spiel Deine Restore-Szenarien durch. Für mich ist daher meistens wichtig, dass die notwendigen Tools schnell und überall beschaffbar sind, also afio oder star, und dazu bzip2 und mcrypt. afio hat im Gegensatz zu tar den Vorteil, die Dateien einzeln zu komprimieren und nicht das ganze Archiv. Wird das Archiv teilweise beschädigt, geht nicht direkt alles darauf folgende verloren. CD-R(W)s, Bänder und ähnlich leicht portable Medien sollten möglichst verschlüsselt werden. Es geht primär gar nicht mal um die perfekte Sicherheit. Es reicht schon, wenn jemand, der ein Medium entwendet oder im Müll findet, mit dem Medium alleine keine Daten wieder herstellen kann. Aber bei Verschlüsselung würde ich nur auf freie und offene Software setzen. Passwortabfragen in kommerziellen Produkten sind technisch gesehen auch mal gerne mehr Fake, als ein wirklicher Schutz. müssen die Aufträge logischerweise immer ans Band angehängt und nicht überschrieben werden -) Dafür einfach das richtige Device wählen. z.B. /dev/nst0 und mit mt entsprechend positionieren, sonst wird vor jeder Aktion zurückgespult. Wie schaut es mit der Hardwarekomprimierung aus? Nichts als Marketing-Gag! Die Prospekte rechnen mit 2:1 und geben immer gerne die angeblichen Brutto-Kapazitäten an. Bei Allerweltsdaten kommen aber vielleicht 1,1:1 heraus. Mehr als 1,4:1 habe ich in freier Wildbahn noch nicht gesehen. Dazu muss man wohl eine Platte mit lauter Nullen sichern. Ergo: abschalten und mit den Netto-Kapazitäten rechnen. Alles andere irritiert nur. Wenn Du ordentliche Komprimierung benötigst, bleibt nur Software a la gzip/bzip. Wobei es notwendig ist, genau hin zu schauen, wie schnell diese arbeitet und ob es zur CPU-Ausstattung passt. Sonst kann es schnell passieren, dass das Backup plötzlich -zig mal solange benötigt. Das ist gerade bei Schrägspurverfahren nicht so praktisch, weil sich so die Belastung von Laufwerk und Bändern entsprechend vervielfacht. -- [EMAIL PROTECTED] -- Häufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
