Challenge

Solution

• Issue description, impact on your system and business operations, issue severity, and the exact text of error messages and diagnostic details.
• Steps to reproduce the problem, known workarounds
• Contact number where you can be reached
• Best time to reach you, and contact method (i.e. email/phone)

 
1.  Go to http://cp.veeam.com

2.  Click [Sign in to Open a case]



3.  Enter your credentials, and click Sign In

4.  Click Open Case



5.  On next page you will fill in details regarding the issue. Please remember to include the exact error message that is occurring. Including screen shots can often help expedite resolution.




6. After clicking next you will be taken to a page listing 3 KB articles that may be related to your issue.

Click 

7.  On the next page you will be asked to add attachments to your case. It is on this page that you will attach the logs related to the issue, and any screenshots you have gathered.

If the log package is large there will be an upload completion percentage listed in the status of the browser.



8.  On the last page of case creation you will have an opportunity to review all details provided and provide specific contact details.
 
After you have created a case you will be contacted within the time set forth in the SLA agreement for the severity you specified.

More Information

Challenge

Cause

Solution

Challenge

Cause

Solution

More Information

Challenge

Solution

select * from product_component_version;

Challenge

Solution

More Information

Challenge

Solution

 

For Replica seeding in Veeam Backup & Replication 8 please review:
 
VMware
http://helpcenter.veeam.com/backup/80/vsphere/index.html?replica_seeding_vm.html
 
Hyper-V
http://helpcenter.veeam.com/backup/80/hyperv/index.html?replica_seeding_hv.html
 
For replica seeding in Veeam Backup & Replication 7 or older please review the following.

To manually seed a Replica:
 
Part 1: Restoring the VM to the Destination


1.  Go to Backups and select the job in your target repository(Check the Repository column). Expand the backup set via the chevron to the left of the backup set name. Right click the VM you want to make into a replica and select 'Restore Entire VM'.




2.  On the Restore Mode tab select ‘Restore to a new location or with different settings’.



3.  On the same tab click ‘Pick Proxy to Use’.



4.  Pick the appropriate proxy to process this restore job. Pick the proxy on the TARGET side.



5.  On the ‘Host’ tab, select the target host you want the replica to reside on.



6.  On the ‘Resource Pool’ tab, select whichever resource pool, if any, you want the replica to use.

7.  On the ‘Datastore’ tab, by default, original datastore and disktype are selected for each VM. You can change them by selecting desired VM file, and clicking Datastore or Disk Type (at the bottom).

8.  On the ‘Folder’ tab, by default, the original VM folder is selected as restore destination for each VM. You can change folder by selecting the desired VM and clicking Folder (at the bottom). You can also change the VM name by highlighting the VM and then clicking “Name…” at the bottom. It is suggested to add the suffix “_replica”.

9.  On the ‘Network’  tab, if you are restoring to a different location, specify how the original location’s network maps to the new location’s network.

10.  From here you can click through to finish, make sure NOT to check "Power on VM after restoring", and hit [Finish].


Part 2: Mapping to the restored VM


1.  When the restore completes edit the replication job.

2.  Mark the ‘Enable Low Connection Bandwidth’ (fig. 1) in the Name tab.

3.  On the Destination tab make sure the settings match the present location of the restored VM that will become the replica.

4.  On the ‘Seeding’ (fig.2) tab check ‘Map replicas to existing VMs’.

5.  Then highlight your production VM, hit ‘Edit’, and map it to the VM you restored on the TARGET side in Part 1 of this KB. Once you have mapped the restored VM (now replica) to the original VM, next through until you have completed the rest of the job settings and select Finish.

6.  Be sure to run the job and test it.

Challenge

Cause

Solution

Please be aware that as an alternative to performing the steps below, you may first attempt to clone the faulty replica within VMware, if it succeeds map the Replication job to the clone of the replica.
 
 
Note: Prior to beginning:
•Stop all replication jobs to target location of the replica in question.
•Manually check each target side proxy for stuck replica hotadded disks. (Consider switching the target proxies to use Network transport mode to prevent this if it becomes a problem). See KB1775 for details.
 
──────────────────────────────────────────────────────────
Gather Information
──────────────────────────────────────────────────────────
 
