Hallo Liste,
derzeit versuche ich die Backup-Funktionen auf einem unserer Server zu optimieren. Bei einem Voll-Backup wird zunächst mittels »find« eine Dateiliste erstellt, welche anschließen über »tar --files-from <DATEILISTE>« eingelesen wird. Ohne diese Dateiliste springt mich der Prozess irgendwann mit einer Fehlermeldung an, da sich die Daten innerhalb der Ordnerstruktur ändern können (hauptsächlich kommen Dateien hinzu). Welche Möglichkeit habe ich, diese Fehlermeldung zu unterdrücken? Gibt es ein anderes Archiviersystem, welches ihr mir stattdessen empfehlen würdet? Wie machen es "richtige" Backup-Programme, wenn sie von einem Live-System Daten sichern sollen? "Warum der Aufwand?" könnte nun eine Frage lauten. Der »find«-Prozess schluckt aufgrund der hohen Anzahl (kleiner) Dateien eine Menge Zeit. Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
derzeitiger Ablauf: »find« > »tar« > »pbzip2«
Gruß
Björn
Hallo Björn,
Gibt es ein anderes Archiviersystem, welches ihr mir stattdessen empfehlen würdet?
Ich verwende derzeit gern "bacula" - ne "richtige" Backupsoftware, dafür sollte man entweder etwas Zeit fürs Handbuch mitbringen oder schon Verständnis für Backups mit Pools usw. mitbrigen. Ich habe letzterse und so keine 2h gebraucht was Sinnvolles mit 2 Generationen auf 2 verschiedenen Medientypen zu sichern. Alternatv, wenns schnell gehen soll biete sich rsync an, wozu es mit rsnapshot ne ressourcensparende fast fertige Lösung gibt - vllt. ist das genau der richtige Einstieg für Dich sofern Dein Ziel irgendwie unixoid ist.
es "richtige" Backup-Programme, wenn sie von einem Live-System Daten sichern sollen?
Das kann man Pauschal nicht beantworten. Mnache arbeiten mit Snapshots von den zu sichernden Volumes, sie frieren also die Partition quasi ein, sichern den "Eiswürfel" während das OS in einen "Zwischenspeicher" arbeitet. Das muss aber das OS bzw. Storage unterstützen. Wieder andere auf Client/Serverbasis machen es im Grunde wie Du, einen Katalog aufbauen, was lokal verfügbar ist, ggf. mit dem Katalog der letzten Sicherung(en) vergleichen [incr. / diff.] und die benötigenten Resourcen berechnen um letztlich zu sichern. Andere wiederum, laufen nur linear oder parallelisiert durchs FS und nehmen was geht, ggf. gelocktes wird u.U. später noch einmal versucht. Wie Du siehst, gibt es eine Menge Möglichkeiten.
Der »find«-Prozess schluckt aufgrund der hohen Anzahl (kleiner) Dateien eine Menge Zeit.
Bist Du sicher, dass es hier "find" ist und nicht *bzip*"? Letzteres ist auch recht ressourcenhungrig. Natürlich kann aber auch Quelle oder Ziel am Flaschenhals hängen. Wenn Du auf ein linkverstehendes Dateisystem sicherst (remote oder lokal angeschlossen) versuche mal rsnapshot (sofern Du ausreichend Platz hast). Das vergleicht zuerst Listen der Quelle mit dem Ziel um zu erfahren was zu sichern wäre, dann überträgt es je nach Konfiguration nur Differenzen und von denen auch nur die geänderten Blöcke pro Datei. Eine Kompression ist da nicht (sinnvoll) möglich (weil ein *zip einer Textdatei ganz anders aussieht als das der selben Datei mit nur einem geänderten Byte). Aber dafür kannst Du am Ziel verhardlinkte Ordner nutzen und somit (ja nach Menge der zwischen den Sicherungen geänderten Daten) 3 Generationen mit 20 Versionen von Sicherungen mit dem doppelten Platzbedarf einer Vollsicherung haben (ein fiktives Beispiel!).
Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Viel zu lange! Miss doch mit 'time' in Deinem Skript mal, welcher Prozess die Zeit frisst. Miss auch mal Datentransferraten von der Quelle oder zum Ziel. Beobachte vllt. auch swap. Ich vermute hier noch ganz anderes Potential.
Mit freundlichen Grüßen / With kind regards Ronny Seffner -- OT Seeligstadt | web http://www.seffner.de Alter Viehweg 1 | mail ronny@seffner.de 01665 Triebischtal | fon/fax +49 35245 72-950/-9059 | mobiltelefon +49 174 9474439
Am Montag, 6. September 2010, 12:07:55 schrieb Björn Abheiden:
Hallo Liste,
derzeit versuche ich die Backup-Funktionen auf einem unserer Server zu optimieren. Bei einem Voll-Backup wird zunächst mittels »find« eine Dateiliste erstellt, welche anschließen über »tar --files-from <DATEILISTE>« eingelesen wird.
... Ronny hat schon das wichtigste gesagt.
Zuerst mußt Du rausbekommen, woher die "grottige" Schreibleistung kommt.
Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Toll. Das sind 4,5 GB/h oder 1.2 MB/s. Das ist eine Stelle wo ich ernsthafte Fragen habe. 10-30 MB/s Schreibleistung kann man schon erwarten.
Thema "richtige" Software: Ich verwende wie Ronny bacula ebenfalls, kann aber von der "mal eben so" Verwendung nur abraten. (s.u.) Letztlich ist bacula eine Datenbank, die im Umfeld von (auch netzwerkmäßig verteilbaren) Kopiervorgängen festhält, was, wann, wo und wie passiert. Bei Einsatz sollte man sich mit den entsprechenden Sprachregelungen schon sehr gut vertraut machen und die eigenen Absichten klar benennen können.
Beispiel zur geringen Schreibleistung: Bei Einsatz von bacula könntest Du mit so was Schwierigkeiten bekommen. Dort werden die Jobs "gestapelt". Ich hatte mal den Fall, daß ein full-backup zu langsam war, das für den nächsten Tag geplante differential-backup das (fertige) full als Bezug nicht fand und daraufhin wiederum seinerseits ein full-backup anschob etc.etc. Dort die Notbremse zu ziehen, war schwer, weil die verwendete Datenbank (sqlite) bei der Gelegenheit auch überlief. (Jemand hatte für Tests einfach ein paar -zig Millionen kleine Dateien erzeugt.)
Zitat Ronny:
Alternatv, wenns schnell gehen soll biete sich rsync an, wozu es mit rsnapshot ne ressourcensparende fast fertige Lösung gibt - vllt. ist das genau der richtige Einstieg für Dich sofern Dein Ziel irgendwie unixoid ist.
+=1 (Zusammen mit Hardlinks kann man da eine Menge anfangen.)
Ziat Ronny:
Das kann man Pauschal nicht beantworten. Mnache arbeiten mit Snapshots von den zu sichernden Volumes, sie frieren also die Partition quasi ein, sichern den "Eiswürfel" während das OS in einen "Zwischenspeicher" arbeitet. Das muss aber das OS bzw. Storage unterstützen.
Echte Snapshots von Dateisystemen sind unter Linux IMHO die Ausnahme. (XFS kann's?) Mit Änderungen während eines Backupvorgangs muß man leben können (ggf. eben auch 2>/dev/null :-) ).
Thema *.zip Das ist ein tradeoff, den ich in letzter Zeit immer mehr gegen zip entscheide. Die meisten "Platzkiller" sind schon recht gut gepackt (*.avi, *jpg, *.mp3). Für andere Dateien (Text, html etc. verstellt man sich sich mit zip die rsync- Möglichkeit.)
Bisher unerwähnt: Datenintegrität. DAS ist m.E. ein viel zu leicht genommenes Thema, sei es das die Daten auf dem origininalen Datenträger oder dem Backup-Medium korrumpiert sind/werden. (Ich hatte mal einen bacula-restore Fall, der letztlich ein HD-Problem aufzeigte.)
Bernhard
Hallo,
@Ronny und Bernhard: Vielen Dank
Das Problem ist, dass sich die ganze Situation doch etwas schwieriger gestaltet. Derzeit gibt es zig-Millionen kleine (proprietäre, binäre) Dateien, die gesichert werden müssen. Jeden Tag kommen einige Tausende hinzu. Aufgrund von Performance-Schwierigkeiten werden tägliche Backups so erstellt, dass eine MySQL-Datenbank nach neu angelegten Datensätzen befragt wird. Dort wird auch ersichtlich, welche Dateien hinzugekommen sind. Anschließend wird aus diesen Informationen eine Liste von Dateinamen generiert. Die Liste wird an tar übergeben (siehe vorherige E-Mail). Wenn nun eine Vollsicherung gemacht werden soll, braucht die Datenbank nicht befragt werden, aber alle Verzeichnisse und Unterverzeichnisse (mehrstufige Struktur) werden nach Dateien durchsucht. Auch leere Verzeichnisse müssen gesichert werden. rsnapshot läuft bei uns bereits und würde in einer Nacht nicht fertig werden, vom entfernten System die Daten zu beziehen. Daher werden die beschriebenen Sicherungsvorgänge alle auf dem entfernten System durchgeführt und nächtlich holt sich das externe Sicherungssystem die Daten, die bereits vorliegen. Das System ist eigentlich sehr schnell, darf aber durch Sicherungsvorgänge nicht ausgebremst werden. (16 GB RAM, 450 GB SAS-HDD 15krpm, Quad Core)
Mit Änderungen während eines Backupvorgangs muß man leben können (ggf. eben auch 2>/dev/null :-) ).
Leider lassen die Fehlermeldungen den gesamten Vorgang abbrechen, also ist danach die Sicherung nutzlos.
Vielleicht fällt euch da noch etwas ein.
Gruß
Björn
Am Montag, 6. September 2010, 14:57:10 schrieb Björn Abheiden:
Hallo,
@Ronny und Bernhard: Vielen Dank
Das Problem ist, dass sich die ganze Situation doch etwas schwieriger gestaltet. Derzeit gibt es zig-Millionen kleine (proprietäre, binäre) Dateien, die gesichert werden müssen. Jeden Tag kommen einige Tausende hinzu. Aufgrund von Performance-Schwierigkeiten werden tägliche Backups so erstellt, dass eine MySQL-Datenbank nach neu angelegten Datensätzen befragt wird. Dort wird auch ersichtlich, welche Dateien hinzugekommen sind. Anschließend wird aus diesen Informationen eine Liste von Dateinamen generiert. Die Liste wird an tar übergeben (siehe vorherige E-Mail).
Ich werde bei den "vielen kleinen Dateien" hellwach. (Im Zusammenhang mit der geringen Backup-Leistung)
Wenn zwischen dd if=/dev/xyz of=/dev/null cat (xyz)/dir_abc/* find (xyz)/dir_abc -type f -print0 | xargs -0 rm -f
krasse Unterschiede bestehen (z.B. weil das Filsystem für Zugriff auf Refcounts zuviel Zeit braucht) dann muß man halt ein anderes FS wählen. Unter Linux gibt es ja genug Auswahl. (Das oben nur zur Verdeutlichung der Idee der Trennung Zugriff auf Dateiinhalt von OS/FS-Problemen.)
Lacher: Meine (30?)-zig Millionen Files (s. vorige Mail) zu löschen hat auf einem dicken RAID mit XFS an SCSI sage und schreibe 16 Stunden gedauert. (richtig geraten "nur" rm -rf dir_abc/)
Andere Richtung: Auch RAID ist bei regelmäßigen Backups nicht unbedingt ein muß.
Wenn nun eine Vollsicherung gemacht werden soll, braucht die Datenbank nicht befragt werden, aber alle Verzeichnisse und Unterverzeichnisse (mehrstufige Struktur) werden nach Dateien durchsucht. Auch leere Verzeichnisse müssen gesichert werden. rsnapshot läuft bei uns bereits und würde in einer Nacht nicht fertig werden, vom entfernten System die Daten zu beziehen. Daher werden die beschriebenen Sicherungsvorgänge alle auf dem entfernten System durchgeführt und nächtlich holt sich das externe Sicherungssystem die Daten, die bereits vorliegen. Das System ist eigentlich sehr schnell, darf aber durch Sicherungsvorgänge nicht ausgebremst werden. (16 GB RAM, 450 GB SAS-HDD 15krpm, Quad Core)
Mit Änderungen während eines Backupvorgangs muß man leben können (ggf. eben auch 2>/dev/null :-) ).
Leider lassen die Fehlermeldungen den gesamten Vorgang abbrechen, also ist danach die Sicherung nutzlos.
Klar, aber seltsam.
rsync meldet zwar, mit 2>/dev/null arbeitet es aber bei mir weiter.
Der Standpunkt "ignoriere Fehler" mag zwar nicht ganz politisch korrekt sein, aber praktisch durchaus brauchbar. (NB: bacula ist auch äußerst fehlertolerant. Es läuft also so lange wie irgend möglich annehmbar weiter. das auch mit manchmal verblüffenden Lösungen.)
Vielleicht fällt euch da noch etwas ein.
Dazu müßte ich das System mal in die Finger bekommen.
Gruß
Björn
Bernhard
Hallo Björn,
Derzeit gibt es zig-Millionen kleine (proprietäre, binäre) Dateien, die
...
rsnapshot läuft bei uns bereits und würde in einer Nacht nicht fertig
Hier Achtung! Hast Du mal das rsnapshot mit -vvv laufen lassen. Ich habe wiederholt nachweislich Probleme mit bestimmten (z.B. den in debian verwendeten) Versionen von rsync gesehen, die mit großen Mengen (und die waren deutlich kleiner als Deine) Probleme hatten und nichts mehr machten. Ich habe mir unter debian angewöhnt lieber das rsync aus den stabilen Originalquellen zu bauen - auf beiden Seiten!
Bei so einer Menge kleinster Dateien ist vllt. auch das Dateisystem der Flaschenhals?
Leider lassen die Fehlermeldungen den gesamten Vorgang abbrechen, also ist danach die Sicherung nutzlos.
Das habe ich mit tar so noch nicht gesehen, aber ich will Dir glauben.
Vielleicht fällt euch da noch etwas ein.
Finde die "Spaß"bremse!
Was ganz anderes, was man vllt. nicht Backup nennen sollte. Ich habe an einem System für gerade und ungerade KW je eine e-SATA/FW Platte, das lokale storage ist dafür als softraid mit metadaten konfiguriert, entsprechende udev regeln sorgen für das einhängen, ein admin für das aushängen. So hat man immer mal eine 1:1 Kopie der lokalen Platte mit nativer Geschwindigkeit und im Idealfall nur die geänderten Daten gesynct - ganz ohne sich über Dateisysteme und Dateimengen Gedanken zu machen. Sowas ist auch verdammt schnell wieder belebt. Und zur Sicherheit: mein mdX ist dazu noch per truecrypt verschlüsselt was eine (zusätzliche" Kennworteingabe beim booten der Kiste erfordert. Ich denke es gibt Fälle, in denen kann man auch mit sowas leben - bei mir ist es das Backup vom Backup, für den Fall, dass das Büro mal abfackelt oder ausgeräumt wird.
Mit freundlichen Grüßen / With kind regards Ronny Seffner -- OT Seeligstadt | web http://www.seffner.de Alter Viehweg 1 | mail ronny@seffner.de 01665 Triebischtal | fon/fax +49 35245 72-950/-9059 | mobiltelefon +49 174 9474439
Hallo Björn,
Björn Abheiden b.abheiden@ba-webdesign.com (Mo 06 Sep 2010 12:07:55 CEST):
Hallo Liste,
derzeit versuche ich die Backup-Funktionen auf einem unserer Server zu optimieren. Bei einem Voll-Backup wird zunächst mittels »find« eine Dateiliste erstellt, welche anschließen über »tar --files-from <DATEILISTE>« eingelesen wird.
Ich würde mich hier auf die Fähigkeit von Tar verlassen (Stichwort Index-File), wenn es darum geht, zu ermitteln, was neu hinzugekommen ist.
Ohne diese Dateiliste springt mich der Prozess irgendwann mit einer Fehlermeldung an, da sich die Daten innerhalb der Ordnerstruktur ändern können (hauptsächlich kommen Dateien hinzu).
Das wird doch auch mit dieser Dateiliste passieren. Solange Leben in den Verzeichnissen ist, wird tar bemerkten, daß während des Sicherns Änderungen passieren. Ob das kritisch ist, kann tar nicht wissen, es wird aber weiterarbeiten.
Welche Möglichkeit habe ich, diese Fehlermeldung zu unterdrücken? Gibt
tar … 2>/dev/null
es ein anderes Archiviersystem, welches ihr mir stattdessen empfehlen würdet? Wie machen es "richtige" Backup-Programme, wenn sie von einem Live-System Daten sichern sollen?
Die sollten die selben Probleme haben. Was das mehrfach erwähnte Bacula hier macht, weiß ich nicht, vielleicht einfach die Meldungen unterdrücken. Amanda zeigt diese Meldungen, wenn es die Sicherung mit tar erstellt. Wenn es dump benutzt, weiß ich gerade nicht, was da passiert, ob dump etwas äußert.
"Warum der Aufwand?" könnte nun eine Frage lauten. Der »find«-Prozess schluckt aufgrund der hohen Anzahl (kleiner) Dateien eine Menge Zeit. Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Berechnet oder erreicht.
derzeitiger Ablauf: »find« > »tar« > »pbzip2«
Ich würde vielleicht das Dateisystem in ein LVM legen und dann einen Snapshot machen, den ich in aller Ruhe sichern kann. Da ändern sich dann auch keine Files mehr. Ob Du für den Snapshot irgendwelche Dienste anhalten willst, hängt von Deinen Anwendungen ab.
Ich mache gerne sowas:
snapshot
fsck - wenn fehler, dann snapshot wegschmeissen und noch mal snapshot
dump / tar / whatever
snapshot wegschmeissen
Hallo Heiko,
"Warum der Aufwand?" könnte nun eine Frage lauten. Der »find«-Prozess schluckt aufgrund der hohen Anzahl (kleiner) Dateien eine Menge Zeit. Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Berechnet oder erreicht.
Bei der Sicherung von ca. 25% der Daten werden entsprechend die prozentuale Anzahl Stunden gebraucht. Wir gehen also davon aus, dass die Anzahl Stunden passt, da die Dateien immer nach dem gleichen Muster aufgebaut sind.
An dem Dateisystem kann ich leider nichts ändern, da das System keine Wartungsfenster in den nächsten Wochen vorsieht, aber das Backup natürlich dennoch schnellstmöglich laufen soll. Wir haben zwei Jahre lang immer nur inkrementelle Backups gemacht, bis wir vor kurzem eine große Aufräumaktion hatten. Hierbei ist uns eingefallen, dass die inkrementellen Backups auch noch die alten Daten beinhalten. Nun darf alles umgestellt werden. Alles live ... so ist das Leben. ;-)
Gruß
Björn
On 06.09.2010 16:49, Heiko Schlittermann wrote:
Hallo Björn,
Björn Abheiden b.abheiden@ba-webdesign.com (Mo 06 Sep 2010 12:07:55 CEST):
Hallo Liste,
derzeit versuche ich die Backup-Funktionen auf einem unserer Server zu optimieren. Bei einem Voll-Backup wird zunächst mittels »find« eine Dateiliste erstellt, welche anschließen über »tar --files-from <DATEILISTE>« eingelesen wird.
Ich würde mich hier auf die Fähigkeit von Tar verlassen (Stichwort Index-File), wenn es darum geht, zu ermitteln, was neu hinzugekommen ist.
Ohne diese Dateiliste springt mich der Prozess irgendwann mit einer Fehlermeldung an, da sich die Daten innerhalb der Ordnerstruktur ändern können (hauptsächlich kommen Dateien hinzu).
Das wird doch auch mit dieser Dateiliste passieren. Solange Leben in den Verzeichnissen ist, wird tar bemerkten, daß während des Sicherns Änderungen passieren. Ob das kritisch ist, kann tar nicht wissen, es wird aber weiterarbeiten.
Welche Möglichkeit habe ich, diese Fehlermeldung zu unterdrücken? Gibt
tar … 2>/dev/nulles ein anderes Archiviersystem, welches ihr mir stattdessen empfehlen würdet? Wie machen es "richtige" Backup-Programme, wenn sie von einem Live-System Daten sichern sollen?
Die sollten die selben Probleme haben. Was das mehrfach erwähnte Bacula hier macht, weiß ich nicht, vielleicht einfach die Meldungen unterdrücken. Amanda zeigt diese Meldungen, wenn es die Sicherung mit tar erstellt. Wenn es dump benutzt, weiß ich gerade nicht, was da passiert, ob dump etwas äußert.
"Warum der Aufwand?" könnte nun eine Frage lauten. Der »find«-Prozess schluckt aufgrund der hohen Anzahl (kleiner) Dateien eine Menge Zeit. Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Berechnet oder erreicht.
derzeitiger Ablauf: »find« > »tar« > »pbzip2«
Ich würde vielleicht das Dateisystem in ein LVM legen und dann einen Snapshot machen, den ich in aller Ruhe sichern kann. Da ändern sich dann auch keine Files mehr. Ob Du für den Snapshot irgendwelche Dienste anhalten willst, hängt von Deinen Anwendungen ab.
Ich mache gerne sowas:
snapshot fsck - wenn fehler, dann snapshot wegschmeissen und noch mal snapshot dump / tar / whatever snapshot wegschmeissen
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Hallo
Hallo Liste,
derzeit versuche ich die Backup-Funktionen auf einem unserer Server zu optimieren. Bei einem Voll-Backup wird zunächst mittels »find« eine Dateiliste erstellt, welche anschließen über »tar --files-from <DATEILISTE>« eingelesen wird.
Ich würde mich hier auf die Fähigkeit von Tar verlassen (Stichwort Index-File), wenn es darum geht, zu ermitteln, was neu hinzugekommen ist.
wenn gnu tar zu langsam könnte man star mal testen
vielleicht hat tar auch Probleme mit links
Ohne diese Dateiliste springt mich der Prozess irgendwann mit einer Fehlermeldung an, da sich die Daten innerhalb der Ordnerstruktur ändern können (hauptsächlich kommen Dateien hinzu).
Das wird doch auch mit dieser Dateiliste passieren. Solange Leben in den Verzeichnissen ist, wird tar bemerkten, daß während des Sicherns Änderungen passieren. Ob das kritisch ist, kann tar nicht wissen, es wird aber weiterarbeiten.
Welche Möglichkeit habe ich, diese Fehlermeldung zu unterdrücken? Gibt
tar … 2>/dev/nulles ein anderes Archiviersystem, welches ihr mir stattdessen empfehlen würdet? Wie machen es "richtige" Backup-Programme, wenn sie von einem Live-System Daten sichern sollen?
Die sollten die selben Probleme haben. Was das mehrfach erwähnte Bacula hier macht, weiß ich nicht, vielleicht einfach die Meldungen unterdrücken. Amanda zeigt diese Meldungen, wenn es die Sicherung mit tar erstellt. Wenn es dump benutzt, weiß ich gerade nicht, was da passiert, ob dump etwas äußert.
"Warum der Aufwand?" könnte nun eine Frage lauten. Der »find«-Prozess schluckt aufgrund der hohen Anzahl (kleiner) Dateien eine Menge Zeit.
man könnte versuchen in Echtzeit mit dnotify eine Liste erstellen oder gleich den Archiv hinzufügen
Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Berechnet oder erreicht.
derzeitiger Ablauf: »find« > »tar« > »pbzip2«
Ich würde vielleicht das Dateisystem in ein LVM legen und dann einen Snapshot machen, den ich in aller Ruhe sichern kann. Da ändern sich dann auch keine Files mehr. Ob Du für den Snapshot irgendwelche Dienste anhalten willst, hängt von Deinen Anwendungen ab.
Ich mache gerne sowas:
snapshot fsck - wenn fehler, dann snapshot wegschmeissen und noch mal snapshot dump / tar / whatever snapshot wegschmeissen
würde ich auch probieren
oder ein Filesystem nutzen das snapshort/oder history kann (zfs(performance schlecht Userspace) brtfs (beta) logfs() ext3cow())
man könnte auch überlegen die Daten per drbd auf einen anderen Rechner zubringen
drbd deaktivieren backup drbd aktivieren und sync (habe ich aber keine Erfahrung ob das geht)
Andreas
-- Heiko
Hallo Grimnin!
wenn gnu tar zu langsam könnte man star mal testen
vielleicht hat tar auch Probleme mit links
Vielen Dank für den Hinweis! Ich werde diesem mal nachgehen.
Links gibt es in der gesamten Verzeichnisstruktur keine.
man könnte versuchen in Echtzeit mit dnotify eine Liste erstellen oder gleich den Archiv hinzufügen
dnotify halte ich für eine interessante Idee. Die "online"-Archivierung hatten wir kürzlich aufgrund von Fehlern (sehr aufwändig) abschalten müssen.
LZOlayer-FS flog uns regelmäßig um die Ohren, falls das jemandem etwas sagt. Seit dieser negativen Erfahrung wollten wir auf eine solche Schicht verzichten.
Grüße
Björn
lug-dd@mailman.schlittermann.de
-
Bernhard Schiffner -
Björn Abheiden -
Grimnin Fridyson -
Heiko Schlittermann -
Ronny Seffner