Heinz Diehl schrieb:

On 19.03.2009, Dieter Lukas wrote:

...

ich benutze seit kurzem opensuse 11.0, gnome und suche ein backup-Programm. Damit will ich die neuen und geänderten Dateien u.a. im Ordner 'Dokumente' oder alle emails neu, geändert und nicht geändert sichern.

man rsync

--------------------- Marko Käning schrieb:

Ich nehme immer storeBackup, was letzterem sehr ähnlich sein muss. Kann ich nur empfehlen. Habe seit Jahren damit nur gute Erfahrungen gemacht.

--------------------- Roman Fietze schrieb:

Hallo Dieter,

Ich nehm mal an, dass etwas wie Amanda oder Bacula zu fett fuer deinen Anwendungsfall ist.

Also bleiben u.A. rsync, oder darauf aufsetzend und inkrementell (mit Hostory) rsnapshot.

ZU beiden Programmen gibt es gute manpages und auch andere Dokumentation.

...

Ist dafür 'dump' geeignet?

Jein. Denn wenn du nicht ext[23] hast brauchst du etwas Anderes als dump.

Roman

------------------------------- Hallo, dann werde ich mir mal die mans von rsync, rsnapshot und storeBackup ansehen (wenn mein usb-stick, auf dem ich bisher händisch gesichert habe, wieder tut - meint, dass er nur noch gelesen werden kann). Mein Dateisystem ist glaube ich ext, so wie es von der suse-Installation angelegt wurde. Wie kann ich das eigendlich nachprüfen? Vielen Danmk für Eure Hilfen. dieter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

On 22.03.2009, Dieter Lukas wrote: [....] Ein "rsync -avx --delete /quellordner/ /zielordner" sichert dir schnell und unproblematisch den gesamten Quellordner. Zielordner wird dabei auf den selben Stand wie Quellordner gebracht, es werden nur die Veraenderungen mit einbezogen, es wird nicht jedes Mal ein Vollbackup gemacht. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Michael und Heinz, -------- Original-Nachricht --------

Datum: Sun, 22 Mar 2009 14:03:18 +0100 Von: Michael Kohaupt An: opensuse-de@opensuse.org Betreff: Re: Danke: backup-Programm

Heinz Diehl schrieb:

...

Ein "rsync -avx --delete /quellordner/ /zielordner" sichert dir schnell und unproblematisch den gesamten Quellordner. Zielordner wird dabei auf den selben Stand wie Quellordner gebracht, es werden nur die Veraenderungen mit einbezogen, es wird nicht jedes Mal ein Vollbackup gemacht.

Heinz, Deine Empfehlung ist eher eine Synchronisation von Verzeichnisinhalten als das, was man unter einem Backup versteht. Sie ist sogar gefährlich, und zwar wegen --delete. Hast Du nämlich im Zielverzeichnis schon ein älteres Backup, werden dort mit Deiner Empfehlung alle Dateien gelöscht, die zuvor im Quellverzeichnis und dessen untergeordneten Verzeichnissen gelöscht wurden. Welch ein Desaster, wenn der Benutzer ganze Unterverzeichnisse versehenlich gelöscht hat, denn die sind nämlich beim nächsten Backup endgültig weg! Es ist kaum der Sinn eines sicheren Backups, wenn das Skript eine Zeitbombe für die Vernichtung der eigentlich sichergelaubten Daten ist. Unkritisch aber auch überflüssig wäre --delete bei der Sicherung der Daten in ein neues, und daher leeres Zielverzeichnis. Dann hätte man aber eine weitere Voll-Backup-Generation, was zwar nach versehentlichem Löschen höchst sinnvoll, aber für den Sicherungsvorgang zeitraubend und auch speicherplatzintensiv sein kann. Wenn man eben nicht wieder alle unveränderten Daten erneut sichern will (z.B. die eines riesigen Home-Verzeichnisses, wo sich zw. Sicherungen nur wenig ändert), dann ist die Option --link-dest= sinnvoll, weil hier für alle unveränderten Dateien Hardlinks angelegt werden. Aber jede Backup-Generation sieht aus, wie ein Voll-Backup. Will man nur differentielle Sicherungen, also ohne Hardlinks nur neue und veränderte Dateien kopieren, dann ist --compare-dest= Dein Freund. Für eine "Synchronisation von Verzeichnisinhalten", wo auch im Zielordner Veränderungen unabhängig vom Quellordner stattfinden, fehlt übrigens die Option -u, --update, mit der Dateien im Zielverzeichnis nur überschrieben werden, wenn diese älter sind als die entsprechenden im Quellverzeichnis. Für eine echte Synchronisaton braucht man dann noch die umgekehrte Kopie von Daten mit vertauschtem Ziel- und Quellverzeichnis, wieder mit -u. Gerade da ist --delete gefährlich, weil einem eine Datei, die man gerade bearbeitet hat, von der anderen Seite aus gelöscht werden kann, bloß, weil sie dort zuvor gelöscht wurde und diese Seite von der Arbeit auf der anderen Seite vielleicht nichts weiß. Aber auch hierfür stellt rsync Abhilfe bereit, worauf ich hier jetzt nicht mehr eingehen möchte. Mehr gern via PM.