1. Edit the Replica
2. Note what disk files correlate to each SCSI ID.
      Example:
      [Datastore1] DC01_replica\DC01-00000023.vmdk     on SCSI0:0
      [Datastore1] DC01_replica\DC01_1-00000023.vmdk on SCSI0:1
      [Datastore2] DC01_replica\DC01-00000023.vmdk     on SCSI0:2
 
──────────────────────────────────────────────────────────
Prepare the Replica
──────────────────────────────────────────────────────────
1. Open the Snapshot manager and starting with the oldest snapshot delete the snapshots one at a time. The intention here is to get as much new information in to the base disks as possible. At some point there will be a snapshot that will not remove.
2. If there are any snapshots left in the snapshot manager try using the Delete All option in snapshot manager.
3. Use the consolidate function to consolidate any orphaned snapshots.
 
──────────────────────────────────────────────────────────
Preparing Veeam Backup & Replication
──────────────────────────────────────────────────────────
Within the Veeam console under Replicas find the replica that you will be repair and right-click it, from the context menu choose “Remove from replicas…”
 
After you use the “Remove from replicas…” function it will remove the VM from the Replication job.
You will have to manually add the VM back to the replication job.
 
──────────────────────────────────────────────────────────
Detach Snapshot Disks and Attach Base Disks
──────────────────────────────────────────────────────────
1. Edit the replica, and select each of the disks and click remove. It will put a strikethrough the drive and show the word (removing).
2. After selecting all the disks for removal, press OK.
3. Edit the replica again, now reattach the base disks to the replica, choose to add an existing disk and then navigate to the location of the base disks for the replica. Attach them to the same SCSI nodes that were noted earlier.
 
──────────────────────────────────────────────────────────
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

Challenge

Cause

Solution

More Information

Challenge

Cause

Solution

To Move Metadata for All Replicas in a Repository

To Move Metadata for Specific Replicas

Challenge

Cause

• Slow repository read performance, especially due to deduplication storage "rehydrating" deduped/compressed backup data.
• Slow network link between host and vPower server due to congestion, setting of 100Mb/s on NIC, or other infrastructure issues.
• Poor performance of the vPower NFS server.

Solution

Increase Timeouts

Increase the timeouts below to several times the default value. Although you can increase the timeouts beyond these limits, it is usually better to investigate performance first if you are performing a test or low-priority restore. In an emergency, increase the timeouts as high as necessary, or create a severity 1 case with Veeam Support for assistance in finding a workaround.

Open Regedit on the Veeam Backup Server and create the following values if they do not already exist. All values are created in key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication. All values are in decimal. Make sure no jobs or restore are running, then restart the Veeam Backup Service to apply these changes.

remotingTimeout:
DWORD: remotingTimeout
Default value: 900 (seconds)
Suggested value: 7200
Description: Applicable in all cases.

IrMountLeaseTimeOut:
DWORD: IrMountLeaseTimeOut
Default value: 30 (minutes)
Suggested value: 90
Description: Applies to mounting VMware virtual disks from backup or storage snapshot for instant VM recovery, except when restoring to vCloud Director.

IrVcdMountLeaseTimeOut:
DWORD: IrVcdMountLeaseTimeOut
Default value: 45 (minutes)
Suggested value: 120
Description: Applies to mounting VMware virtual disks from backup for instant VM recovery to vCloud Director.

Improve Performance

The most common cause of these errors is slow read performance from the backup repository. Deduplicating storage is not recommended as a back-end for vPower-based restores. Where possible, optimize storage devices for random read I/O of large blocks (typically 256 KB – 512KB with default settings, or 4 MB for backups on deduplicating storage; your use case may vary). A simple benchmark is described in KB2014.

As a workaround, or to verify that storage performance is the cause of the timeout, try temporarily moving the backup files to faster storage.

Where possible, make sure the vPower NFS server, the repository, and the destination ESXi host for the restore are all located at the same site. That is, avoid creating unnecessary bottlenecks by sending restore traffic over the WAN.

Additional performance troubleshooting:

