Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #232421 > unrolled thread

[OT] Große geöfnete Datei synchronisieren

Back to article view | Back to ger.ct

Contents

  [OT] Große geöfnete Datei synchronisieren Jörg Barres <news@traicon.net> - 2015-12-07 11:18 +0100
    Re: [OT] Große geöfnete Datei synchronisieren Jörg Barres <news@traicon.net> - 2015-12-07 13:17 +0100
    Re: [OT] Große geöfnete Datei synchronisieren Jörg Tewes <jogi1964@gmx.net> - 2015-12-07 17:03 +0100
      Re: [OT] Große geöfnete Datei synchronisieren Karsten Düsterloh <trash@tprac.de> - 2015-12-07 18:44 +0100
        Re: [OT] Große geöfnete Datei synchronisieren Jörg Tewes <jogi1964@gmx.net> - 2015-12-07 22:35 +0100
          Re: [OT] Große geöfnete Datei synchronisieren Hanno Foest <hurga-news2@tigress.com> - 2015-12-07 22:48 +0100
            Re: [OT] Große geöfnete Datei synchronisieren Hendrik van der Heijden <hvdh@gmx.de> - 2015-12-08 08:23 +0100
              Re: [OT] Große geöfnete Datei synchronisieren Hanno Foest <hurga-news2@tigress.com> - 2015-12-08 15:32 +0100
            Re: [OT] Große geöfnete Datei synchronisieren Jörg Tewes <jogi1964@gmx.net> - 2015-12-08 03:34 +0100
              Re: [OT] Große geöfnete Datei synchronisieren Karsten Düsterloh <trash@tprac.de> - 2015-12-09 20:57 +0100
                Re: [OT] Große geöfnete Datei synchronisieren Jörg Tewes <jogi1964@gmx.net> - 2015-12-09 22:49 +0100
                  Re: [OT] Große geöfnete Datei synchronisieren Karsten Düsterloh <trash@tprac.de> - 2015-12-09 23:18 +0100
                    Re: [OT] Große geöfnete Datei synchronisieren Hanno Foest <hurga-news2@tigress.com> - 2015-12-09 23:56 +0100
                    Re: [OT] Große geöfnete Datei synchronisieren Jörg Tewes <jogi1964@gmx.net> - 2015-12-10 00:15 +0100
                      Re: [OT] Große geöfnete Datei synchronisieren Wolfgang Kynast <wky@gmx.de> - 2015-12-10 00:40 +0100
                        Re: [OT] Große geöfnete Datei synchronisieren Jörg Tewes <jogi1964@gmx.net> - 2015-12-10 01:41 +0100
                          Re: [OT] Große geöfnete Datei synchronisieren Wolfgang Kynast <wky@gmx.de> - 2015-12-10 12:38 +0100
                  Re: [OT] Große geöfnete Datei synchronisieren Hanno Foest <hurga-news2@tigress.com> - 2015-12-09 23:46 +0100
                    Re: [OT] Große geöfnete Datei synchronisieren Michael Bode <m.g.bode@web.de> - 2015-12-10 07:16 +0100
    Re: [OT] Große geöfnete Datei synchronisieren Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-12-07 17:37 +0100
    Re: [OT] Große geöfnete Datei synchronisieren Hendrik van der Heijden <hvdh@gmx.de> - 2015-12-07 18:11 +0100
    Re: [OT] Große geöfnete Datei synchronisieren Stefan Reuther <stefan.news@arcor.de> - 2015-12-07 18:51 +0100
      Re: [OT] Große geöfnete Datei synchronisieren Stephan Elinghaus <091215.6.seli@spamgourmet.com> - 2015-12-09 15:21 +0100
    Re: [OT] Große geöfnete Datei synchronisieren Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-12-07 20:25 +0100
      Re: [OT] Grosse geoeffnete Datei synchronisieren Frank Klingenhoefer <frank.private@t-online.de> - 2015-12-08 00:26 +0100

Page 1 of 2  [1] 2  Next page →

#232421 — [OT] Große geöfnete Datei synchronisieren

