Thanks for your feedback, I'm aware of the potential dataloss. So far however
in my experience (Linux, ext4) systems recover very well from unforseen
shutdowns, especially if the application software (like Oracle databases) also
addresses this.
I could have the VM's use data=journal to further
> I'm sure I'm replicating a moment in time like someone pulled the power plug.
> I assume that the VM's can recover from that.
Maybe...
It will depend what you are backing up. Some things may be fine with having the
power plug pulled out, while others may not. I would not count on it just
be
DRBD seems a suitable alternative, but I looked into it and it seemed
quiet complex. I am mostly interrested in asynchronous replication, and
I'm not sure if this works in a proper way. The proper way for me means
that write order is preserved for consistency reasons (explained below),
and I can't
On 06/27/2012 08:48:30 AM, Karl O. Pinc wrote:
> On 06/27/2012 06:51:29 AM, Rolf Fokkens wrote:
>
> > After having wrestled with rsync and several patches I found a
> > solution to
> > synchronize block devices: BDsync.
> >
> > Bdsync can be used to synchronize block devices over a network. It
>
On 06/27/2012 06:51:29 AM, Rolf Fokkens wrote:
> After having wrestled with rsync and several patches I found a
> solution to
> synchronize block devices: BDsync.
>
> Bdsync can be used to synchronize block devices over a network. It
> generates
> a "binary diff" in an efficient way by comparing
Hi!
After having wrestled with rsync and several patches I found a solution to
synchronize block devices: BDsync.
Bdsync can be used to synchronize block devices over a network. It generates
a "binary diff" in an efficient way by comparing MD5 checksums of 32k
blocks of block devices. This binar