• Depending on the underlying infrastructure, there can be significant performance differences between running the vPower NFS service from a VM or from a physical machine. For example, try using a VM located on the same ESXi host as the virtual lab.
• Heavily fragmented full backup files can reduce restore performance. Schedule compact operations to reduce fragmentation.
• Where applicable, test throughput of the network connections between the repository and vPower NFS server, and between the vPower NFS server and the ESXi host.
• Investigate CPU and memory usage of the repository and vPower servers.

More Information

Challenge

Product Information:

Product Family: iSAN SAN Storage
Status: Veeam Ready - Repository
Classification Description: Verified backup storage that supports all Veeam backup and restore features.

Solution

Product Details:

Model number: iSAN 6140
Number of Drives: 12
Drive type: Samsung SSD 850 EVO mSATA
Firmware version: 6.19xg11
Additional support: iSAN models at or above the model referenced in this article with an equal or greater number of drives are also supported.
General product family overview: Cybernetics' revolutionary iSAN® 6140 SSD model provides a large 40TB capacity of SSD storage in a small, space-saving, and energy-saving architecture.

Veeam Details:

Veeam Build Number: 9.0.0.1715
Veeam Settings:

• Repository Type: Windows
• Deduplication: OFF
• Compression: Optimal
• Storage Optimization: Local Target
• Per-VM Backup Files: OFF
• Decompress before storing: OFF
• Align backup file blocks: OFF

More Information

Company Information:

Company name: Cybernetics
Company overview: Founded in 1978 and headquartered in Yorktown, Virginia, Cybernetics is a privately held corporation specializing in the design and manufacture of high performance disk, tape, and virtual tape storage solutions. Our product line features cutting edge technologies which have been rigorously tested to deliver seamless compatibility and solid reliability, along with innovative- and exclusive- features that provide greater functionality, data accessibility, and return on investment than any other storage solutions provider can match.

Challenge

Product Information: 

Product Family: K-Block 
Status: Veeam Ready - Repository 
Classification Description: Verified backup storage that supports all Veeam backup and restore features.   

Solution

Product Details: 

Model number: 2 K-Blocks, each with 1 disk shelf 
Number of Drives: 48 – 960 GB 
Drive type: SSD 
Firmware version: 5.8.0.64  
Additional support: Any K-Block, SSD-based array meeting or exceeding the hardware and software configuration outlined. 
General product family overview: Kaminario K2 — a very innovative all-flash storage solution. It is unique in its capability to deliver predictability in the face of business uncertainty — predictable pricing, predictable scalability, predictable performance, predictable simplicity. Predictability is extremely critical in today’s dynamic, on-demand world. 

Veeam Details: 

Veeam Build Number: 9.0.0.1715
Veeam Settings:  

• Repository Type: Windows 
• Deduplication: OFF 
• Compression: Dedupe-Friendly 
• Storage Optimization: WAN Target 
• Per-VM Backup Files: ON 
• Decompress before storing: OFF  
• Align backup file blocks: OFF

More Information

Company Information: 

Company name: Kaminario 
Company overview:  Kaminario is a leading all-flash storage company that is redefining the future of modern data centers. Its unique solution enables businesses to succeed in today’s on-demand world, and prepares them to seamlessly handle tomorrow’s innovations. Hundreds of customers rely on the Kaminario K2 all-flash array to power their mission critical applications and safeguard their digital ecosystem. Headquartered in Needham, MA, Kaminario works with an extensive network of resellers and distributors, globally. For more information, please visit www.kaminario.com.

Challenge

Product Information: 

Product Family: NEC HYDRAstor 
Status: Veeam Ready - Repository 
Classification Description: Verified backup storage that supports all Veeam backup and restore features. 

Solution

Product Details: 

Model number: HS8-5002S-288 
Number of Drives: 48 
Drive type: SATA 
Firmware version: V5.0.3 (System Version) 
Additional support: Available on HYDRAstor HS8-5002S-288 or higher tier models with an equal or greater number of drives using the firmware version listed. 
General product family overview: NEC's HYDRAstor technology delivers high performance, capacity-optimized and highly available storage solutions, supporting backup, long-term data archive, and DR solutions for all enterprises. HYDRAstor is a scale-out grid storage platform built on top of a scalable back-end object storage with inline global deduplication, solving present and future challenges for long-term data. HYDRAstor’s scale-out grid architecture provides scalability of both performance and capacity, capacity optimization, advanced erasure-coded data protection, and high availability with node-level resiliency. HYDRAstor can be further expanded and refreshed online with no data migration by incorporating newer generation hardware into the same grid system, maximizing investment protection. 

