Challenge

Cause

Solution

• Dell EMC Data Domain OS 6.0 support, including synthetic full backup performances optimizations, backup retention and health check reliability improvements.
• HPE 3PAR 3.2.2 MU3 support, including multiple API interaction improvements for added reliability and performance.
• HPE StoreOnce 3.15.1 support, bringning Instant VM Recovery to Catalyst-based backup repositories.
• Veeam Agent for Linux 1.0 support.
• Veeam Agent for Microsoft Windows 2.0 Public Beta (build 2.0.0.594) support.
• VMware vSAN 6.5 support.
• VMware vSphere 6.5 support (see the next section for details).

• Encrypted VMs support. vSphere 6.5 introduces VMs with encrypted disks. Such VMs can be backed up in hot add and network (NBD) transport modes only, with hot add mode requiring that the backup proxy itself is an encrypted VM. There are no limitations around restores, because backups contain unencrypted VM data (remember to enable backup encryption if that is a concern).
• VMFS6 support. vSphere 6.5 introduces the new VMFS version, and this update allows you to leverage advanced functionality such as Backup from Storage Snapshots and Veeam Explorer for Storage Snapshots for VMs with virtual disks residing on VMFS 6 datastores.
• Virtual hardware version 13 support. vSphere 6.5 introduces the new VM hardware version which increases some configuration maximums and adds ability to add NVMe controllers to a VM. This update adds ability to process such VMs.
• NBD compression. VDDK 6.5 adds ability to enable native NBD traffic compression. To control the compression level, create VMwareNBDCompressionLevel (DWORD) registry value under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key on the backup server with value from 0 (no compression) to 3 (best compression). Please expect significant performance impact from enabling NBD compression unless you’re backing up over slow or busy management network.
• New guest interaction API support. vSphere 6.5 discontinued VIX API that previous Veeam versions leveraged for network-less guest interaction for functionality such as application-aware processing. As part of vSphere 6.5 support effort, we have switched the corresponding functionality to the new vSphere API for guest interaction, so that you can continue using the existing product functionality with vSphere 6.5.
• New VM tag API support. vSphere 6.5 introduces new APIs for programmatic access and management of vSphere tags. With its support by Veeam, you can continue using advanced backup policies based on tags even after you upgrade to vSphere 6.5

• Double-byte support. Double-byte characters are now supported in the virtual infrastructure object names (such as VM name) and Veeam object names (such as job name).
• Export performance improvements. Disk content export from agent-based backups now processes multiple disks in parallel, as opposed to sequentially.

• Performance improvements. Performance of Backup Copy jobs with large number of VMs (hundreds/thousands) was improved in a few times.
• Reliability improvements. Added transfer resume functionality for transparent handling of short network connection outages in certain backup copy process phases where they were not previously used.

• Reliability improvements. Added transfer resume functionality for transparent handling of short network connection outages between a source backup repository and a tape server.

• OES 2015 SP1 support. Open Enterprise Server 2015 SP1 support for file-level recovery from NSS volumes with Trustee Index enabled.

• Side by side restore. Tenants are now able to restore VMs and vApps without overwriting the original object by selecting Keep restore option, in which case the restored object will be created with the _restored suffix as opposed to overwriting the original object (which is still possible by selecting Overwrite restore option).
• Job mapping. Added Set-VBRvCloudOrganizationJobMapping PowerShell cmdlet that allows to map a vCloud backup job and associated guest processing credentials to the existing self-service org record to enable tenants to start using self-service portal functionality for the existing jobs and backups.

