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.