Hallo Leute,

schönen Nikolaus und so weiter :-)

Ich habe mal wieder eine Frage an die vorhandene Experience:

Ich würde gerne einen Ordner, der geöffnete Dateien enthält, auf einer 
Freigabe im Netz synchron halten, alle 10-15 Minuten reicht, muss alo 
keine real-time-sync sein.

Quellordner ist eine VM unter ESXi, ein Zugriff per SSH ist möglich.
Die dort laufende VM soll auf einem Netzlaufwerk gesichert werden, aber 
ohne sie vorher runterzufahren.
Die Dateien sind also teilweise recht groß (etliche GB), ein 
vollständiges Kopieren ist also nicht das Ziel, sondern nur ein Kopieren 
der geänderten Bereiche.

Tante Google spuckt nichts brauchbares aus, aber ich bin mir recht 
sicher, daß so etwas möglich sein sollte.

Die Software kann unter Windows oder Linux laufen, darf auch gerne ein 
Script sein.

Notfalls darf es auch eine kommerzielle Software sein, solange der Preis 
akzeptabel ist.

Wer hat hier einen Tip für mich?

Vielen Dank an alle,

Jörg

[toc] | [next] | [standalone]

#232474

Ups,

sehe gerade, im Betreff ist ein f runtergefallen, hier isses: f

Und das OT steht für OnTopic :-)

Jörg

[toc] | [prev] | [next] | [standalone]

#232486

Jörg Barres schrieb:
> Hallo Leute,
> 
> schönen Nikolaus und so weiter :-)
> 
> Ich habe mal wieder eine Frage an die vorhandene Experience:
> 
> Ich würde gerne einen Ordner, der geöffnete Dateien enthält, auf einer 
> Freigabe im Netz synchron halten, alle 10-15 Minuten reicht, muss alo 
> keine real-time-sync sein.
> 
> Quellordner ist eine VM unter ESXi, ein Zugriff per SSH ist möglich.
> Die dort laufende VM soll auf einem Netzlaufwerk gesichert werden, aber 
> ohne sie vorher runterzufahren.
> Die Dateien sind also teilweise recht groß (etliche GB), ein 
> vollständiges Kopieren ist also nicht das Ziel, sondern nur ein Kopieren 
> der geänderten Bereiche.
> 
> Tante Google spuckt nichts brauchbares aus, aber ich bin mir recht 
> sicher, daß so etwas möglich sein sollte.

Von einer großen Datei sollen nur die geänderten Bereiche mit einer
anderen/dergleichen großen Datei an einem anderen Ort synchron
gehalten werden? Ich bezweifel das es dafür Software gibt, die nicht
mit der Software "verwandt" ist die die große Datei erstellt. Wenn ich
mir z.B. die MBOX Dateien von Thunderbird angucke, ist ein
synchronisieren von zwei Installationen nur möglich indem man die
großen MBOX Dateien hin und herkopiert.


        Bye Jörg

-- 
"Optimismus ist, bei Gewitter auf dem höchsten Berg in einer
Kupferrüstung zu stehen und »Scheiß Götter!« zu rufen."

[toc] | [prev] | [next] | [standalone]

#232515

Jörg Tewes aber hob an zu reden und schrieb:
> Wenn ich mir z.B. die MBOX Dateien von Thunderbird angucke, ist ein 
> synchronisieren von zwei Installationen nur möglich indem man die 
> großen MBOX Dateien hin und herkopiert.

Das liegt aber weder an mbox noch an der Größe, sondern an deinen
Aufräumeinstellungen. TB fügt ohne die immer nur hinten an die mbox an.


Karsten
-- 
       Freiheit stirbt        |       Fsayannes SF&F-Bibliothek:
            Mit Sicherheit    |       http://fsayanne.tprac.de/

[toc] | [prev] | [next] | [standalone]

#232540