• Direct SAN transport improvements. Improved direct SAN transport selection on backup proxies with disabled MPIO, added support for parallel restore through multiple Direct SAN backup proxies.
• Restore without storage profile. The newly added Default policy container in the Select Datastore dialog allows restoring, replicating or migrating virtual machines without their virtual disks inheriting an existing storage profile assigned to the target datastore.
• Restore logic improvements. Full VM restore and Instant VM Recovery operations will now preserve workingDir parameter of the original VM.
• Broker service enhancements. Added experimental Broker Service behavior when it does not try to keep the vSphere infrastructure cache up-to-date continuously. Instead, it will query vSphere infrastructure hierarchy changes only when hierarchy data is requested, but no less often than the specified timeout. Using this mode significantly reduces vCenter Server traffic in large environments while only slightly delaying tasks requiring vSphere hierarchy data. To enable this mode, create VmwareForcedHierarchyUpdatePeriod (DWORD) registry value under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key on the backup server with the value in seconds (900 is the recommended value).

• Asian OS locales support. Veeam Backup & Replication console now supports installation on operating systems with Asian locales, where it was previously unusable due to misplaced UI controls. Update 1 has been tested on all most common Asian locales and validated by local Veeam sales teams of the corresponding regions.
• Experimental high DPI monitors support. We've made the first step towards high resolution monitors support - and while there's still work to be done, the UI is now more usable on DPI settings above 100%. This did require changing the UI font, resizing all dialogs and adjusting placement for some UI controls - so you will notice slightly different UI look after installing the update.

• Fixed an issue which caused monthly Active Full backup schedule to reset to the default one (First Monday of the month) after upgrading to version 9.5.
• Improved reliability of establishing connections to Linux servers by addressing a number of Linux version-specific issues and updating SSH client.
• Improved Direct Restore to Microsoft Azure proxy appliance deployment and management functionality.
• Improved backup placement logic improvements for reversed-incremental backup jobs targeting scale-out backup repository with per-VM backup file chains disabled.
• Addressed an issue with enabling CBT on a VMware VM when backup server is running on certain non-English locales, for example Turkish.
• Addressed a number of minor issues with Veeam Cloud Connect.

More Information

Challenge

Cause

Solution

──────────────────────────────────────────────────────────
Datastore Cleanup
──────────────────────────────────────────────────────────
1. Using datastore browser go to the folder of the replica.
2. Most likely there will be many files, keep in mind that the only files that are required are:
 •VMX
 •VMXF
 •NVRAM
 •VMDK for each disk.
So for example here is a folder precleanup post repair.



We can remove the following files:



Leaving the VMX, VMXF, NVRAM, and the VMDK for each disk. Removing the associated snapshot files that are no longer needed.
 
──────────────────────────────────────────────────────────
Test the replica
──────────────────────────────────────────────────────────
1. Create a snapshot on the replica.
2. Remove the snapshot.
3. If no error occurs, map to the replica in a replication job and see if the job runs successfully.

Challenge

Cause

Solution

1. Start the Netlogon service
2. Change the "Startup type" to "Automatic"
3. Reboot the server

Challenge

Cause

Solution

Challenge

[16.01.2017 16:16:08] <  1380> vdl| Loading VDDK library. Version: 6.5, directory: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_5',
module: 'C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_5', config file: ''
...
[16.01.2017 16:16:08] <  1380> vdl|   [vddk] VixDiskLib: Initialize transport modes.
...
[16.01.2017 16:16:08] <  1380> dsk|   SSLLoadSharedLibraries: Failed to load OpenSSL libraries. libdir is C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_5
[16.01.2017 16:16:08] <  1380> vdl|   [vddk] PANIC: SSLLoadSharedLibraries: Failed to load OpenSSL libraries. libdir is C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_5
[16.01.2017 16:16:08] <  1380> vdl|   [vddk] Backtrace:
[16.01.2017 16:16:08] <  1380> vdl|   WARN|[vddk] Win32 object usage: GDI 4, USER 3
[16.01.2017 16:16:08] <  1380> vdl|   [vddk] CoreDump_CoreDump: faking exception to get context

Cause

Solution

More Information

Challenge

Cause

Solution

Recommended Method:
 
If Veeam Backup & Replication is already installed, apply the latest update.
 
If it is not installed:

1. Choose a new database name during installation. An empty database will be created with this name.
2. Once installation has completed, apply the latest update.
3. Switch from the empty database to the original configuration database using the Configuration Database Connection Settings utility.