Mich wundert, dass immer nur rsync genannt wird. Wie wäre es mit rdiff?

Rdiff kenne ich nicht. Rsync kopiert auch, aber nicht nur differentiell, sondern z.B. mit --delete löscht es sogar Daten im Zielverzeichnis. Das würde ich nach meiner obigen Begründung eher synchronisieren nennen. Andrew Tridgell hat m.W. das Programm ursprünglich auch für den Zweck geschrieben (siehe seine Beispiele in der Manpage). Inzwischen ist es extrem vielseitig geworden. Ich verwende es schon Jahre mit stetig wachsendem Gewinn ... selten in der Welt der Software.

Und dazu gibt es ein feines kleines Progrämmchen -> keep 0.4.0 Einmal eingerichtet, braucht man sich um überhaupt nichts mehr kümmern.

Verlockend, aber gefährlich, davon kann Dir jeder Admin ein Lied singen. Bekommt man wenigstens Fehlermeldungen per Mail oder so?

Backupd alles gewünschte vollautomatisch im Hintergrund. Sichert beim ersten Mal alles komplett und danach nur noch Veränderungen.

Tut ein Skript mit rsync genauso, bewahrt dabei je nach Wunsch mehrere Backup-Generationen auf, löscht älteste Backups, wenn der Plattenplatz knapp wird und noch vieles mehr. Kann keep auch entfernte Hosts über Internet und SSH-Tunnel bandbreitesparend sichern? Gutes Backup ist keine komplizierte, aber u.U. eine vielschichtige Sache, wo es einiges zu bedenken gibt. Das kommt einem bei eingem Nachdenken automatisch, spätestens aber, wenn man sich Gedanken zur Wiederherstellung macht, und das sollte man ... Andrew Tridgell hat sich jedenfalls viele gute und höchstpraktische Gedanken gemacht. Rsync ist für mich eines der besten und nützlichsten Tools überhaupt. Herzliche Grüße Tom -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, -------- Original-Nachricht --------

Datum: Sun, 22 Mar 2009 19:19:57 +0100 Von: Heinz Diehl An: opensuse-de@opensuse.org Betreff: Re: Danke: backup-Programm

At Sun, 22 Mar 2009 15:26:08 +0100, Thomas Michalka wrote:

...

Heinz, Deine Empfehlung ist eher eine Synchronisation von Verzeichnisinhalten als, was man unter einem Backup versteht.

Ja, so habe ich das auch beschrieben. Es gleicht das Zielverzeichnis mit dem Quellveryeichnis ab, und da...

Ja, aber nach dem Subject wollte der OP eben ein Backup-Programm, kein Synchronisationswerkzeug für den allerletzten Stand.