Karsten Düsterloh schrieb:
> Jörg Tewes aber hob an zu reden und schrieb:
>> Wenn ich mir z.B. die MBOX Dateien von Thunderbird angucke, ist ein 
>> synchronisieren von zwei Installationen nur möglich indem man die 
>> großen MBOX Dateien hin und herkopiert.
> 
> Das liegt aber weder an mbox noch an der Größe, sondern an deinen
> Aufräumeinstellungen. TB fügt ohne die immer nur hinten an die mbox an.

Ich habe keine Aufräumeinstellungen vorgenommen. Ist alles auf Standard.

Wie bekommst du es denn hin, daß die tagsüber auf dem Laptop
vorgenommenen Änderungen an der Messagebase, also allen Newsservern,
und allen Mailpostfächern abend auf dem Desktoprechner synchronisiert
werden, ohne das jedesmal die gesamte Datei kopiert wird?

Und das natürlich nicht nur für Thunderbird sondern auch für andere
Formate.

Also ich wüßte keine Möglichkeit z.B. bei einer 4 GByte Datenbank
Datei von außen nur die 100 KByte die geändert wurden, mit einer
Datenbank Datei an einem anderen Speicherort zu synchronisieren ohne
daß das Programm welches die Datenbankdatei erstellt hat darin
involviert wäre, und das ganz hinterher nicht defekt wäre. Mit sowas
wie robocopy funktionierts schon mal nicht.


        Bye Jörg

-- 
"It is good to have friends, is it not, Mr. Garibaldi? Even if,
maybe, only for a little while?"
"Even if only for a little while."
(Londo and Garibaldi, "Acts of Sacrifice")

[toc] | [prev] | [next] | [standalone]

#232544

Am 07.12.2015 um 22:35 schrieb Jörg Tewes:

> Also ich wüßte keine Möglichkeit z.B. bei einer 4 GByte Datenbank
> Datei von außen nur die 100 KByte die geändert wurden, mit einer
> Datenbank Datei an einem anderen Speicherort zu synchronisieren ohne
> daß das Programm welches die Datenbankdatei erstellt hat darin
> involviert wäre, und das ganz hinterher nicht defekt wäre.

Ich schon. https://de.wikipedia.org/wiki/Rsync

Gibt es ja erst seit knapp 20 Jahren.

Voraussetzung ist natürlich, daß große zusamenhängende Teile der Datei 
unverändert sind.

Hanno

[toc] | [prev] | [next] | [standalone]

#232567

Am 07.12.2015 um 22:48 schrieb Hanno Foest:
> Am 07.12.2015 um 22:35 schrieb Jörg Tewes:
> 
>> Also ich wüßte keine Möglichkeit z.B. bei einer 4 GByte Datenbank
>> Datei von außen nur die 100 KByte die geändert wurden, mit einer
>> Datenbank Datei an einem anderen Speicherort zu synchronisieren ohne
>> daß das Programm welches die Datenbankdatei erstellt hat darin
>> involviert wäre, und das ganz hinterher nicht defekt wäre.
> 
> Ich schon. https://de.wikipedia.org/wiki/Rsync

Ja, sowas kann man zum Syncen nehmen. Es bleibt das Problem, dass
die Datei, so wie sie von rsync etc. gelesen wird, sehr wahrscheinlich
inkonsistent und damit unbrauchbar ist, wenn man nicht vorher das
primär zugreifende Programm beendet und hinterher wieder startet.
Und genau das versucht der OP zu vermeiden.


Hendrik vdH

[toc] | [prev] | [next] | [standalone]

#232628

Am 08.12.2015 um 08:23 schrieb Hendrik van der Heijden:

>> Ich schon. https://de.wikipedia.org/wiki/Rsync
>
> Ja, sowas kann man zum Syncen nehmen. Es bleibt das Problem, dass
> die Datei, so wie sie von rsync etc. gelesen wird, sehr wahrscheinlich
> inkonsistent und damit unbrauchbar ist, wenn man nicht vorher das
> primär zugreifende Programm beendet und hinterher wieder startet.