1. In Object Explorer, connect to the instance containing the empty database (such as localhost\VEEAMSQL2012).
2. Expand Databases, right-click the empty database, and then click Delete.
3. Confirm the correct database is selected, and then click OK.

 
Do not attempt to revert to a previous release of the software (such as to v8 from v9).

More Information

Challenge

Solution

More Information

Challenge

Solution

• Validate the VMs named "W2008", "W2008R2_DC" and "W2K" in the most recent restore point for the backup "Backup Job 1_imported".
  
  Veeam.Backup.Validator.exe /backup:"Backup Job 1_imported" /vmname:W2008 /vmname:W2008R2_DC /vmname:W2K
   
• Validate all virtual machines in the last restore point with ID 3942788C-B309-4FA4-A111-A4C87B3EC63D.
  
  Veeam.Backup.Validator.exe /backup:3942788C-B309-4FA4-A111-A4C87B3EC63D
   
• Validate a VM with the name "Windows 8" in the restore point created on December 5 2012 for a job named “Backup Job 1".
   
  Veeam.Backup.Validator.exe /backup:"Backup Job 1" /vmname:"Windows 8" /date:05.12.2012
   
• Validate a VM with the name "VM1" in the restore point created around 16:00 on December 5 2012 for a job named "Backup Job 2".

• Validate a VM with the name "VM2" contained in the VBM file located at C:\Backup\VM2_Backup.vbm
  
  Veeam.Backup.Validator.exe /file:"C:\Backup\VM2_Backup.vbm" /vmname:"VM2"
   
• Validate all VMs in VBK-file (backup file).
  
  Veeam.Backup.Validator.exe /file:"C:\Backup\VM2_Backup.vbk"
   
• Validate a VM with the name "VM3" in the most recent restore point of "Backup Job 1" and create an HTML-report.
  
  Veeam.Backup.Validator.exe /backup:"Backup Job 1" /vmname:"VM3" /report:"D:\Reports\Backup_Job_1_Validate_30_09_2014.html"
   
• Validate a VM with the name "VM3" in the most recent restore point of "Backup Job 1" and create XML-report.
  
  Veeam.Backup.Validator.exe /backup:"Backup Job 1" /vmname:"VM3" /report:"D:\Reports\Backup_Job_1_Validate_30_09_2014.xml" /format:xml

More Information

Challenge

Solution

More Information

Challenge

Solution

Microsoft has provided us with options for relocation of databases and their associated transaction logs, as well as tools to perform these operations with ease and reliability in both small and large computing environments. Regardless if you have five servers or a complex infrastructure with hundreds of servers, this process will allow for the seamless movement of databases from any compatible operating system.

Moving a database by using detach-and-attach operations involves the following stages:

1) Detaching the database.
Detaching a database removes it from the instance of the Microsoft SQL Server Database Engine, but leaves the database intact with its data files and transaction log files. To detach the database using SQL Management Studio, you will expand the Instance, right-click on the Database you wish to Detach, click Tasks, and then click Detach. Be sure you have selected the correct database performing the Detach action.

2) Moving the database files to the other server or disk.

The database is traditionally stored in the Data location of the SQL Server program folder on the local disk. Each instance contains a “.#” suffix following the MSSQL folder, the default instance contains a 1, followed by each other instance which increases by 1 respectively. In the data folder, you will see the.mdf (database) and .ldf (transactional logs) files.
Both of these files will need to be relocated to their new server They do not necessarily have to be placed in a similar location - they can be placed anywhere as long as the SQL Server has direct access to the storage. It is actually Microsoft's best practice to place these files on different storage volumes as the transaction log file grows indefinitely, and can become significantly larger than the database file.

3) Attaching the database by specifying the new location of the moved file or files.

Once you have successfully logged into the SQL Server instance where you would like the database to be attached to, you will need to expand the instance, right-click on the Database node, and click Properties. Here, you will find the Attach option. Next you can browse to the new location where our original database files now reside. Only the .mdf files will be displayed in this view. You will have the option to verify the location for the .ldf files after click OK.

