This came up on #VMware on Freenode this weekend. Basically the concern was “How do I Backup my ESXi USB Key?” Other than ripping the USB key out of a production machine… how was the user to do this? Well, vMA and the vCLI provide a method for this:

Backing up your ESXi Configuration:

To backup your ESXi configuration you’ll be using the vicfg-cfgbackup.pl command as follows:

• Download either the vMA or vCLI
• Launch vicfg-cfgbackup.pl:
  C:\Program Files\VMware\VMware vSphere CLI\bin>vicfg-cfgbackup.pl –save –server 192.168.15.253 –username root –password password backup.bak
• Note: The backup will be stored relative to your user “AppData” path:
  C:\Users\Username\AppData\Local\VirtualStore\

Restoring your ESXi Configuration:

Restoring your ESXi config can be done after you have the host up and responding over the network again by using the following:

C:\Program Files\VMware\VMware vSphere CLI\bin>vicfg-cfgbackup.pl –load –server 192.168.15.253 –username root –password password backup.bak

Note: You will be asked to reboot the host on restore.

Backing  up multiple hosts! – There is a script to backup multiple ESXi hosts on the VMware communities site here. Also in PowerCLI here!

[Edit: Added link to backup multiple ESXi hosts from William in the comments. Thanks William!]
[Edit 2: Added PowerCLI link from NiTRo. Site is in French, PowerCLI is not]

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.

I likely should have started with a post or two about vDR (VMware Data Recovery), what it is, and how to install it. Instead, I’ll point you to some of the docs on those: Info & Installing. The installing guide is especially recommended after I spent a few days unsuccessfully installing vDR (Hint: Use the most recent code)

That said, now that everything is installed and connected, creating the first back job is straight forward (more in another post if you’d like) except the retention policies. VMware’s vDR admin guide has this to say on it:

Retention Policy
    Data Recovery backups are preserved for a variable period of time. You can choose to keep more or fewer backups for a longer or shorter period of time. Keeping more backups consumes more disk space, but also provides more points in time to which you can restore virtual machines. As backups age, some are automatically deleted to make room for new backups. You can use a predefined retention policy or create a custom policy. The backup policy is once a day during the backup window.

What does that mean? Well, take a look at the first screenshot of what you’re presented with:

Few, More, Many and Custom. If only backups were that simple, often they’re not.

Here is a breakdown of the default policies:

Few: 7 most recent, 4 weeks, 3 months
More: 7 most recent, 8 weeks, 6 months, 4 quarters, 1 year
Many: 15 most recent, 8 weeks, 3 months, 8 quarters, 3 years

If you don’t already have a backup policy/job, perhaps one of these will fit, as all the options are quite sensible. Keeping in mind that the higher you go, the more space they’ll take. If one of these does not fit… there is always custom, which can be tuned to your hearts desire.

Let me know if you have vDR questions in the comments.

Still cleaning out my feed reader after having slacked for a few days, and came across this gem on Yellow-Bricks:

I’ll have to give this a test shortly to see how well it performs. Woot!

Thomas at Tandem wrote a wonderful PDF on setting up Site Recovery Manager using the Netapp Simulator.

PDF Can be downloaded here

Trilead VM Explorer is a management tool that eases management, backup and disaster recovery tasks in your VMware ESX Server environment. You get maximum flexibility: backups can be stored to ESX, Windows, Linux and FreeBSD based storage platforms or directly to a SAN. Our newest edition even has beta support for the ESX 3i server.

The free version can be downloaded here

So, this is a bit of old news, and you have likely heard it from no fewer than thirty other places so far, but I feel I need to chime in too.

ESX 3.5 update 3 is now available!

The release notes mention a pretty cool feature that’s been added, that will help make life quite a bit easier, and that is the VMDK Recovery Tool. It’s not exactly a backup solution, and is not meant to be. There are plenty of those available (esXpress, Veeam, etc). What it does do, is let you back up a single VM, or all VM’s on a host from one datastore to another. Something like this:

[root@esx11]# vmfs-undelete


########################################################


# VMFS Data Recovery and Backup #


# #


# This tool is NOT a replacement for regular backups #


# Please backup your data on a regular basis #


