Skip to main content

Hi, my first experience backing up a volume on my Ubuntu 20.04.6 LTS Linux machine is resulting in a Snapshot overflow error.  I use Veeam B&R Community Edition Build 12.1.2.172.  Here are some details:

  • Veaam R&D machine: Dell PowerEdge R7515
  • OS: Windows Server 2022 Standard.
  • CPU: AMD EPYC 7232P 8-Core Processr 3.09GHz
  • RAM: 32 GB
  • Backup Disk E: has 65.5 TB capacity with 9 TB free (This disk is the default backup repository)
  • Protected computer: Dell PowerEdge R550
  • OS: Ubuntu 20.04.1
  • CPU: Intel Xeon Gold 5317 12-Core Processor 3GHz
  • RAM: 64 GB
  • Backup Mode: Volume level backup
  • Objects: /mnt/data as the only mount point (ext4 with about 7.7 TB of content with total capacity of 65 TB, which means it is 87% free)

Multiple backup attempts were made and they all failed with the same Snapshot overflow error. 

Furthermore, I have studied the protected computer requirements referenced here and my system seems to comply.

I appreciate any feedback and suggestions.

Thank you,

-sul.

Can you check the backup logs and post some of the errors?  Located here - C:\ProgramData\Veeam\Backup\Jobname

You might need to create a case for this one as this is the community not support.  We help as best we can.


Can you check the backup logs and post some of the errors?  Located here - C:\ProgramData\Veeam\Backup\Jobname

You might need to create a case for this one as this is the community not support.  We help as best we can.

Hi Chris,

thanks for your post and comment.  I have attached a log file for the backup job in question.  Happy to send more details if needed.

 

Thank you!

 

-sul.


I am not seeing anything in this log about a failure unfortunately.  The drive that is the repo drive on your server - are you able to free up more space on there as the free of 9TB is close to the size of data from the Linux machine 7.7TB and you always want some working room for transforms, etc.

It is hard to say what the issue is without a deeper log dive but that would be a support ticket at this point.

Maybe search the Veeam Forums for the same issue to see if there are any others that fixed it - https://forums.veeam.com

 


Hi Chris,

thank you for studying the log file and for your suggestion for allocating more working room on the repo.  The default repo is now cleaned out and I was able to reclaim 65.2 TB of space.  I just ran the job again and let’s see what happens.  If it fails with the same error, I will open a ticket.

Thanks again,

-sul.


Sounds like a plan and I hope the backup works this time.  Keep us posted.


Sounds like a plan and I hope the backup works this time.  Keep us posted.

So, unfortunately even after freeing up more than ample amount of disk space, the back up of the volume still crashes with a “Snapshot overflow” error.  I will open a support ticket and I intend to share my experience with support. 

thank you,

-sul.


Sounds like a plan and I hope the backup works this time.  Keep us posted.

So, unfortunately even after freeing up more than ample amount of disk space, the back up of the volume still crashes with a “Snapshot overflow” error.  I will open a support ticket and I intend to share my experience with support. 

thank you,

-sul.

Best approach now for this issue as they can look at the logs better.  Keep us posted on the solution.


Hello

 

12.1.2.172 Faulty version please tested, I recommend you to switch to 12.1.1.56


Hello

 

12.1.2.172 Faulty version please tested, I recommend you to switch to 12.1.1.56

Thank you for the tip.  Unfortunately, I am not familiar with how to rollback Veeam to a prior version in a way that is not too disruptive, e.g., fully uninstalling and then re-installing Veeam.  Hopefully Veeam tech support will consider taking on my open case soon. 

Thank you,

-sul.


Sounds like a plan and I hope the backup works this time.  Keep us posted.

So, unfortunately even after freeing up more than ample amount of disk space, the back up of the volume still crashes with a “Snapshot overflow” error.  I will open a support ticket and I intend to share my experience with support. 

thank you,

-sul.

Freeing up space on the backup repository doesn‘t solve anything related to a „snapshot overflow“ warning.

 

This message usually means, that there is not enough space in the source machine (where you have installed your Linux Agent) to temporarily store snapshot files while the backup is running. Snapshots are not stored on your backup repository disks.

 

I suggest to check with our support team if anything can be tweaked on your Linux machine to solve this situation.

 

Best,

Fabian

 

 

 


Sounds like a plan and I hope the backup works this time.  Keep us posted.

So, unfortunately even after freeing up more than ample amount of disk space, the back up of the volume still crashes with a “Snapshot overflow” error.  I will open a support ticket and I intend to share my experience with support. 

thank you,

-sul.

Freeing up space on the backup repository doesn‘t solve anything related to a „snapshot overflow“ warning.

 

This message usually means, that there is not enough space in the source machine (where you have installed your Linux Agent) to temporarily store snapshot files while the backup is running. Snapshots are not stored on your backup repository disks.

 

I suggest to check with our support team if anything can be tweaked on your Linux machine to solve this situation.

 

Best,

Fabian

 

 

 

