This post has been restored from an archived copy. Links
may have changed or be broken.
So it's not a secret that I am a big fan of Debian Linux, and also not a secret that I am a big fan of NetApp's storage technology (I did go work for them when given the chance after all), however in the "Enterprise" world Debian is kind of a second class citizen. Most people have heard of it but RedHat kinda rules the day... Thankfully if you do it right Linux is pretty much Linux from a compiled binary standpoint.
So NetApp ships a product called Open Systems SnapVault or OSSV. This uses some really neat technology to do block-level delta based backups to a NetApp FAS/V series controller and is currently the backbone of my backup strategy. Because it's a block delta transfer I can quite happily backup a large swath (about 100GB all told) of my home network, over my residential (1M up) Internet connection to a remote colocation facility where I have a FAS sitting without a whole lot of headache. The one hurdle was getting the agent to run on my home server, which runs Debian 6.0 (squeeze) on amd64, since the agent is designed to run on RedHat and SuSe.
Step 1: This is only if you are running the agent on amd64 instead of i386. The OSSV binary is 32 bit, so you will need to ensure you have libc6-i386 installed.
Step 2: Begin the install of the OSSV client as per the documentation
(untar, run ./install, etc). It will bomb out at some point mid-way
through with library problems. This is because for whatever reason it
puts the libs it needs in $DIR_YOU_TOLD_IT_TO_INSTALL_TO/lib
instead of any system lib directory. Change to the lib directory under
the install hierarchy and execute as root ldconfig . to add the
libs to the dynamic linker cache.
Step 3: Now, because the install never finished (a bunch of stuff wasn't
configured), the easiest thing to do is in fact uninstall OSSV. To do
that you goto the directory it was trying to install to and run the
uninstall script.
Step 4: Re-run the installer with the same settings as before, into the same directory as before and thanks to the updated dynamic linker cache everything should complete successfully and the agent will start.
Step 5: RedHat doesn't seem to use the same LSB syntax for init-script
metadata as Debian does so you'll want to add the LSB info to the top of
/etc/init.d/snapvault so that Debian's init system will know what to do.
For your convenience here is what the block looks like:
### BEGIN INIT INFO
# Provides: snapvault
# Required-Start: $local\_fs $syslog $network $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: NetApp OSSV client
### END INIT INFO
I put this below the existing comments and before the PATH declaration in the script.
Step 6: Tell Debian to start OSSV at boot. This is as easy as issuing
update-rc.d snapvault defaults as root. Thanks to the LSB metadata
we just added, the init system should sequence the OSSV agent startup
appropriately in the startup order and away you go.
Now, after you establish your snapvault relationships you should see
something pretty like this when you issue snapvault status:
tardis 21:28:12 /vol/snapvault (2819)$ sudo /vol/snapvault/bin/snapvault status
Snapvault primary is ON
Source Destination State Lag Status
tardis:/vol/kvm_images toaster:/vol/snapvault/tardis-kvm_images
Source 21:24:48 Idle
tardis:/vol/staff toaster:/vol/snapvault/tardis-staff Source 21:24:48
Idle
tardis:/ toaster:/vol/snapvault/tardis-root Source 21:24:47 Idle