In dem Absatz, auf den ich geantwortet habe, war keine Rede davon, daß 
man das zugreifende Programm nicht beenden darf. (Steht zwar im Topic, 
aber das ist ja bekanntlich eher bedeutungslos.)

Ob es auch bei geöffneter Datei geht, kommt auf die Umstände an 
(Systemaktivität, Last, Umfang des Cachings, Geschwindigkeit der 
Synchronisation). Ich hab schon Datenbanken und Dateisysteme (!) während 
der Fahrt gesynct und sie funktionierten hinterher. Hat zwar etwas 
gerumpelt beim Einschalten, als die Fehlerbereinigungsmechanismen 
Inkonsistenzen ausbügelten, war aber bis auf die letzten geschriebenen 
Daten OK. Ein deutlich zeitnäherer Datenstand als bei einem Backup pro 
Woche jedenfalls.

Ja, ich weiß, daß das eigentlich Pfusch ist. Aber manchmal muß man halt 
stricken, wenn Not am Mann ist.

Hanno

[toc] | [prev] | [next] | [standalone]

#232710

Hanno Foest schrub

> Am 07.12.2015 um 22:35 schrieb Jörg Tewes:

>> Also ich wüßte keine Möglichkeit z.B. bei einer 4 GByte Datenbank
>> Datei von außen nur die 100 KByte die geändert wurden, mit einer
>> Datenbank Datei an einem anderen Speicherort zu synchronisieren ohne
>> daß das Programm welches die Datenbankdatei erstellt hat darin
>> involviert wäre, und das ganz hinterher nicht defekt wäre.

> Ich schon. https://de.wikipedia.org/wiki/Rsync
>
> Gibt es ja erst seit knapp 20 Jahren.

Wenn ich also eine MBOX Datei an einen anderen Ort kopiere, dann auf
diese beiden MBOX Dateien mit Thunderbird zugreife und diverse MAil auf
der einen Seite und diverse Postings auf der anderen Seite empfange,
dann habe ich in beiden Thunderbirds denselben Mail und Postingbestannd,
und nicht eine defekte Datenbasis?

Bezweifel ich.

> Voraussetzung ist natürlich, daß große zusamenhängende Teile der
> Datei unverändert sind.

Was heißt große zusammenhängede Teile? Wieviel müßte von einer 4 GByte
Datei unverändert sein? Und wäre die Datendatei vom zugehörigen Programm
noch nutzbar, oder unbrauchbar?


        Bye Jörg

-- 
Sechs Jahre habe ich nicht geraucht, nicht gesoffen und nix mit Frauen
gehabt. Und dann wurde ich eingeschult. :-))

[toc] | [prev] | [next] | [standalone]

#232834

Jörg Tewes aber hob an zu reden und schrieb:
>> https://de.wikipedia.org/wiki/Rsync
>> 
>> Gibt es ja erst seit knapp 20 Jahren.
> 
> Wenn ich also eine MBOX Datei an einen anderen Ort kopiere, dann auf 
> diese beiden MBOX Dateien mit Thunderbird zugreife und diverse MAil
> auf der einen Seite und diverse Postings auf der anderen Seite
> empfange, dann habe ich in beiden Thunderbirds denselben Mail und
> Postingbestannd, und nicht eine defekte Datenbasis?
> 
> Bezweifel ich.

Das Strohmann-Problem hast du dir aber jetzt auch ausgedacht,
denn um parallele schreibende Nutzung ging es gar nicht.


Karsten
-- 
       Freiheit stirbt        |       Fsayannes SF&F-Bibliothek:
            Mit Sicherheit    |       http://fsayanne.tprac.de/

[toc] | [prev] | [next] | [standalone]

#232852

