Veeam Backup & Replication Patch 4 Release Notes
Please confirm you are running version 188.8.131.520, 184.108.40.2065, 220.127.116.114, 18.104.22.1681, 22.214.171.1243, 126.96.36.1999 or 188.8.131.520 prior to installing this patch. You can check this under Help | About in Veeam Backup & Replication console.
After upgrading, your build will be version 184.108.40.2061
New Features and Enhancements
VMware Virtual SAN (VSAN)
- In addition to adding basic support (as provided by other vendors), the intelligent load-balancing engine was enhanced to account for VSAN specifics. As the result, for each VM the job will pick backup proxy running on VSAN cluster node with most of the virtual disks’ data available locally. This significantly reduces backup traffic on VSAN cluster network, resulting in minimum possible impact on production environment from backup activities.
Microsoft SQL Server 2014
- Added support for Microsoft SQL Server 2014 both as the protected guest workload (including application-aware processing functionality), and the back-end database for backup and Enterprise Manager servers.
License key auto update
- Added automated license key update option to the License Information dialog. With auto-update enabled, the product will check Veeam licensing server periodically for an updated license key, and download and install the key automatically as soon as it becomes available. This feature is particularly useful to the Service Providers and subscription-based customers, and it removes the need to download and install the license key manually each time when the license extension is purchased.
- The maximum allowed amount of restore points in the Backup Copy job has been increased to 999.
- Backup Copy will now resume the transfer after network connection drop to a Linux-based backup repository.
- Backup Copy jobs should no longer report errors during the days when source backup jobs are not scheduled to run - for example, during the weekend.
- Added support for certain Hardware VSS Providers that previously could not be detected by the storage rescan process, and as such could not be used by the jobs.
- Jobs will now retry failed snapshot creation when another shadow copy of the same volume is already in progress, instead of immediately failing to process a VM.
- Under certain circumstances, the target data mover may crash with the "Cannot allocate memory for an array" error while processing a backup job with WAN storage optimization setting.
- Increased maximum amount of open files for Linux data mover to improve backup reliability in cases with a very large amount of concurrent tasks hitting the same repository.
- If the same ESX(i) host is added to Managed Servers both as a part of the vCenter, and as a standalone host, the jobs fail to remove VM snapshots correctly.
- Replication job does not truncate Microsoft Exchange transaction logs when the corresponding setting is set to "Truncate logs on successful backup only".
- Setting EnableSameHostHotaddMode registry value (introduced in Patch #3) to 1 causes replication jobs to fail with the "Object reference not set to an instance of an object" error.
- If you clone replica VM with vSphere, and start the replication job, the target VM will be selected randomly between the two VMs.
- Issues introduced with Windows Server 2012 R2 Update (April 2014 rollup), see KB1863 for more info.
- Very large amount of parallel tasks may cause in significant delays (up to a few minutes) between assigning required backup infrastructure resources to the job, and the job actually starting to leverage those resources.
- Replication jobs do not truncate Microsoft Exchange transaction logs regardless of the corresponding settings state.
- Processing of virtual machines with long dash symbol in the file name fails with the "The system cannot find the path specified.\n\nFailed to open file [C:\ClusterStorage\FOLDER\GUID.xml] in readonly mode. (System.Runtime.InteropServices.COMException)" error.
- Parallel snapshots of SMB3 share may fail with the "Failed to add volume to the VSS snapshot set. Another shadow copy creation is already in progress. Wait a few moments and try again" error.
- Restoring a VM to localized Hyper-V cluster creates duplicate cluster resources remaining in the Starting state in Failover Cluster Manager.
- During full VM restore and SureBackup job, Domain Controllers may spend longer than required in the DSRM mode (up to 10 minutes – until the corresponding timeout expires), thus unnecessarily delaying DC recovery.
- Increased timeouts for network-less application aware processing of vSphere guests to improve the chance of processing completing successfully.
- Backup Copy configured with multiple backup jobs as the source does not include VMs which are excluded in one source backup job, but included in another.
- Health Check process continuously fails with the "Timed out waiting for the backup repository resource to become available for backup integrity check" error during the periods when the Backup Copy job is restricted from using network bandwidth.
- Backup Copy is incorrectly marked as failed despite completing successfully when source or target WAN accelerator becomes unavailable (for example, due to the network issue and reboot) during the period when Backup Copy job is waiting for its availability.
Backup from Storage Snapshots
- Disabling failover to network processing mode on a backup proxy causes intelligent load balancing not to assign the backup proxy to jobs running with storage snapshots integration enabled.
- Under certain circumstances, backup from 3PAR volumes may fail with the "LUN is already taken for set ESXs" error.
- The presence of null byte in tape changer serial number causes configuration backup to fail.
- Certain files are skipped with the File Copy job with the "Cannot copy a symbolic link of type Veeam.Backup.Core.CLocalFileItem into a directory of type Veeam.Backup.Core.CRemoteWinFolder" error, however the job reports success. For example, this may happen when copying files from volumes with Windows Server 2012 deduplication enabled.
- File Copy job fails when attempting with the "Client error: boost::filesystem::remove: Access is denied" error when attempting to overwrite read-only file on the destination Windows server. The remaining files are not copied.
Native File Level Recovery
- Starting file level recovery from the Restore wizard fails with the "Object reference not set to an instance of an object" error when SAN snapshots is picked as the recovery source. Starting the same process from SAN infrastructure tab does not have this issue.
- In rare scenarios, file level recovery is unable to parse LDM contents of the virtual disk. As the result, Backup Browser opens empty, without any volumes mounted.
- Restoring to original location for volumes which are mounted to a folder (as opposed to a drive letter) fails when such volumes reside on GPT partition or dynamic disk.
- Folder permissions, group and owner IDs are not preserved when restoring a folder with "Preserve permissions and ownership" check box selected.
- Multi-OS FLR fails with the "The file specified is not a virtual disk" error on replica VMs with VMDK larger than 2TB in size.
- Depending on where the file is placed on the tape, restore process may not calculate the file size correctly, resulting in corrupted file restored from good backup.
- File to Tape job fails to process files with full path of exactly 260 symbols long with the "The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters" error. Files with full path longer or shorter than 260 symbols are processed normally.
- Restoring a very large file from tape may fail with the "Value was either too large or too small for an Int64" error.
- Restoring a VM from tape may fail with the "Unable to read tape metadata" error.
- VMs and Templates View of the virtual infrastructure Browse dialog, and Category View on the Virtual Machines tab do not show vSphere vApps.
- Sending email notifications fails with the "Key not valid for use in specified state" error if SMTP credentials were entered by a user account other than Veeam Backup Service account.
Veeam Explorer for Microsoft Exchange
- Opening mailbox database may occasionally fail with the "The process cannot access the file 'C:\PATH\ese.dll' because it is being used by another process" error.
- Mounting mailbox database or transaction log volumes fails with the "Exchange logs cannot be replayed, block size mismatch" error from 512-byte emulation (512e) disks.
- In rare scenarios, opening a mailbox from German localized Microsoft Exchange deployment fails with the "JetError -1404, JET_errIndexNotFound, No such index" error.
Veeam Explorer for Microsoft SharePoint
- SharePoint restore wizard fails with the "Object reference not set to an instance of an object" error if actual SharePoint configuration does not match the one collected with application-aware processing logic during the backup job.
- Increased source WAN accelerator digests retention to 2 months to avoid digests recalculation every week.
Pilot Patch #4 (build 220.127.116.110)
The generally available version of Patch #4 (build 18.104.22.1681) also addresses the following issue reported during pilot patch deployments:
- Tape inventory fails on certain tape drives with the following error: "Tape fatal error. No more data is on the tape"
This patch also contains all fixes from Patch 1, R2 update and Patch 3
After installing the patch, please start the Veeam services, open the console and allow Veeam B&R to update its components.
To obtain the patch, please click here (you need to be logged in to download the patch).