Backup ReadyNas to ReadyNas with rsync and exclude lists

ewok wrote:
You would have to ssh in and make the change manually.

I, too, need the ability to pass an arbitrary number of extra flags and parameters to rsync when it performs back-ups.

For example, I need to back up a chroot'ed BIND installation that features a /proc directory within the chroot'ed environment. If I don't use '--exclude chroot/proc' when backing this up, madness ensues and the job fails.

FrontView is inadequate for this. There really ought to be a text field in which one can add the necessary extra options for insertion in the rsync command line that is ultimately invoked.

Lacking this, I finally succumbed to the urge to install the EnableRootSSH patch and go poking around in search of something I could easily hack to get the job done.

Well, I found it. /frontview/bin/backup is the Perl script that handles the back-ups. It's invoked by each of the scheduled back-up jobs, which are listed in /etc/cron.d/frontview-backup.

Happily, the extra functionality can be added to /frontview/bin/backup in about 15 lines of Perl. Here's how I chose to implement it: The patch below works on RAIDiator 4.1.3 (and possibly others).

--- backup.orig	2008-09-25 15:56:13.000000000 +0200
+++ backup	2008-09-25 22:19:35.000000000 +0200
@@ -244,6 +244,22 @@
   $rsync_option .= " --delete";
 }
 
+my $rsync_option_file = '/frontview/conf/rsync.conf';
+if( $backup_source_share_proto eq 'rsync' && -f $rsync_option_file )
+{
+  open(RSYNC, $rsync_option_file);
+  my @rsync = <RSYNC>;
+  close(RSYNC);
+
+  my $row = (grep(/$backup_source_path/, @rsync))[0];
+  if( $row )
+  {
+    my ($extra_options) = (split $FS, $row)[1];
+    chomp($extra_options);
+    $rsync_option .= " $extra_options";
+  }
+}
+
 my $mount_point = "/job_${job}";
 my $login_param;
 my $source_path = "/$backup_source_share_proto/$backup_source_path";

I wanted to avoid having to repeatedly hack system files when a back-up job with extra rsync options needs to be modified, so I chose to have the new functionality use its own configuration file, /frontview/conf/rsync.conf.

That file should contain one line of additional rsync configuration per back-up job. Each line should contain two fields, separated by the standard FrontView field separator, two exclamation marks (!!).

The first field is the back-up source, which uniquely identifies the back-up job by host::module/path.

The second field consists of the options that should be inserted in the rsync command line before it is invoked.

In my case, /frontview/conf/rsync.conf looks like this:

foo.caliban.org::slash/var/named!!--exclude chroot/proc --delete-excluded

Now, when an rsync back-up job is run that has foo.caliban.org::slash/var/named as its source, '--exclude chroot/proc --delete-excluded' is added to the rsync command line.

The nice thing about this approach is that /frontview/conf/rsync.conf can be maintained and edited on some other machine and ssh'ed into place on the ReadyNAS. There's no need to work directly on the ReadyNAS, which is important to me. It's an appliance and I want to treat it as such. Logging into it and performing this hack was the last resort for me.

Some would say that, if you need this level of control, you should be configuring the back-up job on the client and pushing your data to the ReadyNAS. However, I need to back-up multiple machines and I want all of my back-up jobs centralised on the ReadyNAS. This is an entirely reasonable approach to managing back-ups.

Obviously, I would like to see this functionality added to FrontView. I don't like the fact that I've potentially endangered my right to tech support by installing EnableRootSSH. I also don't like poking around on an appliance that wasn't really intended to be manipulated at this level. I consider it a dangerous activity.

Anyway, this works for me. If you know what you're doing, it will work for you, too.