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:

nss /poolactivate=RSYNC1 
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 
--daemon --config=RSYNC1:/rsync/rsyncd.conf

Example Load Script for the non-SSL Instance of RSYNC:

nss /poolactivate=RSYNC2 
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
--config=RSYNC2:/rsync/rsyncd.conf

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:

RSYNC1:rsync/rsyncdn Rsync10.10.10.207:873

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

RSYNC2:rsync/rsyncdn Rsync10.10.10.208:873

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=
SYS:rsync/excludes.txt

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:

[SITE1]
   path = RSYNC2:/SITE1/USERS
   comment = USERS backup area for SITE1 server
   read only = no
   use chroot = no 
   timeout = 3600
   transfer logging = yes
   use lfs=yes
   hosts allow=10.1.1.203
   hosts deny=*

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
--update

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 from replication.

Example: My SITE1 server has this excludes.txt file to exclude certain
file types from the transfer:

#EXCLUDES.TXT
*.mp3
*.wma
*.rma
*.mov
*.vid
*.avi

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.