# There is absolutely no guarantee #


# Use at your own risk #


# #


# VMs with Raw Disks (virtual or physical) are #


# Not supported!!!! #


########################################################

————————————————–


Select [b]ackup, [r]estore [q] to quit: b


——————————————


0 ) /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/Win2k3DC-64/Win2k3DC-64.vmx


1 ) /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/mandel-rhel3-32/mandel-rhel3-32.vmx


2 ) /vmfs/volumes/48da37be-22e0d1a4-b076-0019bbd51b56/spanis/spanis.vmx


3 ) /vmfs/volumes/48da37be-22e0d1a4-b076-0019bbd51b56/rhel4/rhel4.vmx


4 ) /vmfs/volumes/48da37be-22e0d1a4-b076-0019bbd51b56/spanfc/spanfc.vmx


5 ) /vmfs/volumes/48932bc1-a4b8a07e-ac22-0019bbd51b58/Win2k3DC-32/Win2k3DC-32.vmx


——————————————


found 6 vms


Choose a VM to backup, [99] for all registered VMs or [q] to quit: 1


number of vms to backup 1


Ready to write to data to disk


Enter path and filename of where to save the recover log to:/back/test


________________________________________


working on VM: /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/mandel-rhel3-32/mandel-rhel3-32.vmx


Checking for VM Snapshots…


Creating Snapshot…


read block list for /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/restore/mandel-32.vmdk


removing snapshot….


Done……


########################################################


# VMFS Data Recovery and Backup #


# #


# This tool is NOT a replacement for regular backups #


# Please backup your data on a regular basis #


# There is absolutely no guarantee #


# Use at your own risk #


# #


# VMs with Raw Disks (virtual or physical) are #


# Not supported!!!! #


########################################################

————————————————–


Select [b]ackup, [r]estore [q] to quit: q

You can also restore from the same:

[root@esx11 /]# vmfs-undelete


########################################################


# VMFS Data Recovery and Backup #


# #


# This tool is NOT a replacement for regular backups #


# Please backup your data on a regular basis #


# There is absolutely no guarantee #


# Use at your own risk #


# #


# VMs with Raw Disks (virtual or physical) are #


# Not supported!!!! #


########################################################

————————————————–


Select [b]ackup, [r]estore [q] to quit: r


enter file name to restore from: /back/test

—————————————-


1) /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/mandel-rhel3-32/mandel-rhel3-32.vmx


Found 1 VMs available to restore

select VM to restore [1 - 1] or ‘q’ to quit:1


Available VMDKs to restore:


—————————————-


1) /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/restore/mandel-32.vmdk


select VMDK to restore [1 - 1 ]: 1


1) /vmfs/volumes/spannedISCSI ——> [VMFS UUID: 48ad7ec0-e325a051-b085-0019bbd51b56]


2) /vmfs/volumes/esx11:storage1 ——> [VMFS UUID: 48ad95b7-a4fbcfd2-3ae5-0019bbd51b58]


3) /vmfs/volumes/datastore4 ——> [VMFS UUID: 48da37be-22e0d1a4-b076-0019bbd51b56]


4) /vmfs/volumes/100gb ——> [VMFS UUID: 48932bc1-a4b8a07e-ac22-0019bbd51b58]


5) /vmfs/volumes/spannedFC ——> [VMFS UUID: 48ada29d-e6f0dd4b-c312-0019bbd51b58]


6) /vmfs/volumes/templib ——> [VMFS UUID: 000a8416-362eaee8-b274-00145e5a474f]


select VMFS DataStore to restore to [1 - 6] : 4


Enter the directory to restore to: restore


/vmfs/volumes/100gb/restore already exists


Are you sure you want to restore to /vmfs/volumes/100gb/restore [y/n]: y


Enter the file name to restore to: [ex: recovered.vmdk]: test.vmdk


restoring VM: /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/mandel-rhel3-32/mandel-rhel3-32.vmx


Disk: /vmfs/volumes/48b033a5-b8c3c297-424d-0019bbd51b56/restore/mandel-32.vmdk


to : /vmfs/volumes/100gb/restore/test.vmdk


restoring data….


[==> 4%

Pretty cool.