After you’ve spent the time installing VMware Data Recovery (vDR), you may find that some of the defaults do not work well. Some of these, like the retention policies are an easy change. Others, like the behavior of the vDR appliance, however, are a bit more difficult. To that end, you can create a datarecovery.ini file, to otherwise control the behavior of the appliance. What lies below is a bit of the how to create said file, as well as which parameters are helpful to change and why.
Creating The File
First you need to create the file. This can be done by logging in to the vDR appliance with either the default credentials, or the ones you set when configuring it (you did change those, right?… Right?)
Once logged in we do the following:
service datarecovery stop
touch /var/vmware/datarecovery/datarecovery.ini
This stops the data recovery service, and creates the file for us. Then we can proceed to use our favorite text editor to put the contents of the file together. Starting with the format:
[Options]
DisableHotaddCopy=1
DisableNetworkCopy=1
IntegrityCheckInterval=7
The Options
There are just over a bakers dozen worth of options for this file. The full list can be found in VMware KB 1013175. Here we’ll discuss the following:
- DisableHotaddCopy=1
- DisableNetworkCopy=1
- IntegrityCheckInterval=7
- RetentionPolicyInterval=7
- DedupeCheckOnRecatalog=1
Disable Hotadd Copy/Network Copy
These options will disable the use of that particular option as a choice for data copy. In the DisableHotaddCopy case, it disables the use of SCSI hot add, and will force the use of network copy for backups. In the case of Network Copy, it does just the opposite. Now why would you want to set these options?
The first reason that jumped to mind, is to enforce configuration standards & best practices. It is one thing to have an admin set this up, it is quite another to ensure it can only ever be setup in such a way as your policy dictates. You do have a policy for these things? Right?
In the case of DisableHotaddCopy, I feel there may likely also be a security benefit there. As administrators would no longer be permitted to hot add disks to the server, the risk of an inadvertent cross contamination of data is reduced. In other words, it is less likely that your Jr. admin will be able violate your security policy by attaching the accounting servers backups to the same location as your web servers backups, and the like.
The same case for security can be made for DisableNetworkCopy. By prohibiting the vDR appliance from using the network for data copy, you limit the data exposure to that which might otherwise be dangerous on your network.
My recommendation is to tune these specifically to your environment and policies.
Integrity Check Interval
This one is quite interesting, in that it allows you to tune the default integrity check interval, using a time in days as the measure. Acceptable values are between 1 and 7, however finding the correct value may take a bit of detective work to tune appropriately. Why is tuning this value important? The integrity check for a particular datastore, depending on the size of the datastore, as well as the resources available for such a check, can take a significant amount of time. Knowing that, adjusing this value will allow you to ensure that you are not firing off one integrity check while another is still running.
Retention Policy Interval
Like the IntegrityCheckInterval before it, the values for retention policy are also specified in days. Setting this particular value allows you to tune the amount of time, in days, that passes between the reclaim operations on a dedupe datastore. The appropriate setting for this value will also need to be tuned to your environment, to ensure you are balancing the potentially resource intensive nature of a reclaim event, against your available storage needs.
Dedupe Check On Recatalog
This brings us to the last, but not least important of these values, and that is the DedupeCheckOnRecatalog. This is either a true or false (1 or 0) value, that controls whether or not an integrity check gets kicked off directly after a recatalog event. As mentioned before, the integrity events can be long running events, and kicking off an additional check may be more hassle than it’s worth (after-all, if one is already in progress, etc…).
That said, setting this value will depend on some of the selections you’ve made above. For example, if your retention policy interval is set to 3 days, while your integrity check set to 7, you may want to set this flag to true. That is, after you’ve confirmed that the integrity checks will take less than the remaining time between the reclaim and the next nearest check. In this way you can ensure you are balancing your resources, dedupe, and integrity.
For more information, check the VMware KB 1013175. As always, if you have any comments, questions, or complaints, you can drop them in the comments, or send them to cody_bunch on Twitter.
4 thoughts on “Advanced vDR Configuration”
Comments are closed.