...

Sie ist sogar gefährlich, und zwar wegen --delete. Hast Du nämlich im Zielverzeichnis schon ein älteres Backup, werden dort mit Deiner Empfehlung alle Dateien gelöscht, die zuvor im Quellverzeichnis und dessen untergeordneten Verzeichnissen gelöscht wurden.

...ist es perfekt, wenn die Veraenderungen aus dem Quellverzeichnis auch im Zielverzeichnis ausgefuehrt werden.

Ist es das für Dich auch, wenn Du versehentlich eine ultra-wichtige Datei löschst? Woher holst Du die dann zurück? Na, Du wirst ja sicher noch an anderer Stelle ein richtiges Backup haben.

War nur ein Vorschlag, analog zu dem, wie ich meine Backups mache. Wenn bei mir eine Platte defekt

Also machst Du "Backups" doch so. Nach allen Regeln der Kunst sind das aber keine, denn: Schlagartig defekte Platten kommen (nicht nur nach meinen Erfahrungen) extrem selten vor im Gegensatz zu benutzerverursachten "Unfällen" und schleichenden Ausfällen. In der Häufigkeit vergleichbar mit letzteren sind n. m. Erf. Defekte in Dateisystemen - klar, weil schleichend kaputtgehende Platten Inkonsistenzen in Dateisystemen verursachen können. Das ist eine besonders heimtückische Fehlerquelle, bei der sich über Tage die defekten Superblocks, Inodes häufen können und sich damit die Zahl der unerreichbaren Dateien allmählich häuft. Das kann dazu führen, daß mit --delete Dateien auf dem Backup-Medium in der einzigen Sicherung gelöscht werden, die Du selber auf dem Quellmedium nicht mal versehentlich gelöscht hast, denn eine Datei, die nicht auffindbar ist, ist für rsync nicht vorhanden.

ist, dann will ich den aktuellen Stand zurueckspielen,

In den von mir beschriebenen Fällen, ist der letzte Stand ein Mißstand, wahrscheinlich voller Inkonsistenzen, den Du doch kaum wiederhaben willst, oder?

und da nuetzen mir evtl. aeltere Daten nichts. Deswegen --delete.

Ältere Daten, die Du nicht mehr willst, wirst Du sicher absichtlich gelöscht haben. Überlege Dir mal, was rsync --link-dest in einem anschließenden Backup tut, besser gesagt "nicht tut". Es sichert natürlich in den letzten gültigen Backup, zunächst ein leeres Verzeichnis, nennen wir es <backup-base-dir>/2009-03-3__daily.letzter/home, *keine* gelöschten Dateien, d.h. es legt auch keine Hardlinks auf Dateien an, die in einem früheren Backup noch gesichert wurden. Hardlinks legt rsync --link-dest nur auf vorhandene _und_ unveränderte Dateien im Backup <backup-base-dir>/2009-03-3__daily.1/home an, wenn man das als Referenzverzeichnis hinter --link-dest angibt. Natürlich kann man auch *.daily.28/home wählen, dann ist nur die Menge der tatsächlich kopierten Daten größer, was sowohl den Vorteil der Speicherplatz- als auch der Backup-Zeitersparnis schmälert. Sagen wir, Du behältst 28 tägliche Backups von *.daily.01/home bis *.daily.28/home, dann besteht eine gute Chance, die wie auch immer in den letzten 28 Tagen verlorenen Dateien aus 28 Backup-Generationen wiederherzustellen. Diese Chance hast Du überhaupt nicht, wenn Du immer nur im selben Zielverzeichnis den allerletzten Stand zu Deiner Quelle synchron hältst. Also nützen Dir ältere Backup-Generationen sehr wohl etwas.

Das ist in diesem Falle kein Sicherheitsrisiko, sondern erwuenscht.

