Kennt jemand ein tool ähnlich rsync, das log-dateien syncronisieren kann. Angenommen eine log-Datei ist 10MB groß. Nach dem ersten syncronisieren wird eine identische Kopie vorliegen. Wächst die Datei dann auf 11MB soll nur das eine neu dazugekommene MB übertragen werden. An den bestehenden 10MB soll keinerlei Veränderung vorgenommen werden, egal was da jetzt im Quellfile steht. Das ist der Unterschied zu rsync. Hintergrund sind Messdaten die in einer Datei fortlaufend geschrieben werden. Es soll aber zuverlässig verhindert werden, dass durch das syncronisieren bestehende Sicherungen verändert werden. Wenn die Quelldatei durch einen verrückt spielenden Prozess überschrieben, gekürzt oder gelöscht wird, soll das die bereits gesicherten Daten nicht verändern. Ich bin nur an Tools interessiert die das unter Linux direkt unterstützen. Vielleicht habe ich auch nur eine Option bei rsync übersehen.
Das macht doch wenig sinn. Wenn die Datei bei 0 anfängt und dann irgendwann bei 11Mbyte ist, dann werden die Daten an eine Datei dran gehangen wo sie überhaupt nicht dazu passen. Und wenn es text-Dateien sind, dann ist noch nicht mal sichergestellt das die Zeilen alle gleich lang sind.
gabi schrieb: > Es soll aber zuverlässig verhindert werden, dass durch das > syncronisieren bestehende Sicherungen verändert werden Ich würde dafür jetz SVN nutzen, auch wenn das nicht der primär angedachte Zweck ist hätest du dort alles was das Herz begehrt: - diverse Toolunterstützung - Historie - Diffs
Wenn es wirklich log-Daten sind, steht doch wohl am Anfang ein Zeitpunkt. Damit kann man sich doch ein kleines Tools schreiben, was alle neueren Daten an die alte Datei anhängt. Dabei spielt dann die Dateigröße keine Rolle mehr.
Um das nochmal zu konkretisieren. Es geht um Messdaten. Die Datei besteht aus Datensätzen mit fixen längen und binären Messdaten. Im ersten Record der Datei steht die Zeit an der diese Datei beginnt. Damit kann dann über die Zeit die Position in der Datei berechnet werden wo die Daten eingetragen werden. Für 16 16bit Werte werden somit 256byte benötigt, zusätzlich noch crc und der Zeitstempel zum Quervergleich. Mit anderen Worten ca. 22MB / Tag oder 8GB im Jahr wenn pro sec ein Record geschrieben wird. Der Syncronisationsvorgang soll alle paar Minuten laufen. svn scheidet damit sicher aus. Es werden auch keine Zwischenstände der Sicherung benötigt. Das einzige was sichergestellt sein muss ist, dass Daten die schon gesichert sind nicht nachträglich verändert werden dürfen auch wenn ein wild gewordener Prozess die Quelle vertümmelt.
Peter II schrieb: > Wenn es wirklich log-Daten sind, steht doch wohl am Anfang ein > Zeitpunkt. Damit kann man sich doch ein kleines Tools schreiben, was > alle neueren Daten an die alte Datei anhängt. Dabei spielt dann die > Dateigröße keine Rolle mehr. Ja das trifft es genau. Nur sollte das ganze remote über ssh laufen wie bei rsync. Das Tool kann ich mir auch selber schreiben, ich wollte nur verhindern, dass ich mir die Arbeit mache und am Ende feststellen muss, dass ich nur zu blöd zum suchen war.
gabi schrieb: > Vielleicht habe ich auch nur eine Option bei rsync > übersehen. eher das. Rsync würde in dem Beispiel-Fall für die ersten 10 MB nur Block-Checksummen übertragen, und das 11te MB komplett.
Planlos schrieb: > eher das. oder auch nicht, die Frage richtig gelesen? > Rsync würde in dem Beispiel-Fall für die ersten 10 MB nur > Block-Checksummen übertragen, und das 11te MB komplett. aber wenn sich die ersten 10Mbyte ändert würde er sie auch übertragen, das will er aber nicht. Das ganze ist so speziell, dafür wird es nichts fertiges geben.
Peter II schrieb: > oder auch nicht, die Frage richtig gelesen? Das stimmt, habe ich nur sinnentstellend überflogen. Peter II schrieb: > Das ganze ist so speziell, dafür wird es nichts > fertiges geben. Wenn die Datei deutlich größer als 10MB ist, könnte man etwas in der Art mit btrfs, snapshots, btrfs send&receive basteln. triffts aber auch nicht ganz. Man hat dann zwar am Zielsystem die Möglichkeit die vom Quell-Rechner zerschossenen Daten wiederherzustellen, und es werden mehr oder weniger nur die Änderungen übertragen, aber out-of-the box ist die Ziel-Datei nicht immer korrekt.
Mittels cat ginge das, nur ob das rein inkrementell ist ... Dann noch sed oder via pipes und grep o.ä. ... Wenn es sehr speziell ist also z.B. die Binary nicht wie Text behandelt werden kann kommst Du um ein eigenes kleines Progrämmchen nicht herum. Das dürfte genausoviel Arbeit machen wie sämtliche Foren und Suchen abzuklappern und Du hast nachher das was Du brauchst und kannst es selber passend erweitern.
katze schrieb: > Mittels cat ginge das, nur ob das rein inkrementell ist ... > Dann noch sed oder via pipes und grep o.ä. ... > Wenn es sehr speziell ist also z.B. die Binary nicht wie Text behandelt > werden kann kommst Du um ein eigenes kleines Progrämmchen nicht herum. > Das dürfte genausoviel Arbeit machen wie sämtliche Foren und Suchen > abzuklappern und Du hast nachher das was Du brauchst und kannst es > selber passend erweitern. Oha, Kommando zurück erst lesen, dann denken, dann kapieren ... Da wirst Du um eine echte inkrementelle Backupsoftware oder eine selber geschriebene nicht herumkommen. Mach's lieber selber und lege noch ein paar Sicherheitskopien an. Konnte man nicht mit TAR auch an bestehende Bänderdateien was anhängen, ist zu lange her ... Allerdings ein lokales Script das mit cat die empfangenen Daten anhängt sollte trotzdem gehen, kommt nur darauf an wie schnell es sein muß und ob man das in eine Pipe hängen kann ?
Du kannst dir mit dd nur den fehlenden Teil dazu kopieren. Um ein Fehlerhandling fuer den Fall, dass sich der untere Teil veraendert oder er gar verschwindet, wirst du aber nicht herum kommen. Insofern waere eine Loesung mit rsync und Snapshots (Kannst du auch mit copy anlegen) im Ziel wohl sinnvoller.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.