| Double SYNC -- Using RSYNC Simultaneously With and Without Branch Office for Data Backup|
Posted: 22 Feb 2005
Some people might already be using (or considering) Nterprise Branch Office,
in order to realize the savings on hardware and administrative costs. But they
are also using full-fledged NetWare servers where the Branch Office appliance is
not appropriate, and may want to leverage the same benefit of using RSYNC to
replicate files from the full servers, at the same time. Can RSYNC do both?
You bet it can. Why would we want this? Nterprise Branch Office allows us to
replicate data (using RSYNC) over public Internet connections using SSL to
encrypt the data during transit, so there is a need to run the RSYNC daemon on
the Central Office server using SSL. However, other NetWare servers (perhaps on
the local LAN or over private WAN links) do not require the overhead of SSL
encryption, and are better replicated using an RSYNC daemon running without SSL.
This could be accomplished by running two separate RSYNC servers at the central
office, or --better-- by running two instances of RSYNC on one Central Office
server. Or --best-- we can run the two (SSL and non-SSL) instances of RSYNC on a
NetWare cluster, to allow for server failover.
Let's examine a scenario where a central office NetWare cluster receives data
replication from both Branch Office appliances and regular NetWare servers.
Essentially, the central office cluster runs two instances of RSYNC, one using
SSL for the NBO servers, and one without SSL for NetWare servers on the LAN. The
data is copied daily using RSYNC from remote servers to a central office server,
which is then centrally backed up to tape.
My Central Office (2-node) cluster servers run NetWare 6.5 with the RSYNC
component installed. To provide for server failover, the RSYNC service is
configured as a cluster resource, which can load on either physical server.
Since I'm running the service twice (one for SSL, and one without), I have
configured two separate cluster volumes, RSYNC1 and RSYNC2, as the cluster
resources, so that they can independently failover to either server node.
Creating Clustered Instances of the RSYNC Daemon
I simply create the two cluster volumes using NSSMU, or iManager, and assign
them their respective IP addresses and preferred node (they can start on the
same server for an active-standby cluster, or on separate servers for an
active-active cluster). I copy the RSYNC software to both volumes (RSYNC1 and
RSYNC2) in RSYNC, and modify the cluster resource load and unload scripts to
launch the RSYNC daemon for each instance:
Example Load Script for the SSL Instance of RSYNC:
mount RSYNC1 VOLID=252
CLUSTER CVSBIND ADD RSYNC1_SERVER 10.10.10.207
NUDP ADD RSYNC1_SERVER 10.10.10.207
add secondary ipaddress 10.10.10.207
RSYNC1:/rsync/rsync --progress --address=10.10.10.207 --port=873 --ssl
Example Load Script for the non-SSL Instance of RSYNC:
mount RSYNC2 VOLID=251
CLUSTER CVSBIND ADD RSYNC2_SERVER 10.10.10.208
NUDP ADD RSYNC2_SERVER 10.10.10.208
add secondary ipaddress 10.10.10.208
RSYNC2:/rsync/rsync --progress --address=10.10.10.208 --port=873 --daemon
NOTE: Normally the rsyncd.conf file lives in the SYS:ETC folder, but to
allow for multiple instances, as well as failover with the cluster volume, we
specify with the "--config=" parameter to use the rsyncd.conf file in the RSYNC
folder in the cluster volumes (RSYNC1 and RSYNC2).
The unload scripts similarly add a statement to shut down the particular
RSYNC service, as in these examples:
del secondary ipaddress 10.10.10.207
CLUSTER CVSBIND DEL RSYNC1_SERVER 10.10.10.207
NUDP DEL RSYNC1_SERVER 10.10.10.207
nss /pooldeactivate=RSYNC1 /overridetype=question
del secondary ipaddress 10.10.10.208
CLUSTER CVSBIND DEL RSYNC2_SERVER 10.10.10.208
NUDP DEL RSYNC2_SERVER 10.10.10.208
nss /pooldeactivate=RSYNC2 /overridetype=question
NOTE: Use RSYNCDN as in the above examples, rather than "unload RSYNC" since
this would kill both instances of the RSYNC daemon, if they were running on the
same physical server. Also note that there is no space before the IP address in
the RSYNCDN command.
Since the SSL instance of RSYNC is running on the cluster resource associated
with the RSYNC1 volume, I can add a line in the HOSTS file of each Branch Office
server to resolve RSYNC1 to that IP address (10.10.10.207), or point the
replication service directly to that IP address. Likewise, since the non-SSL
instance of RSYNC is running on the cluster resource associated with the RSYNC2
volume, I can edit the HOSTS file of each full NetWare server to resolve RSYNC2
to the non-SSL resource IP address (10.10.10.208).
Performing Data Replication from a Normal NetWare Server
Thus on a non-SSL NetWare server, my RSYNC command might look like this:
rsync -rav --volume=DATA: /USERS RSYNC2::SITE1 --delete --exclude-from=
The -rav means -r for recursive, -a for archive, -v for verbose. The source
string is "--volume=DATA: users/" (note the trailing "/"). The destination
string is "RSYNC1::SITE1" (the server name can be resolved via the HOSTS file,
and the SITE1 corresponds to the section specified in the rsyncd.conf file on
the RSYNC server). The double-colon "::" specifies that rsync communication will
occur via TCP, default port 873. The -- delete switch will delete files on the
target that have been deleted on the source (use carefully). The --exclude-from
switch will exclude copying files that are listed in the specified text file
(like, *.mp3 - see below).
See the rsync man pages for a full list of rsync options (available at http://samba.anu.edu.au/ftp/rsync/rsync.html.
The sending server then resolves RSYNC2 as the receiving host from its own
hosts file, and then resolves SITE1 as the file destination from the rsyncd.conf
file on the receiving server (the server running the daemon). Remember, each
instance of RSYNC running on the server will have its own rsyncd.conf file.
That's why it is placed on the corresponding cluster volume, rather than in the
SYS:ETC location. For example:
The Central Office Server RSYNC Daemon Configuration File
My RSYNC2 cluster resource has this section in its rsyncd.conf file, which
allows the command above to work:
path = RSYNC2:/SITE1/USERS
comment = USERS backup area for SITE1 server
read only = no
use chroot = no
timeout = 3600
transfer logging = yes
NOTE: The file location /SITE1/USERS on the volume RSYNC2 must already exist
for the previous RSYNC command to work. Be sure to create it ahead of time.
Preserving NetWare File Trustee Information
Since rsync does not save the NetWare attributes on the files, I run this
trustusers.ncf one minute before the rsync:
TRUSTEE SAVE DATA:USERS DATA:USERS rustees.txt
Then the trustees.txt file gets synched with the data. Thus if I have to
restore, I can also later restore all the NetWare permissions. TRUSTEE.nlm can
be downloaded at http://support.novell.com/servlet/downloadfile?file=/uns/ftf/trust110e.exe.
Restoring Data Using RSYNC
In the event that I want to perform a full data restore of the entire USERS
directory, I can pull data back from the RSYNC server to the source server with
a restusrs.ncf file:
rsync -rav RSYNC2::SITE1 --volume=DATA: users --update
This will restore any files deleted since the last backup, by reversing the
source and target strings. The --update switch will ensure that any files
modified since the last backup will not be overwritten.
This is a "brute force" restore, I realize. If used, it would also restore
deleted files in subdirectories that weren't meant to be restored.
If I need to perform a more selective restore of data, say, down to the
directory level, I can execute the following command on the REMOTE server:
rsync -rav RSYNC2::SITE1/admin/foo/bar/ --volume=DATA: users/admin/foo/bar
This will restore all files in the data:/users/admin/foo/bar directory, while
preserving any files that were updated since the last backup (rsync). The
trailing "/" in the source string is important -- meaning all files/folders in
that directory, rather than the directory itself.
Replication from the Nterprise Branch Office Server
When I am replicating data from a Branch Office Appliance, the configuration
is done using the Nterprise Branch Office Web Management portal, as is normal
for this product. I merely enable replication, point the Central Office Server
IP address to the SSL-enabled instance of RSYNC running on the NetWare cluster,
and import the SSL certificate that I exported from the Central Office server.
See "Setting Up Data Replication" on the Novell Documentation site
for Nterprise Branch Office.
Excluding Certain Files Types in the Data Replication
Of course, we don't necessarily want to replicate all file types. Some users
(perish the thought) may download and save undesirable file types to their home
directories, which we don't want to copy to the Central Office server. Thus the
sending servers will have the parameter "--exclude-from=SYS:rsync/excludes.txt"
in their RSYNC command, which specifies the file types that we wish to exclude
Example: My SITE1 server has this excludes.txt file to exclude certain
file types from the transfer:
Thus we see that RSYNC works happily for both SSL and non-SSL purposes,
replicating for Nterprise Branch Office, or for regular NetWare servers. It can
operate in both modes on the same Central Office server, or --best-- on a
NetWare cluster to provide failover and load balancing. For your data
replication needs, RSYNC does it all.