Thank you for your post. The source machine’s volume has about 87% of space free with over 65 TB  of free capacity. Furthermore, and unfortunately, tech support just decided to close my case (#07312406 opened 6/22/2024) with no resolution.  They claim they are low on support staff--which, IMHO should never be a reason to close a case, but rather delay it, if anything.  Very disheartening.  Any way, I will likely be moving on from Veeam as a viable tool to backup my Ubuntu machine.

Thanks!

-sul.


Furthermore, and unfortunately, tech support just decided to close my case (#07312406 opened 6/22/2024) with no resolution.  They claim they are low on support staff--which, IMHO should never be a reason to close a case, but rather delay it, if anything.  Very disheartening.  Any way, I will likely be moving on from Veeam as a viable tool to backup my Ubuntu machine.

Thanks!

-sul.

Hi Sul

I’m sorry to hear that. It looks like you are a user of our free product offering.
Support on our free products is on a best effort level. If there is free capacity in our support team, free cases will also be processed. Please see our support policy for more information (chapter 4.3): https://www.veeam.com/support-policy.html 

You may try again with a new case.

 

Best,

Fabian

 

 


Furthermore, and unfortunately, tech support just decided to close my case (#07312406 opened 6/22/2024) with no resolution.  They claim they are low on support staff--which, IMHO should never be a reason to close a case, but rather delay it, if anything.  Very disheartening.  Any way, I will likely be moving on from Veeam as a viable tool to backup my Ubuntu machine.

Thanks!

-sul.

Hi Sul

I’m sorry to hear that. It looks like you are a user of our free product offering.
Support on our free products is on a best effort level. If there is free capacity in our support team, free cases will also be processed. Please see our support policy for more information (chapter 4.3): https://www.veeam.com/support-policy.html 

You may try again with a new case.

 

Best,

Fabian

 

 

Unfortunately, it seems impossible to get free-tier support.  It was closed twice.  I just requested a third time and let’s see.  Crossing fingers, but sadly I’m running out of time before I give up on Veeam.

Thanks!

-s.


Hi All,

After doing some digging, I learned that on a Linux-based target machine, there is a configuration file under /etc/veeam/veeam.ini.  This configuration file has sections to tweak snapshot sizes.  Veeam allows for either common snapshots or stretch snapshots.  I decided only to play with stretch snapshot section by simply uncommenting the existing commented section portionSize = 1073741824. This resulted in the same snapshot overflow error after backing up about 10%.  After that, I doubled the value to 2147483648, which lead to some improvement by backing up about 48%.  Finally, I doubled it again to 4294967296 and that seemed to do the trick.  The backup of about 7 terabytes of data took over 22 hours but at least it does not break.  If someone can guess why backups are taking soooo long and wish to offer suggestions, please feel free to do so.

Many thanks!

-sul.


Not sure what to suggest as 7TB is a large VM so it will take time based on disk and target.


Hello Chris, Sul,

We have the same problem "Snapshot Overflow” on a rather heavy duty system with Unbunt 22.04.4 LTS. A downgrade of the Veaam Version is not an option. Also the close of the case (#07312406 opened 6/22/2024) x is an easy way out.

So therefore is modifying /etc/veeam/veeam.ini => portionSize = 1073741824 to 2147483648 to 4294967296 , doubleing the portionSize the solution??  


Hello Chris, Sul,

We have the same problem "Snapshot Overflow” on a rather heavy duty system with Unbunt 22.04.4 LTS. A downgrade of the Veaam Version is not an option. Also the close of the case (#07312406 opened 6/22/2024) x is an easy way out.

So therefore is modifying /etc/veeam/veeam.ini => portionSize = 1073741824 to 2147483648 to 4294967296 , doubleing the portionSize the solution??  

It seems like the solution for Sul so may work for you as well. Only way to see is test it.


Hello Chris, Sul,

We have the same problem "Snapshot Overflow” on a rather heavy duty system with Unbunt 22.04.4 LTS. A downgrade of the Veaam Version is not an option. Also the close of the case (#07312406 opened 6/22/2024) x is an easy way out.

So therefore is modifying /etc/veeam/veeam.ini => portionSize = 1073741824 to 2147483648 to 4294967296 , doubleing the portionSize the solution??  

It seems like the solution for Sul so may work for you as well. Only way to see is test it.

I agree with Chris.  Try it and see.  And if possible, please report back.

 

-s.


Hi there, any update on this? 

We are running currently in the same behaviour. Environment here is a SLES system with SAP HANA running on it. The HANA backup by the Veeam Enterprise Plugin (via backint) is running fine - but the customer is also running an VAL on it.

Have also tried on the TEST/DEV system playing around with editing the veeam.ini, changed snapshot type from stretch to common - changed it back, increased the portionSize by 8x… 

 

 

Unfortunately i’m not the Linux expert - have found this and some more articles in the R&D.

The Linux & SAP HANA Consultant currently cant’t give me a seperate mount point for storing the snapshots. I will open a ticket in the next hour (currently there is an issue in Veeams Support Portal). Will keep you updated.


Comment