Ein Sicherheitsrisiko ist es auf jeden Fall für den, der glaubt oder den man glauben macht, er hätte damit ein sicheres Backup. Wer, wie Du, weiß was er tut, geht das Risiko bewußt ein. Aber Du solltest niemandem raten, mit --delete Backups anzulegen, der noch kein Backup-Werkzeug kennt und auch noch fragt, wie man die Dateisysteme auf den Partitionen bestimmen kann. Da wäre es ja noch besser ohne --delete in nur ein Verzeichnis zu synchronisieren. Fällt Dir eine Platte ohne Vorwarnungen aus, dann haben Backups mit Hardlinks den Vorteil, daß Du den letzten gesicherten Stand, wie von einem Voll-Backup auf einen Rutsch wiederherstellen kannst. Also mußt Du nicht einen alten Voll-Backup plus eine oder mehrere differentielle Sicherungen einspielen. Zusätzlich kannst Du evtl. früher schon gelöschte Dateien wiederherstellen. Noch ein Vorteil: jeder Benutzer kann das selber tun, wenn Du ihm z.B. per NFS die Backup-Generationenverzeichnisse vom Backup-Server readonly zur Verfügung stellst, vorausgesetzt, Du hast die Daten mir der Option --numeric-ids gesichert, denn die Benutzer-Accounts wird es dort i.d.R. nicht geben. Solltest Du aber gar keine richtigen Backups machen wollen, sondern nur den letzten Stand sychronisieren, dann habe ich an Deiner Intention vorbeigeschrieben, aber Du hättest dann in diesem Thread das Thema verfehlt, denn es ging von Anfang an um Backup-Software. BTW: Interessanterweise sieht man an der Statistik, die rsync am Ende eines Backups ausgibt (--stats, s.u.), wenn sich die Zahl der Dateien in einem Quellverzeichnis über einen relativ kurzen Zeitraum ungewöhnlich stark verringert, vorausgesetzt man liest das Logfile hinundwieder. Das sieht z.B. so aus: Number of files: 2351460 Number of files transferred: 713 Total file size: 154.07G bytes Total transferred file size: 273.97M bytes Literal data: 273.97M bytes Matched data: 0 bytes File list size: 53.73M File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 327.95M Total bytes received: 212.58K sent 327.95M bytes received 212.58K bytes 208.52K bytes/sec total size is 154.07G speedup is 480.76 Diesen Endabschnitt des Logfiles kann man auch automatisch auf ungewöhnliche Veränderungen charakteristischer Kennzahlen analysieren und sich das Ergebnis per Mail schicken lassen. Verringern sich z.B. "Number of files", "Total file size" und/oder "File list size", könnte mit dem Dateisystem was faul sein. Aber dafür gibt es vielleicht noch bessere Indizien. Da käme --delete vielleicht doch wieder zu Ehren. Man könnte z.B. ein Verzeichnis zur Kontrolle parallel zu jedem Backup-Lauf mitsynchronisieren (mit --delete und mit --link-dest, was enorm Zeit und Platz spart). Wenn eines Tages im Logfile ungewöhnlich viele Löschungen verzeichnet würden, könnte einen das auch stutzig machen. Aber: Das Löschen von großen Verzeichnisbäumen kann beim Backup erheblich Zeit kosten, so daß der Zeitraum des Backups relativ lang wird, was bei voneinander abhängigen Dateien zu Inkonsistenzen führen kann. Übrigens ist gerade der Zeitvorteil bei Backups mit Hardlinks gegenüber Voll-Backups gewaltig. Meine 154 GBytes von /home werden vollständig in knapp sechs Stunden, als differentieller Backup plus Hardlinks in ca. 26 Minuten kopiert! Nur so kann man überhaupt sinnvolle stündliche Backups machen.

Ansonsten hatte ich dem OP auch zualererst empfohlen, die manpage zu lesen. ;-)

Das ist generell sinnvoll, vor allem bei einer so guten. Ciao, Tom -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, -------- Original-Nachricht --------

Datum: Tue, 24 Mar 2009 02:19:59 +0100 Von: Florian Gross An: opensuse-de@opensuse.org Betreff: Re: Danke: backup-Programm