Veeam Details: 

Veeam Build Number: v9.x
Veeam Settings:  

• Repository Type: Shared Folder 
• Deduplication: No 
• Compression: None 
• Storage Optimization: Local Target 
• Per-VM Backup Files: Yes 
• Decompress before storing: Yes 
• Align backup file blocks: No 

More Information

Company Information: 

Company name: NEC Corporation of America 
Company overview: Established July 1, 2006, from the combined operations of NEC America, NEC Solutions America and NEC USA, NEC Corporation of America (NEC) is a leading technology integrator providing solutions that improve the way people work and communicate. NEC delivers integrated Solutions for Society that are aligned with our customers' priorities to create new value for people, businesses and society, with a special focus on safety, security and efficiency. We deliver one of the industry's strongest and most innovative portfolios of communications, analytics, security, biometrics and technology solutions that unleash customers’ productivity potential. Through these solutions, NEC combines its best-in-class solutions and technology, and leverages a robust partner ecosystem to solve today's most complex business problems.   

NEC Corporation of America is a wholly-owned subsidiary of NEC Corporation, a global technology leader with a presence in 160 countries and $25 billion in revenues. 

Challenge

Product Information: 

Product Family: Scality RING 
Status: Veeam Ready - Archive 
Classification Description: Verified disk archive storage that can be used as a Backup Copy target.  Synthetic full backups, granular restores, and vPower features may not provide sufficient performance or be supported 

Solution

Product Details: 

Model number: Scality RING 
Number of Drives: 48 SATA, 6 SSD per node (6 nodes) 
Drive type: SATA and SSD 
Firmware version: RING Software Version 5.1.7 
Additional support: Configurations with 6 or more nodes with at least 48 SATA drives and 6 SSD’s per node 
General product family overview: The Scality RING is software that turns any standard x86 servers into web-scale storage. With the RING, you can store any amount of data, of any type, with incredible efficiency and 100% reliability, guaranteed—all while reducing costs by as much as 90% over legacy systems. 

Veeam Details: 

Veeam Build Number: 9.0.0.1715 
Veeam Settings:  

• Repository Type: SMB Shared Folder 
• Deduplication: Yes 
• Compression: Optimal 
• Storage Optimization: Local Target (16TB+ backup files)  
• Per-VM Backup Files: Yes 
• Decompress before storing: No  
• Align backup file blocks: No

More Information

Company Information: 

Company name: Scality  
Company overview: Scality, the world leader in object and cloud storage, bridges the gap between application vendors and industry standard hardware providers to meet your cost-effective storage scale, durability, cloud and performance requirements.

Challenge

Cause

Solution

Changing the Credentials Record

Example 1: Shared folder on a Windows file server

1. In an Explorer window, right-click the shared folder (E:\share) and select Properties;
2. From the Sharing tab, click Advanced Sharing;
3. Click Permissions;
4. Select Everyone and note the current permissions;
5. Deny all permissions, click OK, then in the Advanced Sharing window click Apply.
6. In the Veeam console, in the Files and Folders page of the File to Tape job settings, click Next. A message box will appear;
7. Change the permissions for \\fs1\share to match what was noted in step 4;
8. In the Veeam console, choose a credentials record in the message box, or add a new record.

Example 2: Shared file on a domain-joined NAS

1. Open an Explorer window to \\nas01\share\folder1;
2. Right-click file1.txt and select Properties;
3. From the Security tab, click Edit;
4. Click Add;
5. Click Object Types, and make sure Computers is checked. Click OK;
6. Type VEEAMBK01$ and click OK;
7. Deny all permissions to the VEEAMBK computer account, and click Apply;
8. In the Veeam console, in the Files and Folders page of the File to Tape job settings, click Next. A message box will appear;
9. Return the file permissions for file1.txt to their prior state by selecting the VEEAMBK computer account and clicking Remove, then Apply;
10. In the Veeam console, choose a credentials record in the message box, or add a new record.