Karsten Düsterloh schrieb:
> Jörg Tewes aber hob an zu reden und schrieb:
>>> https://de.wikipedia.org/wiki/Rsync
>>> 
>>> Gibt es ja erst seit knapp 20 Jahren.
>> 
>> Wenn ich also eine MBOX Datei an einen anderen Ort kopiere, dann auf 
>> diese beiden MBOX Dateien mit Thunderbird zugreife und diverse MAil
>> auf der einen Seite und diverse Postings auf der anderen Seite
>> empfange, dann habe ich in beiden Thunderbirds denselben Mail und
>> Postingbestannd, und nicht eine defekte Datenbasis?
>> 
>> Bezweifel ich.
> 
> Das Strohmann-Problem hast du dir aber jetzt auch ausgedacht,
> denn um parallele schreibende Nutzung ging es gar nicht.

Nein, aber die Dateien sollen ja wohl nicht nur kopiert werden weil es
geht, sondern um sie im Notfall auch nutzen zu können. Also muß RSync
z.B. die Mails/Postings die ich schreibe, in die große Datei auf dem
Netzlaufwerk so einfügen das man die Datei einfach zurückkopieren kann
und dann den gesicherten Zustand wieder hergestellt hat. Das wage ich
halt bei solchen Dateien wie MBOX-Dateien oder Datenbanken zu bezweifeln.


        Bye Jörg

-- 
Die deutsche Rechtschreibung ist Freeware, sprich, du kannst sie
kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du
darfst sie nicht verändern oder in veränderter Form
veröffentlichen! ;-)

[toc] | [prev] | [next] | [standalone]

#232855

Jörg Tewes aber hob an zu reden und schrieb:
>> Das Strohmann-Problem hast du dir aber jetzt auch ausgedacht, denn 
>> um parallele schreibende Nutzung ging es gar nicht.
> 
> Nein, aber die Dateien sollen ja wohl nicht nur kopiert werden weil 
> es geht, sondern um sie im Notfall auch nutzen zu können.

Bzw. um im Notfall möglichst viel bereits gerettet zu haben.

> Also muß RSync z.B. die Mails/Postings die ich schreibe, in die große
> Datei auf dem Netzlaufwerk so einfügen das man die Datei einfach 
> zurückkopieren kann

Nicht einfügen. Anhängen. Wo ist das Problem?

Schwieriger wird es, wenn sich Daten *in* der mbox ändern.
Das könnte dann interessant werden (ich weiß nicht, ob rsync das kann,
das müssen andere beantworten).
Viele der Metadaten stehen bei TB ja nicht in der mbox, sondern in der
zugehörigen Indexdatei.

> und dann den gesicherten Zustand wieder hergestellt hat. Das wage ich
> halt bei solchen Dateien wie MBOX-Dateien oder Datenbanken zu
> bezweifeln.

Naja, gerade Datenbanken bieten so Sachen wie "Hot Standby"
<https://wiki.postgresql.org/wiki/Hot_Standby>/"Streaming Replication"
<https://wiki.postgresql.org/wiki/Streaming_Replication>, die genau das
ermöglichen sollen.


Karsten
-- 
       Freiheit stirbt        |       Fsayannes SF&F-Bibliothek:
            Mit Sicherheit    |       http://fsayanne.tprac.de/

[toc] | [prev] | [next] | [standalone]

#232865

Am 09.12.2015 um 23:18 schrieb Karsten Düsterloh:

> Nicht einfügen. Anhängen. Wo ist das Problem?
>
> Schwieriger wird es, wenn sich Daten *in* der mbox ändern.
> Das könnte dann interessant werden (ich weiß nicht, ob rsync das kann,
> das müssen andere beantworten).

rsync macht (mit den geeigneten Parametern aufgerufen) blockweise 
Checksummen über die Dateien auf beiden Seiten. Blöcke mit 
unterschiedlichen Checksummen werden übertragen. Offensichtlich hängt es 
vom Dateiformat ab, wie effektiv die Übertragung der Änderungen ist: 
Wird nur angehangen, ist also der größte Teil der Datei unverändert, ist 
sie sehr effektiv. Werden quer durch die Datei nur wenige Bytes geändert 
- aber genug, daß kein Block unverändert ist - überträgt rsync die 
gesamte Datei.

Hanno

[toc] | [prev] | [next] | [standalone]

#232868