Hallo,

vorneweg: Thomas, könntest du bitte deine Zeilenlänge auf ca. 70 Zeichen/Zeile reduzieren?

Dank für den Hinweis? Komisch, bei mir sieht das nicht so aus, auch nicht, wenn ich meine eigenen Mails an die Liste ansehe, und Beschwerden diesbezüglich hatte ich noch keine. Gibt es noch andere, die das so beobachten? Ich werde der Sache jedenfalls gleich nachgehen. Gruß, Tom -- Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt? Jetzt absichern: https://homebanking.gmx.net/?mc=mail@footer.hb -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Halo zusammen, On Dienstag 24 März 2009, Thomas Michalka wrote:

Gibt es noch andere, die das so beobachten?

Ich habe damit zwar kein Problem, aber Dein Mailprogramm bricht definitiv nicht nach den üblichen 72 Zeichen um. Wenn Dein header mich nicht anlügt, dann benutzt Du ein Webinterface. Keine Ahnung, wo Du das da einstellen kannst. Liebe Grüße Erik -- "Menschen, die nicht rauchen, haben entweder keine große Trauer gekannt oder verweigern sich dem sanftesten Trost, der dem Trost des Himmels am nächsten kommt." Edward George Bulwer-Lytton Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, -------- Original-Nachricht --------

Datum: Sun, 22 Mar 2009 22:06:06 +0100 Von: Arno Lehmann An: opensuse-de@opensuse.org Betreff: Re: Danke: backup-Programm

Hallo,

22.03.2009 15:26, Thomas Michalka wrote:

...

Hallo Michael und Heinz,

...

Gutes Backup ist keine komplizierte,

Na ja... spätestens wenn's um Datenbanken

Ja, bei Datenbanken ist es meistens nicht sinnvoll, einfach die Dateien zu sichern, denn Inkonsistenzen der DB wären vorprogrammiert. Bei mysql kann einem mysqldump (oder so ähnlich?) helfen. Daraufhin sichert rsync ein in sich konsistentes DB-File.

geht oder schnellses Wiederfinden von Dateien zu bestimmten Sicherungszeitpunkten kann das schon kompliziert werden...

Ich lege Sicherungen in folgende Verzeichnisstruktur: /backup/<host>/2009-03-23---daily.latest/<Quellverzeichnisname> Anschließend wird durchrotiert (ältestes *.daily.28 wird gelöscht, die anderen zyklisch umbenannt, das *daily.latest nach *.daily.1). Damit kann jeder Benutzer seine verlorenen Dateien relativ leicht mit Systemsuchwerkzeugen, wie find (für unerfahrene Benutzer gibt es auch intuitivere Suchwerkzeuge) auffinden und per simples Kopieren im Datei-Manager wiederherstellen. Für full-disaster-recoveries muß halt der Admin ran.

...

aber u.U. eine vielschichtige Sache, wo es einiges zu bedenken gibt. Das kommt einem bei eingem Nachdenken automatisch, spätestens aber, wenn man sich Gedanken zur Wiederherstellung macht, und das sollte man ... Andrew Tridgell hat sich jedenfalls viele gute und höchstpraktische Gedanken gemacht. Rsync ist für mich eines der besten und nützlichsten Tools überhaupt.

Rsync ist nett, aber ein richtiges Backupprogramm für mehr als eine Handvoll Rechner wird daraus auch mit Wrapper nicht.

Sehe ich nicht so. Ich finde, wenn man das Problem prinzipiell für einen Host gelöst hat, dann stellt sich bei vielen Rechnern eher die Frage, wieviele Backup-Jobs der Backup-Server auf einmal erledigen kann, bzw. wieviele gleichzeitige Transfers das Netzwerk bewältigt. Ansonsten skaliert eine rsync- oder auch rsnapshot-Lösung sehr gut.

Wenn's um mehr als drei Rechner geht: www.bacula.org

