Tivoli Storage Manager for Virtual Environments - Data Protection for VMware supports tape and virtual tape library (VTL) devices with the restrictions listed in this document.
Tape support that is not related to Data Protection for VMware does not change. For example, there is no change to backing up VMware guest files with an in-guest deployment of the Tivoli Storage Manager backup-archive client.
Tape support statement
The following sections describe tape support for Tivoli Storage Manager for Virtual Environments – Data Protection for VMware.
Backup to tape (physical or VTL) – A full or incremental VMware vStorage image backup created by the Tivoli Storage Manager version 6.2.3 backup-archive client (or later) can reside on physical tape or in a VTL. The Tivoli Storage Manager server must be at version 5.5 (or later). Refer to Tape configuration guidelines for additional information on how to configure backup to tape.
Full virtual machine restore from tape (physical or VTL) – This operation is fully supported using the backup-archive client. Data is sequentially read from tape in a manner that minimizes tape positioning overhead. Processing restores a full backup and applies any required incremental backups based on a selected recovery point. Recovery time is affected by the number of incremental backups that must be applied and is a consideration when determining how often to schedule full backups. In addition, current considerations that can affect restore performance still apply. For example, tape and VTL technology, decompression, decryption, reduplication, and network bandwidth can also affect performance.
File restore from tape (physical or VTL) - File restore from a mounted snapshot volume on tape is supported using Data Protection for VMware mount with the following limitations:
- To enable the mount of a snapshot volume on physical tape or VTL, Data Protection for VMware mount must be operating in Tape Mode. Refer to Tape configuration guidelines for additional information on Tape Mode. In this mode, only one virtual machine snapshot volume can be mounted at a time from a Data Protection for VMware Recovery Agent. The limit is one disk when mounting an iSCSI target or one volume when creating a virtual volume from a selected partition. You can have multiple Tivoli Storage Manager tape storage pool volume mounts for different virtual machine snapshots if you install the Data Protection for VMware Recovery Agent on multiple physical machines or on multiple virtual machine guests.
- While Data Protection for VMware mount does not prevent an attempt to mount a snapshot that resides on physical tape, performance can vary significantly and may be severely impacted. Data Protection for VMware mount does not control the way data is accessed on tape. Data access patterns can be random causing high overhead associated with tape positioning operations. For Linux virtual machines, Tape Mode is only supported when directly using the iSCSI initiator. Refer to the Tivoli Storage Manager for Virtual Environments Installation and User’s Guide. Tape Mode is not supported from the Linux Data Protection for VMware Recovery Agent user interface.
While a limited number of files can be recovered from a mounted volume snapshot that resides on physical tape, consider performing a full virtual machine restore from physical tape if you need to recover a large quantity of data or a large number of files.
Refer to Considerations for file restore from physical tape for additional information.
- Typically the performance associated with a file restore from a VTL is quicker than physical tape. But, performance delays can be encountered. For example, mount may require a virtual tape volume that is in use by another restore operation. Tape volumes in a VTL cannot be shared. In this case, mount processing is delayed until the restore operation using the virtual tape volume completes.
Instant restore from tape (physical or VTL) – The Data Protection for VMware instant restore operation is not supported for snapshot volumes that reside on tape. For more information, refer to Instant restore limitations
Tape configuration guidelines
Backup to tape
When configuring backup to physical tape or VTL, there are additional configuration requirements needed to always keep Tivoli Storage Manager metadata (control files) on disk while allowing the actual virtual machine backup data to reside on tape.
- Use the VMCTLMC option to control the storage pool destination for the virtual machine control files. This destination must be a disk storage pool, with no migration to tape. Update the dsm.opt file with this option. Note: VMCTLMC can not be configured with the dsm preference editor and must be manually added to dsm.opt.
- Use the VMMC option to control the storage pool destination for the actual virtual machine data. For example, a VTL storage pool could be used with a LAN free data path directly to the VTL. Or a disk storage pool could be used. For example, a backup over LAN to a disk storage pool that is enabled for tape migration.
- VMMC is always used to control the retention on VM backups. This applies to both disk and tape configurations. VMCTLMC is not used for the retention of the control files. The .CTL and .DAT files are part of the same grouping and are expired together based on the retention policy of VMMC.
- Refer to the Tivoli Storage Manager for Virtual Environments Installation and User’s Guide for additional information.
If a Tivoli Storage Manager server environment uses disk to tape migration, consider the following recommendations:
- Set the disk storage pool MIGDELAY to value that allows the majority of mount requests to be satisfied from disk. Typical usage patterns indicate that a high percentage of individual file recoveries occur within a small number of days, for example for 3 - 5 days from the time a file was last modified. Therefore, consider keeping data on disk for this small period of time to optimize recovery operations.
In addition, if client side deduplication is being used with the disk storage pool, the setting of MIGDELAY should consider how frequently full virtual machine backups are being performed. The recommendation is to not migrate data to tape from the deduplicated storage pool until at least two full backups can be performed for a virtual machine. When data is moved to tape it is no longer deduplicated. For example, if full backups are performed weekly, consider setting MIGDELAY to a value of at least 10 days. This setting ensures that each full backup could identify and leverage duplicate data from the previous week's backup before being moved to tape.
- Use a device class file storage pool rather than a DISK device class storage pool. A typical value for a volume size, specified by a device class MAXCAPACITY parameter, would be 8 GB to 16 GB. For the associated storage pool, consider enabling collocation by file space. Each virtual machine that is backed up is represented as a separate file space in the Tivoli Storage Manager server. Collocating by file space can allow the data from multiple incremental backups for a given virtual machine to be saved in the same volume (disk file). When migration to tape occurs, this could have the affect of allowing multiple incremental backups for a given virtual machine to be located together on a physical tape.
File recovery from tape
To enable the mount of a snapshot volume on physical tape or VTL, Data Protection for VMware mount must be operating in Tape Mode. Tape Mode is enabled by updating the following values in TDPVMwareMount.conf and restarting the mount service:
- 'Tape Mode = 1’
- 'TSM Read ahead=1024'
- 'Read Ahead Cache Size TSM=75000'
The options 'TSM Read ahead=1024' and 'Read Ahead Cache Size TSM=75000' are advanced configuration options that should not typically be changed from the above recommended values. These values are in 16K blocks. An example of the TDPVMwareMount.conf with tape mode enabled is shown in the following figure:
After updates have been saved to TDPVMwareMount.conf, restart the Data Protection for VMware mount service. Confirm that [Tape Mode] is displayed at the top of the mount user interface.
To disable Tape Mode, update the following values in TDPVMwareMount.conf and restart the mount service:
- 'Tape Mode = 0’
- 'TSM Read ahead=64'
- 'Read Ahead Cache Size TSM=10000'
Note: With disk, the larger read ahead and cache are typically not required. They do not significantly improve the performance of a file copy when the backup resides on disk.
The tool TapeMode.exe is provided with this document to automate the configuration of TDPVMwareMount.conf. When invoked, it provides options to enable or disable tape. The TapeMode.exe tool makes it easier to change operating modes.
To download the TapeMode.exe file, click on this icon ->TapeMode.exe <- and save the file to your system.
The following figures are from the Tape Mode interface that is run from the Windows machine that is responsible for mounting tape snapshots.
This tool can be valuable in environments that use both disk and tape storage pools. For example:
- Mount is typically run in a mode with tape disabled. The majority of mount requests are on disk.
- When Tape Mode is disabled, a mount of a tape snapshot fails. In this case, TDPVMwareMount.conf must be updated to enable tape for mount of the tape snapshot. An example of the failure is shown in the following figure.
As an alternative to switching modes for Data Protection for VMware mount, consider installation on two different machines. The installation on one machine would be responsible for disk mounts. The installation on the other machine would be responsible for tape mounts.
Considerations for file restore from physical tape
As previously stated, file restore performance can vary significantly. For example, the data blocks for a file can be sequentially ordered on a single tape. This organization on tape is a result of the blocks for a file being on contiguous sectors on the original virtual machine disk and the required restore point associated with a full backup. The performance of restoring this file would be significantly better than that of a file that is scattered across non-contiguous disk sectors on the original virtual machine disk and that has portions of the file changing over multiple days. This second file restore would require a number of tape positioning operations. The selected restore point could also require data from multiple incremental backups that could potentially reside on multiple tape volumes.
From a user’s perspective, performance variability typically exists in:
- Time required to display partition information – There can be delay from the time the Mount button is pressed to the time partition information is displayed is the ‘Choose mount destination’ panel. This delay is caused because partition information is accessed from the tape volume. The Data Protection for VMware user interface might appear unresponsive for a period of time.
- Time required to present a mounted volume to OS and navigate directories – This delay can result in Windows Explorer appearing to hang, indicate it is not responding or being grayed out for a period of time.
- Time required to copy a file from the mounted snapshot. Note that the Windows estimate of completion time might not be completely accurate.
Factors that can affect access performance of a file restore from physical tape include the following:
- Type of tape hardware (positioning time).
- Amount of data being restored.
- Number of files being restored.
- Virtual machine guest disk fragmentation.
- Tape drive availability, time to mount tape.
- Tape volume usage. Physical tape volumes can not be shared and only one backup or restore operation can be accessing a tape.
- Number of tape positioning operations.
- Number of incremental backups required.
The Data Protection for VMware Recovery Agent operates in two modes. Refer to Tape configuration guidelines for additional details. The failure behavior for instant restore depends on the mode of operation:
- Tape mode - Instant restore fails when the restore operation is selected.
- Non-tape mode - Instant restore fails when an attempt is made to access data on a tape volume. This failure can occur when the user interface tries to display partition information or when the operation is restoring data. The latter condition occurs only if disk to tape migration is being used, and part of the snapshot data, the partition information, resides on disk and some of the actual snapshot data resides on tape.
If you try to run instant restore in Tape Mode, the following message is displayed:
"Instant Restore is not supported in Tape Mode."
If you try to run instant restore while not in Tape Mode, and the data is located on tape, the following message is displayed:
"The partition structure of the selected disk cannot be parsed. Either the disk is not an MBR-based disk, or it contains partitions of unsupported types."
Original publication date