Detaching the database




Locating the Database Files



Attaching the database



After your database is moved successfully, make sure to change the following registry keys on your Veeam Backup & Replication server:

HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication\SqlDatabaseName
HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication\SqlInstanceName
HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication\SqlServerName

For 64-bit Installations, the following registry keys should also be updated:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication\SqlDatabaseName
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication\SqlInstanceName
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication\SqlServerName
 

More Information

If the Management Studio is not available, we can perform these same steps using the SQLCMD from the Command Prompt. We will need to use the –d parameters to define the database which we would like to log into locally.



We can then execute this statement to detach the database:

Once it has been successfully detached, we can then manually move the files into their new location.



Then we can perform this command to login to the remote server:

Now, you can perform this task programmatically or without the help of Microsoft SQL Management Studio.

Challenge

Solution

To run a SQL script from a command line, please perform the following steps:

1. Save the script as *.sql file (e.g. script.sql) to local disk
2. Make sure that no jobs are running
3. Run the following command:
       sqlcmd -S <SqlServerName>\<SqlInstanceName> -d <SqlDatabaseName> -i PATHTOSCRIPT\script.sql -o c:\resetresult.txt -I
   
        HKLM\Software\VeeaM\Veeam Backup and Replication\SqlServerName
        HKLM\Software\VeeaM\Veeam Backup and Replication\SqlInstanceName
        HKLM\Software\VeeaM\Veeam Backup and Replication\SqlDatabaseName
   
        If the script needs to be applied to EM database, please use:
        HKLM\Software\VeeaM\Veeam Backup Reporting\SqlServerName
        HKLM\Software\VeeaM\Veeam Backup Reporting\SqlInstanceName
        HKLM\Software\VeeaM\Veeam Backup Reporting\SqlDatabaseName
4. ​Restart the Veeam services

 
You may also run a SQL script from SQL Server Management Studio, right click on your database and choose the “New query” option, insert the text from the file, and click Execute.
 
SQL Server Management Studio can be found here:
https://www.veeam.com/kb1761
 

Challenge

Solution

• This type of restore can be effected adversely by the aforementioned limitations of a Data Domain appliance, and also the type of VM being restored. Highly transactional VMs will require more IOPS from the Data Domain during the Instant Recovery than others. With this in mind you can expect to only be capable of running only a few Instant Recoveries simultaneously. Instant Recovered VMs that are started from a backup file stored on a Data Domain may react or start slowly as the majority of their read operations will be hindered by the Data Domain.
• For VMware users it is highly advised when performing an IR that the user select to have virtual disk updates redirected to a high performance Datastore. This will improve performance by caching written blocks to low latency storage.
• It is advised that if the VM is intended to be made permanent that the VM be migrated to production storage as soon as possible after the Instant Recovery has begun.

• The backup browser may take longer than usual to open if an increment is selected and furthermore by that increments distance from the full restore point.
• Navigating between folders within the Backup Browser may take additional time as each folder’s content must retrieved from the backup file to display it.

• Reverse Incremental performance will be very poor due to its highly random I/O.
  Note: When the Backup Job is configured with a DDBoost repository, Veeam Backup & Replication will prevent Reversed Incremental from being selected by the user.
• Synthetic Full creation will be very slow to a Data Domain, unless using DDBoost.
• Synthetic Full with Transforms are not advised.

• A retention longer than 30 is not advisable as restore operations will diminish in performance.
• The Health Check option may take a very long time as it is performing a read operation.

• Using the Datadomain to store Replica metadata is not advisable.
  Note: Veeam Backup & Replication will prevent the user from selecting a DDBoost repository.