Karsten Düsterloh schrieb:
> Jörg Tewes aber hob an zu reden und schrieb:
>>> Das Strohmann-Problem hast du dir aber jetzt auch ausgedacht, denn 
>>> um parallele schreibende Nutzung ging es gar nicht.
>> 
>> Nein, aber die Dateien sollen ja wohl nicht nur kopiert werden weil 
>> es geht, sondern um sie im Notfall auch nutzen zu können.
> 
> Bzw. um im Notfall möglichst viel bereits gerettet zu haben.

Klar, man kann immer nur wiederherstellen was man gesichert hat.

>> Also muß RSync z.B. die Mails/Postings die ich schreibe, in die große
>> Datei auf dem Netzlaufwerk so einfügen das man die Datei einfach 
>> zurückkopieren kann
> 
> Nicht einfügen. Anhängen. Wo ist das Problem?

Das ist halt die Frage, ist das ein Problem? Und was passiert wenn ich
Mails und/oder Postings lösche? Dann sind die hinterher wieder da, und
das womöglich nach Monaten. Die gesicherte Datei wird immer größer,
während die Originaldatei ca. gleich groß bleibt, aber auf jeden Fall
nicht so wächst wie die Sicherung.

> Schwieriger wird es, wenn sich Daten *in* der mbox ändern.

Ahja, da ist ja mein Einwurf. :-)

> Das könnte dann interessant werden (ich weiß nicht, ob rsync das kann,
> das müssen andere beantworten).

Die Frage ist halt auch, wie es bei Dateien funktionieren soll, wo
neue Daten nicht einfach angehängt werden?

> Viele der Metadaten stehen bei TB ja nicht in der mbox, sondern in der
> zugehörigen Indexdatei.

Ja ok das kommt noch dazu.

>> und dann den gesicherten Zustand wieder hergestellt hat. Das wage ich
>> halt bei solchen Dateien wie MBOX-Dateien oder Datenbanken zu
>> bezweifeln.

> Naja, gerade Datenbanken bieten so Sachen wie "Hot Standby"
> <https://wiki.postgresql.org/wiki/Hot_Standby>/"Streaming Replication"
> <https://wiki.postgresql.org/wiki/Streaming_Replication>, die genau das
> ermöglichen sollen.

Das erfordete dann aber einen Eingriff am bearbeitenden Programm, das
es damit funktionieren könnte/sollte schrieb ich ja schon. Ich weiß
nicht ob ein Datenbankprogramm alle 10 Minuten oder wie die Frequenz
im OP war, genauso was machen könnten.


        Bye Jörg

-- 
"That does seem to be the rule, doesn't it? Analyze the problem,
choose whichever strategy makes least sense, and do it."
(Dr. Lazarenn, "Confessions and Lamentations")

[toc] | [prev] | [next] | [standalone]

#232870

On Thu, 10 Dec 2015 00:15:55 +0100, "Jörg Tewes" posted:

...
>Das erfordete dann aber einen Eingriff am bearbeitenden Programm, das
>es damit funktionieren könnte/sollte schrieb ich ja schon. Ich weiß
>nicht ob ein Datenbankprogramm alle 10 Minuten oder wie die Frequenz
>im OP war, genauso was machen könnten.

Ein DB-Programm schreibt üblicherweise ein Änderungslog mit, mit dem
jederzeit eine Wiederherstellung möglich ist. 

-- 
Schöne Grüße,
Wolfgang

[toc] | [prev] | [next] | [standalone]

#232878

Wolfgang Kynast schrieb:
> On Thu, 10 Dec 2015 00:15:55 +0100, "Jörg Tewes" posted:
> 
> ....
>>Das erfordete dann aber einen Eingriff am bearbeitenden Programm, das
>>es damit funktionieren könnte/sollte schrieb ich ja schon. Ich weiß
>>nicht ob ein Datenbankprogramm alle 10 Minuten oder wie die Frequenz
>>im OP war, genauso was machen könnten.
> 
> Ein DB-Programm schreibt üblicherweise ein Änderungslog mit, mit dem
> jederzeit eine Wiederherstellung möglich ist. 

