You can perform full, differential, and incremental backups and restores of vRealize Log Insight VMs.

If resources are not a problem back up all the nodes at the same time, to speed up the backup process. Verify that you are increasing the number of concurrent backups from one, which is the default. Linear backup is also supported but it slows down the restore operation.



vRealize Log Insight backup order

Guidelines for Planning Backups

You can use the following information for backing up vRealize Log Insight 3.3 clusters in a new environment.

  • Ensure that you have no configuration problems on source and target sites before performing the backup and restore operations.

  • During the backup operation, the memory usage can increase due to the vRealize Log Insight cluster usage. In some cases, the worker nodes might be disconnected for 1 to 3 minutes due to high memory usage. To reduce the memory throttling on vRealize Log Insight nodes, follow these guidelines:

    • Allocate additional memory over the vRealize Log Insight recommended configuration.

    • Schedule the recurring backups during off-peak hours.

  • Disable quiesced snapshots, because vRealize Log Insight does not support them.

  • The vRealize Log Insight server supports Linux and Windows agents.

    • If the agent configuration is created on the server side, a separate backup of the agent node is not required.

    • If you use the agent nodes for more than installing the agent software and if these nodes need a full backup, follow the same backup procedure as for any VM.

    • If the agent configuration is done on the client side, on the agents, and if the agent nodes are used only to install vRealize Log Insight agent software, scheduling a backup of the agent configuration file is sufficient. Back up the liagent.ini file and replace the file on the recovered agent or Linux or Windows machine with the backup file.

  • If concurrent backup is not possible, ensure that the vRealize Log Insight master node is backed up first before the worker nodes. Worker nodes can be backed up in any order.

  • Ensure that the backup frequency and backup types are selected based on the available resources and customer-specific requirements.

  • Use the following guidelines when scheduling recurring backups.

    • For a reasonable loaded cluster setup, it might take a while for the first backup to finish irrespective of the tool.

    • The first backup is usually a full backup. Successive backups can be incremental or full backups, Successive backups finish relatively fast, compared to the first backup operation.

  • Use static IP addresses for all nodes in a vRealize Log Insight cluster.

    • Using static IP addresses eliminates the need to update the IP addresses of vRealize Log Insight cluster nodes each time the IP address of a vRealize Log Insight node changes. 

    • vRealize Log Insight includes all node IP addresses in each cluster node configuration file at /storage/core/loginsight/config/loginsight-config.xml#<n> where <n> is the largest number.

    • Some products that integrate with vRealize Log Insight to feed their logs, use a fully qualified domain name (FQDN) or IP address as the syslog target. For example, vSphere ESXi, vSphere, and vRealize Operations Manager use the nodes of the cluster master's or the load balancer's (if configured) FQDN or IP address as the syslog target.

  • Use an FQDN for all nodes in the vRealize Log Insight cluster. 

    • For the master node, when you use a load balancer, a fully resolvable FQDN is required. Otherwise, the ESXi hosts fail to feed the syslog messages to vRealize Log Insight or to any remote target. 

    • Using an FQDN saves time on post-restore and recovery configuration changes, assuming that the same FQDN can be resolved on the recovery site. 

    • For system alerts, vRealize Log Insight uses FQDN host names if available instead of IP addresses.  

    • Assuming that only underlying IP addresses change post-backup and recovery or disaster recovery operations, using FQDN eliminates the need to change the syslog target address (master node FQDN or internal load balancer FQDN) on all the external devices feeding logs to the vRealize Log Insight cluster.

    • With vRealize Log Insight 2.5, you must update the configuration file, located at /storage/core/loginsight/config/loginsight-config.xml#<n> where <n> is the largest number. This configuration file replaces the worker node IP address with the new IP address used for the restored nodes because the FQDN is not used for worker node addresses in the configuration file. You need to make this change only on the master node to synchronize the changes with all the worker nodes.

  • Join requests from a vRealize Log Insight worker node should use the FQDN of the vRealize Log Insight master node.

    • Beginning in vRealize Log Insight 2.5, the master node host value in the configuration file on each of the nodes, located at /storage/core/loginsight/config/loginsight-config.xml#<n>, is based on the value used by the first worker node sending a join request. Using the FQDN of the master node for the join request prevents making any manual changes to the master node host value post-disaster recovery. Otherwise, the worker nodes cannot rejoin the master node until the master node host name is updated in the configuration files on all restored cluster nodes.

  • Provide static IP addresses as well as optional virtual IP addresses for the load balancer. 

    • When configuring an integrated load balancer, provide the optional FQDN for the virtual IP address. This optional FQDN enables vRealize Log Insight to revert to the FQDN when an IP address is not reachable for any reason.