Jonathan Allen wrote:
Drbd http://www.drbd.org/ does it live. If you can live with periodic
snapshots instead, you can do it with rsync.
Correct me if I'm wrong, but this looks like a block-level mechanism,
which is exactly what I said I didn't want.
It is, but it is also the only mechanism likely to actually work for the
real time mirroring you said you did want. I think you can use a file
image as a target instead of a real block device if you need to keep it
within some other larger filesystem on the remote, but in any case you
shouldn't have it mounted there unless the underlying filesystem is
cluster-aware like GFS.
I want to be able to
intercept the open(2)/write(2)/close(2) calls and after passing them
on to normal ext3 filesystem, copy their contents over to an application
that will simply mimic the file operations, so that the destination
filestore can both be normal, contain other stuff and/or simply be
a small part of a large partition.
I don't think that exists, and if it did it would have no way to recover
when the contents become out-of-sync. What happens when a local app
does random writes or seeks to the end of a file that doesn't exist on
the backup because that machine was down when the file was created?
What should link() do if the name already exists on the backup but not
locally? In any case, a periodic rsync would come close to what you
want and is reasonably fast unless the number of files is very large.
--
Les Mikesell
lesmikesell@xxxxxxxxx