• For CIFS/NFS presented repositories Forward incremental mode with periodic Active full backups is recommended to avoid the rehydration penalty during synthetic operations.
• For DDboost enabled repositories Forward incremental mode with either Active full or Synthetic full backups is recommended. Synthetically produced full backups will generally have the best restore performance and reduce the time VM is run off of a snapshot during the backup job run. However in some environments an Active Full job may run faster.
• Transforming previous backup chains into rollbacks is not advisable for both repository types.
• For forever forward incremental backup and backup copy on DDboost enabled repositories, the option “Defragment and compact full backup file” should be enabled if available. In most cases a weekly schedule is appropriate. This helps to avoid excessive growth of pre-compression data size for the full backup file.

• Support EMC Data Domain Boost 3.0
• Reduced impact of storage fragmentation during restore operations even with enabled parallel processing. This feature allows Veeam to store the VM backup in the dedicated backup chain so that fragmentation ratio will be minimum.
• Reduce the impact of the block size so you may define any block size without impact on the restore process. Veeam will be able to read data granularly so amount of the redundant will be minimum.

1. Launch the creation of a new Repository, on the Type tab select Deduplication storage appliance.
   http://helpcenter.veeam.com/backup/80/vsphere/repository_launch.html
   http://helpcenter.veeam.com/backup/80/vsphere/repository_type.html
2. Select the deduplication storage as EMC Data Domain.
3. On the next tab configure the information to for connecting to the Data Domain appliance.
   Very bottom on this page: http://helpcenter.veeam.com/backup/80/vsphere/repository_server.html
4. On the Repository tab click Browse and select the necessary location from the list of available paths. http://helpcenter.veeam.com/backup/80/vsphere/repository_repository.html
5. The default settings can be taken for the last steps in repository configuration.
   Unless your environment requires you to specify a different vPower NFS Server.

1. Launch the creation of a new Repository, on the Type tab select CIFS
   http://helpcenter.veeam.com/backup/80/vsphere/repository_launch.html
   http://helpcenter.veeam.com/backup/80/vsphere/repository_type.html
2. On the next tab configure the path to which the Repository will write to, and set credentials to access that share.
   Second section named Shared Folder on this page: http://helpcenter.veeam.com/backup/80/vsphere/repository_server.html
3. On the Repository tab within the advanced section, enable “Decompress backup data blocks before storing”
4. The default settings can be taken for the last steps in repository configuration.
   Unless your environment requires you to specify a different vPower NFS Server.

1. Launch the creation of a new Repository, on the Type tab select Linux
   http://helpcenter.veeam.com/backup/80/vsphere/repository_launch.html
   http://helpcenter.veeam.com/backup/80/vsphere/repository_type.html
2. On the next tab select the Linux server that we be connected to. If it is not present in the list select “Add New…”
3. On the Repository tab specify the path on the Linux server that leads to where you mounted the Data Domain via NFS. On this tab in the advanced section enabled “Decompress backup data blocks before storing”.
   http://helpcenter.veeam.com/backup/80/vsphere/repository_repository.html
4. The default settings can be taken for the last steps in repository configuration.
   Unless your environment requires you to specify a different vPower NFS Server.

Challenge

Cause

Solution

Challenge

Solution

• A new server to install VBO on it should be ready and should be at least the same version of Windows or higher
• The following data should be available:
  • Everything under C:\ProgramData\Veeam\Backup365 from the old server (Config data)
  • Your data in the VeeamRepository that holds the O365 backupped data (Repository data). Note: The source and target repository paths should be the same.
  • If the repository is a network share, then the target server should have access to that share
  • If the repository is an iSCSI drive then it is important to disconnect it from the source first to avoid 2 iSCSI initiators issue. Then connect it to the target server.
• These files could come from the original server or restored from a VM-backup through Veeam Backup and Replication.
• Your license file

Additional information:

If you forget to retype your password, you will get the following error when a job tries to run.



Error: [Timestamp] :: Connecting to remote server outlook.office365.com failed with the following error message : [ClientAccessServer=DB5PR0201CA0031,BackEndServer=db3pr04mb219.eurprd04.prod.outlook.com,Req
uestId=4dc5aabf-7349-4a2e-8036-597c2163768f,TimeStamp=1/5/2017 5:57:30 PM] Access Denied For more information, see the about_Remote_Troubleshooting Help topic.