Das man dann auch sichern muß.


        Bye Jörg

-- 
"I'm here to pick up some women."
"You'll have better luck at bars."
(Vir and Garibaldi, "Soul Mates")

[toc] | [prev] | [next] | [standalone]

#232918

On Thu, 10 Dec 2015 01:41:13 +0100, "Jörg Tewes" posted:

>Wolfgang Kynast schrieb:
>> On Thu, 10 Dec 2015 00:15:55 +0100, "Jörg Tewes" posted:
>> 
>> ....
>>>Das erfordete dann aber einen Eingriff am bearbeitenden Programm, das
>>>es damit funktionieren könnte/sollte schrieb ich ja schon. Ich weiß
>>>nicht ob ein Datenbankprogramm alle 10 Minuten oder wie die Frequenz
>>>im OP war, genauso was machen könnten.
>> 
>> Ein DB-Programm schreibt üblicherweise ein Änderungslog mit, mit dem
>> jederzeit eine Wiederherstellung möglich ist. 
>
>Das man dann auch sichern muß.

Das legt man gleich auf eine andere Platte. 

-- 
Schöne Grüße,
Wolfgang

[toc] | [prev] | [next] | [standalone]

#232861

Am 09.12.2015 um 22:49 schrieb Jörg Tewes:

> Nein, aber die Dateien sollen ja wohl nicht nur kopiert werden weil es
> geht, sondern um sie im Notfall auch nutzen zu können. Also muß RSync
> z.B. die Mails/Postings die ich schreibe, in die große Datei auf dem
> Netzlaufwerk so einfügen das man die Datei einfach zurückkopieren kann
> und dann den gesicherten Zustand wieder hergestellt hat. Das wage ich
> halt bei solchen Dateien wie MBOX-Dateien oder Datenbanken zu bezweifeln.

Ich sehe da kein Problem.

Hanno

[toc] | [prev] | [next] | [standalone]

#232883

Am 09.12.2015 um 23:46 schrieb Hanno Foest:
> Am 09.12.2015 um 22:49 schrieb Jörg Tewes:
> 
>> Nein, aber die Dateien sollen ja wohl nicht nur kopiert werden weil es
>> geht, sondern um sie im Notfall auch nutzen zu können. Also muß RSync
>> z.B. die Mails/Postings die ich schreibe, in die große Datei auf dem
>> Netzlaufwerk so einfügen das man die Datei einfach zurückkopieren kann
>> und dann den gesicherten Zustand wieder hergestellt hat. Das wage ich
>> halt bei solchen Dateien wie MBOX-Dateien oder Datenbanken zu bezweifeln.
> 
> Ich sehe da kein Problem.

Ob das ein Problem ist oder nicht hängt einzig davon ab, ob die
Ausgangsdatei während des Sync verändert wird. Und die
Wahrscheinlichkeit wird größer (alles andere gleich), je länger der Sync
dauert, also je länger die Datei ist.

[toc] | [prev] | [next] | [standalone]

#232499

On 12/07/2015 11:18 AM, Jörg Barres wrote:
> Hallo Leute,
>
> schönen Nikolaus und so weiter :-)
>
> Ich habe mal wieder eine Frage an die vorhandene Experience:
>
> Ich würde gerne einen Ordner, der geöffnete Dateien enthält, auf einer
> Freigabe im Netz synchron halten, alle 10-15 Minuten reicht, muss alo
> keine real-time-sync sein.
>
> Quellordner ist eine VM unter ESXi, ein Zugriff per SSH ist möglich.
> Die dort laufende VM soll auf einem Netzlaufwerk gesichert werden, aber
> ohne sie vorher runterzufahren.
> Die Dateien sind also teilweise recht groß (etliche GB), ein
> vollständiges Kopieren ist also nicht das Ziel, sondern nur ein Kopieren
> der geänderten Bereiche.

Ich dachte rsync kann sowas? Durch SSH pipen geht damit auch.

  Gerrit

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | ger.ct

csiph-web