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:




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


/etc/init.d/rd_domino start


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!


Arcserve RHA vs Zerto

Choosing the right replication solution for your organisation can be tricky if not daunting.  Arcserve RHA or Zerto? That is the question! In this post we highlight the key features and benefits of both of these products in an attempt to make the decision making process easier for you.

Arcserve RHA vs Zerto

In short, Zerto is a hypervisor agentless VM replication solution whereas Arcserve RHA is an agent based real time replication & high availability solution.


Zerto requires a ZVM (Zerto Virtual Manager) on each site, a ZVA (Zerto Virtual Appliance) on each virtual host and a ZCM (Zerto Cloud Manager) in order to manage multi-tenancy. This can range from a minimum of 4-5 servers upwards, depending on the amount of hosts.

Arcserve RHA requires a minimum of 1 control service engine with RHA manager, to 2 servers if redundancy is required for scenario management.



  • After the large installation, Zerto allows for simplistic DR VPGs (Virtual Protection Groups) to be created.  This doesn’t involve much configuration except to point to a secondary site ZVM & some Re-IP configuration for the DR site.
  • SLAs can be created to ensure VPGs meet their RPO’s.
  • Zerto replicates VM files at a block level to the DR site spool and only creates and powers a VM onto the DR Hypervisor once failover is initiated, regardless of whether it’s a test or real scenario. Therefore Zerto cannot guarantee a RTO.
  • Zerto does not test application or data consistency within the guest OS of the protected VM.
  • When a scenario involves a transactional intensive DB environment; an agent is required to be loaded onto the specific VM’s.  Guest Quiescing is then initiated from Zerto to commit transactional logs (log truncation) so that the DB’s stay consistent on the DR side as it’s an active passive solution. SQL is only built at the point of failure with the latest blocks replicated; and you would need to consider factors like transaction size and long-running transactions that cannot be cleared from the log until they have completed. If a fail over where to occur during the transaction, the DR VM built on the other side will have inconsistent DB’s in a recoverable state.
  • Zerto has a journal history function where blocks can be rolled back to a certain time, but you would need to find a specific point in time where all transactions were completed. Alternatively you can load a Zerto agent which will Quies the guest OS, thus utilising VM resources and IO.  Zerto recommends that it be run every 4 Hours +, inflating your RPO to 4 Hours.
  • Zerto’s failover process requires the user to log into the site ZVM and press a fail over button.  There is no HA or automatic failover solution.

Arcserve RHA:

  • Arcserve RHA requires a control service engine to be loaded onto the server managing the HA or DR replication scenarios. A control engine agent is loaded onto each server protected.
  • Unfortunately the scenario setup requires that the user be more involved. Arcserve allows for DR file & application replication where failovers are manual & HA full system or application HA; where failover can be manual or automated with integrated DNS changes to the local DNS server.
  • In a replication scenario; a live DR VM or server is required to receive replicated files and the server will be required to be setup by the user. With application HA; the server will require the application to be setup and configured as well. This does require more setup and running computer resources on the DR site but it has its added benefits.
  • Arcserve RHA allows for replication or HA from physical environments, virtual or a mixture of both (P2V, V2P, V2V & V2P) this can then be configured to automatically failover or failover through user Intervention. This then provides seconds RPO & seconds RTO.
  • Arcserve has another feature called ‘Assured Recovery’ that allows for automated HA & DR testing and unlike Zerto, tests the application in the guest OS as well as the data constancy with the master server.
  • Other features include data rewind (similar to Journal History) where you are able to rewind changes made to an application or the OS files; unlike Zerto which is at a hypervisor block level only.
  • Synchronization between servers can be done at a block or file level.
  • This entire solution is then able to integrate into Arcserve UDP (Backup Suite) and is managed through a console with 1 license.
  • To avoid the large setup of building the DR VM’s for your scenarios, you can use the backup feature of UDP to replicate source servers and export as VSB ( Virtual standby ) the VSB can then be used in an HA or replication scenario.

Quick Feature Comparison

arcserve zerto comp