[linux-l] RSync für Device-Files

[Peter Ross]

Hi Volker,

On Mon, 28 May 2012, Volker Grabsch wrote:

> RSync legt lediglich auf dem Zielsystem ein ähnliches Block-
> Device an.

Es tut damit genau das Richtige (mehr oder weniger;-): rsync arbeitet auf 
Filesystem-Ebene.

Devices sind lediglich Inodes, und in modernen Systemen nicht einmal 
irgendwo auf Platte, sonders von einem Device-Daemon in einem speziellen 
Device-Filesystem erzeugt (früher gabs statisch mknod)

Die Device-Nodes werden abhängig von der Hardware erzeugt und sind bei 
unterschiedlicher Hardware auch nicht die gleichen - es macht daher gar 
keinen Sinn, /dev zu synchronisieren.

Wenn /dev/sda1 bei Dir auf eine gleichgroße Partition auf einem anderen 
System "gemappt" werden kann, ist das eher Zufall als Absicht (oder halt 
Deine)

> Es gibt keine Option, mit dem ich RSync zwingen
> kann, stattdessen den _Inhalt_ des Block-Devices zu übertragen.
> Zwar gibt es inoffizielle Patches für RSync, doch auch diese
> sollen wohl ihre eigenartigen Problemchen haben.
>
> Andererseits ist das Rotating-Checksum-Verfahren von RSync
> ohnehin Overkill für diesen Zweck. Denn in ein Block-Device
> werden keine Abschnitte eingefügt oder ausgeschnitten. Eine
> "starre" Zerlegung in Blöcke, über die separate Checksummen
> gebildet werden, reicht hier vollkommen aus.
>
> Und siehe da: Diese Idee wurde bereits vor vielen Jahren
> implementiert, in einem einfachen Tool namens "blocksync.py" [1].
> Allerdings hat dieses einige Macken, weshalb ich eine (für
> mich) bessere Variante davon geschrieben habe:
>
>    https://github.com/vog/bscp

Du kannst sinnvoll nur eine Platte "syncen", wenn da kein schreibendes 
Filesystem darauf liegt, normalerweise als "unmounted" oder nur "read-only 
mount".

Ansonsten überträgst Du nur ein inkonsistentes Filesystem. Das ist 
nutzlos.

Du wirst sicherlich irgendwo ein Beispiel dafür haben, sonst hättest Du 
Dir sicher keine Gedanken drüber gemacht..

Ich benutze nun eine Weile ZFS (unter FreeBSD, aber es gibt auch 
ZFSonLinux, und das ähnlich gebaute BTRFS), und meine Strategie besteht 
aus regelmäßigen "zfs snapshot; zfs send | ssh $remote "zfs receive"

Das macht einen Snapshot und überträgt dann diesen zu einem anderen 
Rechner, in der Regel inkrementell gegenüber dem letzten Snapshot.

Da ZFS ein "copy on write"-System ist, also nur Änderungen des Filesystems 
auf die Platten geschrieben werden, braucht, im Gegensatz zu rsync, nicht 
das gesammte Filesystem nach Änderungen "durchforstet" werden, sondern die 
liegen schon bequem zum Übertragen bereit.

Gemessen an dem "ollen Kram" wir rsync und unison (nicht zu reden von 
rsync/unison-Implementierungsproblemen) ein Segen. Ich will, außer 
vielleicht für ein paar spezielle Ausnahmefälle für bestimmte Anwendungen, 
nie wieder was anderes als copy on write.

Es grüßt
Peter