Davon würde ich mir Funktionen erhoffen, Dateien aus verschiedenen Backup-Generationen schnell inhaltlich vergleichen zu können. Das wäre wichtig, wenn man innerhalb einer Datei mal versehentlich große Teile gelöscht hat. Also ein ausgefeiltes, individuelles Recovery. Schöne Grüße, Tom -- Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt? Jetzt absichern: https://homebanking.gmx.net/?mc=mail@footer.hb -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 20 März 2009, Guido Pinkernell wrote:

Für den Betrieb im Netzwerk und auch sonst etwas unhandlich, da man einzelne Dateien nicht ohne weiteres im großen "Teerball" identifizieren kann.

Kommt auf das Netz an. ;) Zum Entpacken einzelner Dateien nehme ich den guten alten mc. Enter auf die Datei und schon kann man alles sehen und auch einzeln rauskopieren, wenn es denn notwendig ist. Liebe Grüße Erik P.S.: Das beste backup ist das, welches man nie braucht. ;) -- Erhabener Tabak! In West und Ost des Türken Labsal und des Seemanns Trost! Der du verschöst des Paschas Polsterbette mit Opium und Weibern um die Wette, prunkvoll in Stambul, minder imposant, doch minder nicht geliebt am Themsestrand, himmlisch in Hukas, köstlich in der Pfeife mit Ambrageschmack, voll Milde, Füll und Reife, gleich andern Reizen, wirbst du gern um Gunst, blendend in Gala und verschönt von Kunst; der Kenner aber gönnt den Putz dem Narren und liebt die nackte Schönheit der Zigarren. Lord Byron Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 20 März 2009, Marko Käning wrote:

tar.gz zumindest ist für Backups NICHT zu empfehlen!

Das mache ich schon seit Jahren und hatte nie Probleme. Liebe Grüße Erik -- "Es soll Kubas göttliches Narkotikum mit blauen Flocken meinen Dichterdivan beladen. Die Zigarre hat oftmals meine Verse gelingen lassen. Auch jetzt wird mich, wie ich hoffe, dieser Gott inspirieren." Auguste Barthélémy Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo Marko, On Friday 20 March 2009 17:00:09 Marko Käning wrote:

tar.gz zumindest ist für Backups NICHT zu empfehlen! (Habe selbst schon 5 von 7 GB Daten verloren, weil mein tar.gz irgenwo einen Bitfehler hatte!)

Da wuerde ich doch eher mal nach der Ursache der Bitfehler suchen. Aber klar ist, wer Wert darauf legt einzelne Files "schnell mal" wieder zu restaurieren, der ist mit Loesungen wie rsync oder rsnapshot besser bedient.

Wenn schon Komprimierung, dann dateiweise.

Macht das nicht Bacula so (ich meine im Vergleich zu Amanda falls Komprimierung auf dem Host oder Slave und nicht dem Tape aktiviert ist)? Roman -- Roman Fietze Telemotive AG Büro Mühlhausen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, 23.03.2009 07:33, Roman Fietze wrote:

Hallo Marko,

On Friday 20 March 2009 17:00:09 Marko Käning wrote: ...

...

Wenn schon Komprimierung, dann dateiweise.

Macht das nicht Bacula so

Ja. Bei Bitfehlern auf dem endgültigen Speichermedium würde ich mich aber auch nicht 100%ig darauf verlassen dass dann im Zweifelsfall nur eine einzige Datei Probleme macht - wenn irgendwelche Header defekt sind führt das häufig genug dazu, dass das ganze Volume nicht mehr lesbar ist.

(ich meine im Vergleich zu Amanda falls Komprimierung auf dem Host oder Slave und nicht dem Tape aktiviert ist)?

Bacula komprimiert immer auf dem Client, oder überlässt - typischerweise bei Bandlaufwerken - die Komprimierung der Hardware. Natürlich könnte man auch auf komprimierende Dateisysteme schreiben. Arno

Roman

-- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org