BDSYNC

The lastest (work in progress) version of bdsync can now be downloaded from GitHub.

bdsync

NAME

SYNOPSIS

  Client: bdsync [--verbose] [--digest=DIGEST] REMSHCMD LOCDEV REMDEV
  Server: bdsync --server [--verbose]
  Patch:  bdsync --patch[=DSTDEV] [--verbose]

DESCRIPTION

Bdsync can be used to synchronize block devices over a network. It generates a "binary patchfile" in an efficient way by comparing checksums of blocks of the local block device LOCDEV and the remote block device REMDEV.

This binary patchfile can be sent to the remote machine and applied to its block device REMDEV, after which the local blockdev LOCDEV and the remote block device REMDEV are synchronized.

bdsync was built to do the only thing rsync isn't able to do: synchronize block devices.

OPTIONS

--server

Start bdsync as a server. No further arguments are accepted, all controll is done by standard input and standard output

--patch[=DEVICE]

Make bdsync "patch" a device by applying a bdsync file read from standard input. The device will be determined from the bdsync data unless an (optional) device name DEVICE is specified

--verbose

Increase the verbosity of bdsync. Can be repeated multiple times.

--hash=DIGEST

Choose any of openssl's digests as a hash for matching blocks on LOCDEV en REMDEV. Default is md5.

--blocksize=BLOCKSIZE

Set the blocksize in bytes for which hashes are calculated on both LOCDEV and REMDEV. Default 4096.

--checksum=DIGEST

Choose any of openssl's digests as a checksum for all LOCDEV data. The checksum will be written to the binary patchfile. Default is none.

--twopass

Makes bdsync first match checksums using large blocks (64 * BLOCKSIZE) and then match checksums using small blocks (BLOCKSIZE). This may reduce systemcall overhead and networktraffic when the "binary patchfile" has limited size.

--remdata

Makes bdsync (in client mode) write the remote data to standard output instead of the local blocks that differs.

--diffsize

Makes bdsync (in client mode and patch mode) accept different sizes of devices

USAGE

Bdsync assumes a client is connecting to a server. The connection isn't established by the client itself, but by a remote-shell-command REMSHCMD. This REMSHCMD can be any kind of command to make a connection: rsh, ssh, netcat.. If using rsh or ssh REMSHCMD should be the full command to make the connection including the remote bdsync command te be executed in server mode. If using netcat to make the connection, the remote server mode bdsync command should be executed by inetd, xinetd etc.

The --verbose option results in verbose output. In Server mode the output will be sent to syslog. The --verbose option can be repeated raising the verbosity level.

Bdsync can be initiated like this in its most simple form:

bdsync "bdsync -s" /dev/LOCDEV /dev/REMDEV > DEV.bdsync

This generates a patchfile DEV.rsync of the /dev/LOCDEV and the /dev/REMDEV devices which both are local. A more realistic example is this:

bdsync "ssh doe@foo.org bdsync --server" /dev/LOCDEV /dev/REMDEV | gzip > DEV.bdsync.gz

This bdsync client makes an ssh connection to foo.org as user doe and executes a bdsync client by passing it the --server option. The generated patchfile output is passed on to gzip which creates a compressed patchfile DEV.bdsync.gz.

On the remote machine foo.org the user doe can apply the patch by executing:

gzip -d < DEV.bdsync.gz | bdsync --patch=/dev/DSTDEV

The reason to use a binary patch file instead of instantly patching the remote block device REMDEV is twofold:

o

Sending over a complete patchfile allows to synchronize in a consistent way in case of an interruption (powerloss, network malfunction) since you can choose to apply the (complete) patchfile or not.

o

Compression of the patchfile can easily be done, without introducing complexity in bdsync itself.

Index

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

USAGE