Challenge

Cause

Solution

Challenge

Failed to connect to the Veeam Backup & Replication server:
No connection could be made because the target machine actively refused it <IP>:9392

Cause

Solution

More Information

Challenge

Solution

• Ensure none of the cluster nodes are in maintenance mode, have the cluster service stopped, are powered off, or otherwise not accessible.
• Ensure all nodes within the cluster can communicate with each other.  This can be tested by pinging between the nodes and using wbemtest (see http://www.veeam.com/kb1926) to connect between nodes via WMI.  For wbemtest, the two namespaces you want to ensure can be connected to are root\cimv2 and root\virtualization (root\virtualization\v2 for Windows Server 2012+).
• Make sure the hosts are not added to the Veeam console as standalone hosts if they belong to a cluster.  This prevents changed block tracking data from being replicated to all nodes.  The cluster must be added to the Veeam console.

• Ensure the SMB server is added to the Backup & Replication console.

• Ensure the shares are visible in the Backup & Replication console.

• If Hyper-V checkpoints/snapshots are manually created/deleted (merged) on VMs, you will get a message that changed block tracking is not working.  This is because checkpoint/snapshot operations create an additional file (avhd/avhdx) that has to be tracked.  It is added to the list of files to track (or removed in case of deletion/merge of a snapshot/checkpoint) and the changed block tracking warning should resolve the second job run after the snapshot/checkpoint was created/deleted (merged).

• Select the option to disable changed block tracking on all Hyper-V hosts in the cluster.  To do this, right-click on each host in the cluster, select Manage Volumes and then check the box to disable changed block tracking.

 

• Run sc stop VeeamFCT, in an elevated command prompt, on each Hyper-V host in the cluster to ensure the CBT service is stopped.
• Find, export and then delete the following registry key on all Hyper-V hosts in the cluster:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VeeamFCT\Parameters\CTDB
• Go back to the Manage Volumes for each host and uncheck the disable changed block tracking option.  Try the job after this.  Allow a couple of job runs before ensuring CBT is working.
• If the issue persists, reboot each Hyper-V host in the cluster.  This will typically involve migrating VMs from one host to another and rebooting the host once it does not own any VMs.  Repeat these steps for all Hyper-V hosts in the cluster.

Challenge

Cause

Please confirm you are running version 9.0.0.902 or 9.0.0.1491 prior to installing this update. You can check this under Help | About in Veeam Backup & Replication console.
If you are using partner preview build 9.0.0.773, you must upgrade to GA build 9.0.0.902 first by installing Day 0 Update (Note: Be sure NOT to accidentally install Update 0 on any build other than 9.0.0.773)

After upgrading, your build will be version 9.0.0.1715

Prior to installing this update please reboot the Veeam server to clear any locks on the Veeam services and when the reboot is done, please stop all the Veeam jobs and services before applying the update.

Ensure that Veeam service account has the db_owner role on the Veeam configuration database, so that the required database updates can be made during the first service start up after update. Additionally, either give Veeam service account the sysadmin role on the SQL Server hosting the configuration database, or just the right to view system table content (GRANT VIEW SERVER STATE TO "DOMAIN\ACCOUNT"). All of the above-mentioned roles and rights can be revoked after update is completed.

After installing the update, during the first start of the Veeam Backup Service, required modifications will be made to the configuration database automatically to optimize its performance. These modifications may take up to 10 minutes to complete. Please do not reboot the Veeam server, or attempt to stop the service during this operation. If there is concern regarding the time that the Veeam Backup Service takes to start after upgrade, please contact Veeam Customer Support.

Once Veeam Backup Service starts, please open the console and allow Veeam Backup & Replication to update its remote components.

If you have Veeam Enterprise Manager installed on a separate server, you need to install the update on it as well.

 

Solution

• Cisco HyperFlex HX-Series support for Direct NFS backup mode.
• EMC Unity support for Backup from Storage Snapshots and Veeam Explorer for Storage Snapshots functionality.
• EMC Data Domain DD OS 5.7 support for DD Boost integration.
• ExaGrid 4.8.0.351.P28 is now the minimal ExaGrid firmware version supported.
• NetApp Data ONTAP 8.3.2 support.
• VMware vCloud Director 8.10 support.
• VMware VSAN 6.2 support.

• Backported a number of isolated Enterprise Scalability enhancements from 9.5 code branch to improve transaction log backup, tape backup and user interface performance.
• Updated OpenSSH client to version 7.2 to enable out of the box support for modern Linux distributions.
• Improved iSCSI target performance (iSCSI target is used to mount backup remotely in certain file-level and item-level recovery scenarios).
• iSCSI mount operations are now retried automatically to workaround occasion “The device is not ready” errors which happen when mount operation takes too long. By default, the mount is retried 6 times every 10 seconds. To change the number of retries, create IscsiMountFsCheckRetriesCount (DWORD) registry value under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key on the backup server.

• To reduce backup server load, Backup Copy jobs targeting shared folder or deduplicating appliance backed repositories with the gateway server setting set to Automatic selection will now start the data mover on the mount server associated with the backup repository (as opposed to the backup server). In cases when the mount server is unavailable, the data mover will be started on the backup server as before.
• Backup Copy performance should now be more consistent due to preserving backup files cache when the job is switching to idle mode.
• Minor reliability improvements in GFS full backup creation algorithm.

• Find-VBRHvEntity cmdlet performance has been improved significantly when used against Hyper-V cluster.
• Backup infrastructure resource scheduler should schedule Guest Interaction Proxy resource dramatically faster in large infrastructures (for example, 5 seconds instead of 15 minutes).

• Improved performance and reduced resource consumption of Microsoft SQL Server transaction log backups.

• Added ability to force CAS server for Veeam Explorer for Microsoft Exchange (instead of automatically detecting one) via DefaultCASServer (DWORD) registry value under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key on the backup server.
• Added ability to change the order of Exchange autodiscovery policies for Veeam Explorer for Exchange (support only setting).

• Added ability to restore Oracle databases while preserving certain parameters which are critical to RMAN in scenarios such as database name change via new <Parameter Name="diagnostic_dest" StartupPath="true"/> parameter in PFileParameters.xml file of Veeam Explorer for Oracle.

• Support for Planned Failover functionality with cloud replicas. You can now perform planned failover to achieve zero data loss, for example when a natural disaster can be predicted in advance.

• Update 2 introduces important changes and fixes around rental licensing, including a pilot functionality of usage reporting directly from the user interface. For additional information, as well as the list of other service provider specific enhancements and bug fixes included in this update, please refer to the issue tracking topic in the private VCSP forum. If you are VCSP but don't have access, please apply to Cloud & Service Providers group using Veeam forum's User Control Panel.

More Information

Challenge

Solution

• Only VMFS type datastores are supported.
• The volume for each datastore containing a VM that is intended to be backed up over Direct-SAN must be presented to the Backup Proxy.
• The volume must appear in Disk Management within the Backup Proxy Server.

• As the number of volumes presented to the Backup Proxy increases the delay for starting of the VM task may increase. This is due to the job scanning each volume. This can be mitigated by manually specifying in the Backup Proxy setting which datastores are connected.
• Under certain circumstances volumes may not be automatically discovered and necessitate manually specifying which datastores are connected in the Backup Proxy settings.

More Information

• http://helpcenter.veeam.com/backup/70/vsphere/direct_san_access.html
• How to setup Direct-SAN Access http://www.veeam.com/kb1446
• Enabling MPIO breaks Direct-SAN mode http://www.veeam.com/kb1107
• Direct-SAN stops working http://www.veeam.com/kb1115
• http://www.veeam.com/blog/direct-san-access-tips-for-iscsi-vmfs-volumes-and-backup-proxies.html

Challenge

Cause

Solution

More Information