Deleting the Shared Folder Object

1. Backup the Veeam database. (http://www.veeam.com/kb1471);
2. Verify the record to be deleted by running the following query against the configuration database (VeeamBackup by default);
   
   SELECT * FROM [backup.model.mrulist]
3. Run the following query, changing <share path> to match the record to be deleted.
   
   DELETE FROM [backup.model.mrulist] WHERE url = ‘<share path>’

Identifying the Credentials Record Associated with the Share

Additional Considerations

Challenge

When running a SureBackup Job, you receive this error in the summary: "Error: Mount with leaseId 'xxx-xxx-xxx-xxx-xxx-xxx' already activated."

When the performance of the NFS datastore is slower than expected, SureBackup job fails because the mount lease timeout expired.  This is the timeout set for how long to wait for NFS mount to complete its operation.
 

Cause

Surebackup will fail with this message if certain operations time out. Veeam Backup & Replication implements timeouts for most operations to protect against hangs. However, even when no process is hung, timeouts may occur due to significant performance problems or an unusual use case.
Typically this error occurs due to slow performance of the vPower NFS datastore. Possible causes of the slow performance:

• Slow repository read performance, especially due to deduplication storage "rehydrating" deduped/compressed backup data.
• Slow network link between host and vPower server due to congestion, setting of 100Mb/s on a NIC, or other infrastructure issues.
• Poor performance of the vPower NFS server

Solution

Increase Timeouts

Open Regedit on the Veeam Backup Server and create the following keys and values if they do not already exist. Increase the timeouts to 2x or 3x the default value. Although you can increase the timeouts beyond these limits, it is usually better to investigate performance first. Make sure no jobs or restore are running, then restart the Veeam Backup Service to apply these changes.

MountLeaseTimeOut:

Key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\SureBackup
DWORD: MountLeaseTimeOut
Default value: 600 (seconds)
Suggested value: 1800

remotingTimeout:

Key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
DWORD: remotingTimeout
Default value: 900 (seconds)
Suggested value: 1800

Improve Performance

The most common cause of this error is slow read performance from the backup repository. Deduplicating storage is not recommended as a back-end for Surebackup. If you must verify backups from deduplicating storage, it may be necessary to increase the above timeouts to several hours, especially if there are any large (multi-TB) VM disks. Where possible, optimize storage devices for random read I/O of large blocks (typically 256 KB – 512KB with default settings, or 4 MB for backups on deduplicating storage; your use case may vary). A simple benchmark is described in KB2014.

As a workaround, or to verify that storage performance is the cause of the timeout, try temporarily moving the backup files to faster storage.

Additional performance troubleshooting:

• If performing verification of offsite backups, make sure the virtual lab and vPower NFS server are located in the same site as the repository.
• Depending on the underlying infrastructure, there can be significant performance differences between running the vPower NFS service from a VM or from a physical machine. For example, try using a VM located on the same ESXi host as the virtual lab.
• Heavily fragmented full backup files can reduce restore performance. Schedule compact operations to reduce fragmentation.
• Where applicable, test throughput of the network connections between the repository and vPower NFS server, and between the vPower NFS server and the ESXi host.
• Investigate CPU and memory usage of the repository and vPower servers.

More Information

User Guide:
Overview of vPower NFS Service
Configuring vPower server
The remotingTimeout setting affects all processes and services communicating with the Veeam Backup Service. It can cause failures of any vPower NFS mount. In some cases, communication failures will be retried, so an operation may not fail until this timeout has occurred multiple times.
Consider that from a networking and vSphere configuration perspective there is little difference between vPower and any other NFS datastore.
VMware Technical Paper: Best Practices for Running vSphere on NFS Storage

Challenge

Cause

1. Too many jobs are running at a time for the number of concurrent tasks set across all proxies available to the job that failed.
2. Proxies may be unavailable (Shutdown, not connected to the network, etc.).
3. The existing set of backup proxies does not have enough resources to process the backup jobs in a timely manner.
4. The virtual machine might be being processed by another job
5. New LUNs created and/or VMs migrated to new LUNs

Solution

1. Stagger your backup jobs and replication jobs at different time slots so that a job isn’t waiting on available proxies when it starts. (Ex. Instead of scheduling your jobs to all start at 8:00PM, start one job at 8:00, another at 8:30, and another at 9:00.)
2. Increase the number of concurrent tasks allowed on your proxies. However, keep in mind the system requirements.  See How to set max concurrent tasks. If your backup proxy is a virtual machine, you should increase the amount of CPU and RAM available to the proxy.

• VERSION 7.X through to VERSION 9.X with default job settings requires 1 CPU core and 200 MB RAM per task that you wish the proxy to run at a time, plus 2 GB RAM for the operating system and Veeam services. Although only 200 MB per task is required, a 2GB per CPU core ratio is recommended for best performance and reliability. (2 Tasks at once = 2 CPU cores and 2.4 GB RAM required, 4GB recommended)
  • If using high compression, 2 cores per concurrent task are required.
  • Memory usage may be greater than the minimum system requirements. If memory usage on the proxy frequently exceeds 80%, consider increasing the available memory.
  • VERSION 7.X through to 9.X runs tasks in parallel, but can run sequentially with the parallel processing option disabled. Processing multiple disks on one VM will reserve multiple concurrent tasks. See Enabling Parallel Processing.
• Remember to not under-allocate your Veeam Backup server, especially if it is your backup proxy.  If the configuration database is installed on a local SQL instance (the default installation), then SQL Express should be allocated 1 CPU core and 1-1.5 GB RAM when planning your resource usage. A full version of SQL may use significantly more resources in a large environment. 500 MB RAM per concurrent task is recommended for the Veeam Backup services and the SQL server combined; 4 GB minimum.

3. Deploy additional backup proxies from within “Backup Infrastructure->Backup Proxies”.
   • This can be a physical server, an existing VM, or a newly-deployed VM. If adding existing virtual machines, bear in mind that Changed Block tracking will be disabled when backing up these VMs, which can substantially increase processing time.
4. Make sure that your backup job or replication job is selecting the correct proxies. Choose “Automatic selection” to have Veeam try to choose the best proxy from your available pool of proxy machines, or choose a specific set of proxies. The latter can be useful if you have set up a specific proxy with a large amount of resources to be used on a large backup or replication job.

• However, be careful as a backup job set to use a single proxy can fail with the above error if that proxy is unavailable. It might be beneficial to choose more than one if manually specifying proxies.
• Also note that automatic proxy selection will detect available transport modes for each proxy, and then wait for a proxy with the best available transport mode. The modes are ranked as follows: Direct SAN (SAN) > Virtual Appliance (HOTADD) > Network (NBD). For example, if you have a virtual machine proxy on each of three hosts, and all of your VMs are on local storage, a job set to automatic will wait for the proxy that has access to the local storage (HOTADD) rather than use an available proxy that can only read the disk over the network (NBD). For more information, see Transport Modes.

5. Investigate backup job performance. If specific jobs are taking longer to process than normal, check for warnings, compare the bottleneck statistics to previous jobs sessions, and try to isolate the problem to a specific proxy, repository, host, or datastore.
6. Present newly added LUNs to the Veeam Server

More Information

Challenge

Cause

Solution

1. Partner has submitted a spreadsheet containing monthly usage report information to 2 different email addresses, and the email was not processed by the aggregator, or the aggregator email address is incorrect.

1. Partner does not have ‘auto update license’ enabled.

1. On rare occasions, the Order Processing team has not processed the usage report yet.

Challenge

Cause

Solution

1. Stop all Veeam services.
2. Connect to the SQL instance hosting the VeeamBackup database.
3. Create a backup of the VeeamBackup database. (http://www.veeam.com/kb1471)
4. Expand the DB to Programmability > Stored Procedures > dbo.DropStoppedOldJobSessions
5. Right click > Execute... > in the window that appears enter how many days you want to keep
6. Press OK to execute, it will report “Query executed successfully.” when it completes.
7. Start all Veeam services.

──────────────────────────────────────────────────────────
Changing Session history retention
──────────────────────────────────────────────────────────
You can specify session history settings for jobs performed on the Veeam backup server. 

1. Select Options from the main menu.
2. Click the History tab.
3. In the Sessions section, specify the number of sessions to display in the Sessions list of the History view.