Read this if you’re thinking of going 100% agentless!

Since the beginning of backup times (almost), backing up specific platforms has typically required an agent optimized for the environment in question.  Typically, you’d get one agent installed on each server, the agent would interact with the backup engine/server and do its thing.  This became very cumbersome when virtualization exploded, when adding a server (virtual) could be easily done with one phone call to your favorite admin. Not just one, but dozens or hundreds. It meant installing one agent on each virtual machine, which quickly became cumbersome and operationally created data protection gaps and issues.

Along came agentless backup which significantly reduced the difficulty associated with backing up virtual machines.  With this approach, you can capture all of the VMs with a proxy server without having to install an agent in each virtual machine.  Less administration, less data loss exposure…what else could be better? It certainly made agent backup look old and clunky.

Not so fast…. As is often the case, there’s more than meets the eye.  You can’t just go 100% agentless…Here’s why:

  • With VMware, any virtual machine that does not use native VMFS cannot be properly protected “agentless-ly” leveraging the native VMware API’s.  Raw Device Maps (RDM’S), and SQL Cluster disks are both examples where a different File System to VMFS is used.
  • Our competitor Company V’s agentless technology, for example, can’t protect these systems.  In contrast, Arcserve easily can through the installation of an agent.  In a recent conversation with our field, we confirmed that we often see customers who use RDM’s being told by Company V that they have to convert them to ‘normal’ virtual machines.  That’s a dirty little secret, and something that many customers just won’t deal with. (By the way, this company’s recent announcement around agent deserves serious inspection – a glorified desktop agent is not the same thing as a full-featured server agent.)

To quote one of our field leads: “Our physical server support through the UDP agent install is a significant advantage over Virtual only agentless solutions.  The ability to be able to protect and recover physical machines as bare metal, as virtual machines or at an object and file level is obvious, but it also allows us to protect virtual machines that are not supported by the native tools and API’s.  There are also circumstances where it may be preferable to install an agent inside the virtual machine – for example if the virtual machine is very large or has a very high change rate, or if the VM Tools are perhaps not properly configured or up to date.”

Also, with our High Availability module, which provides Continuous Data Protection, Fail Over, Fail Back and more, supporting replication and backup of an MSCS cluster running on Windows 2008 R2 in VMware with physical RDM is easy.  It is however a big issue with our competitors Company V and Company Z.  In addition, remember that Arcserve offers great deduplication, global across nodes.  Not everyone does that!

Beware of 100% agentless solutions – they just don’t cut it in many cases!

How to Take Hypervisor Snapshot of Lotus Domino VM with Unix/Linux Guest

I previously published a post Online Backup of Lotus Domino with Arcserve UDP, which used custom scripts so that DB’s consistency was guaranteed during the Arcserve snapshot of a virtual Windows Lotus Domino server.

This was, however, only compatible with Domino on Windows guest. I have since collaborated with Daniel Nashed from Nash!Com in Germany to come up with a creative solution to run an Arcserve Hypervisor snapshot of Domino Virtual Machine running on a Unix/Linux Guest.

Interested? Read on…

Daniel Nashed developed a script for Unix/Linux that would stop domino server. Utilising this script will allow Arcserve to take a DB consistent snapshot through the preferred Hypervisor. The script Bundle is available here. (Please note: the use of blogged scripts are at one’s own risk and should be tested with sandbox or lab copy of your production VMs). There is certain risk in shutting down Domino Server services at every backup, however, a shutdown is the only real solution for ensuring consistency of all databases during backup Snapshot pass.

Using virtualized Lotus Domino as a corporate messaging system on a Unix/Linux guest, the database’s consistency is guaranteed during backup by running custom script Rc_domino_script.

Once you have downloaded the script bundle from Nash!Com the bundle should look like this:

bundle

 

 

To start, the VM guest requires the relevant Hypervisor tools to be installed e.g. VMware tools or Host Integration tools. This will allow Arcserve to pass commands through the Hypervisor to the VM guest and initiate the script pre-snapshot and post-snapshot.

Next, the above files need to be copied to their relevant locations:

Rc_domino_script is the main script logic. It needs to be copied to the Unix/Linux guest location: /opt/ibm/domio

Rc_domino is the main entry point file for the service. It needs to be copied to the Unix/Linux guest location: /etc/init.d

Rc_domino_config_notes is the configuration file used. It needs to be copied to the Unix/Linux guest location: /etc/sysconfig

These three files all reference one another and are required for pre/post-snapshot.
If you are required to make changes, such as a different username for Domino, you will need to make changes to the config. file and modify the settings in the Rc_domino script. For more detail, refer to Read me or NashCom.

Once the script has been copied, we can now create an agentless plan in Arcserve UDP under plan > setting. In the Advanced tab, add the following commands to reference scripts:

/etc/init.d/rd_domino stop

snapshot

/etc/init.d/rd_domino start

snapshot

With the above, we are able to successfully snapshot Domino DB on Unix/Linux without an agent and provide application consistency.

Many thanks to Daniel for his Domino expertise!