Feature Request: Increase 7 days timeout limit on backups

[saibot93]

We have a costumer with a 40 TB fileserver we are trying to backup to Cloud Connect. It always fails after 7 days of backup. Veeam support told us that it was a limit hardcoded in the agent.
We need to be able to override the limit or we cant backup the server.

Case#02313834

[Dima P.]

Hello Tobias,

Just to clarify, you are referring to a single backup job run which takes 7 days and then fails? Thanks!

[saibot93]

Exactly. Single backup job fails if it's not completed after 7 days, because of a hard-coded limit in the agent.

[MPlesnerJ]

Exactly. Single backup job fails if it's not completed after 7 days, because of a hard-coded limit in the agent.

To work around this issue for now, where is the bottleneck ?

I guess it is a network issue?

Or is it Source disk?
Because 5 x10 TB disks (7K SAS) in RAID 5 will delivery ~17MByte/s ( Random 64K block, 90% read )

[GROOVY1975]

I know this is a REALLY old thread and I apologize for resurrecting this post, but I ALSO wish to have this hard coded limit of 7 days REMOVED or at least configurable through config files (XML or whatever). This way we can CHOOSE to change the limit BEFORE a backup fails verses having a coding issue decide the backups should fails (simply because its running for 7 consecutive days). This is critical for multiple CC clients of mine, for example, I am TRYING to create an initial backup on a new client (to fix an older service provider's bad practice design). I am doing this through using CloudConnect off of a Hyper-V host directly to the CC repo in our cloud. This Hyper-V host was not configured properly at all and thus has 3TB's of disk use that MUST be backed up, this host has well over 3TB's of volume used in Snapshots, VHD's, and config files. Until I have a solid backup, I cannot reconfigure the host properly to remove these snapshots, improper VHD locations, ETC. This job runs over the internet (obviously) through CC but cannot finish because it goes past 7 days. WHY would Veeam decide its OK to cancel and fail the job simply because its still running past the 7 days mark? This is not an acceptable solution in all aspects of backups, especially in this scenario (which I have found and faced on numerous occasions for multiple clients).

There are NO bottleneck on the network, nor disk, nor host, or (CC repo side) the only issue is that it takes numerous hours to physically upload the data to the CC repository (approximately 9 days), I say aprox because it cannot finish due to the 7 day threshold so this is my best guess (but it almost finishes). The main point of CC backups is to allow a secure way to backup hosts, VM's, servers. ETC., over the internet so what do we do in the situation of taking longer than a hard-coded 7 day threshold?! This threshold is a bad idea and shouldn't exist (or again, be changeable).

[Dima P.]

am TRYING to create an initial backup on a new client (to fix an older service provider's bad practice design). I am doing this through using CloudConnect off of a Hyper-V host directly to the CC repo in our cloud.

Have you tried to seed the backup (take the backup locally to a usb device and ship it to your cloud connect repository)?

[sacato]

We would also like to have the 7 day limit removed, or the ability to modify to a longer window it at least. We are a new customer to Veeam, and were told by the Veeam rep that the Veeam agents for Windows would work fine for our remote sites. We battled with backup failures for weeks trying to get the initial seed completed because multiple sites would keep failing at 1 week. The remote data set size is 2.5 to 4 TB, 20 mb bandwidth, but bandwidth has to be reduced during business hours. We have significant concerns now that we would have the same issue in the event of a full server recovery event. Even though we have alternate options to temporarily restore locally and have remote sites work over the WAN, we should be able to do a full restore, or full backup over the WAN without the stress of it failing due to a time bomb in the code if more than 168 hours are needed.

[rpixton]

I just wanted to put my hat in the ring. We ran into this issue for our remote site backups as well. We didn't know what it was at first. Took over a month to get our first backups completed. This setting needs to change.

We were able to work around the issue by scaling back the number of root directories we were backing up on each server. Then adding more data with each successful backup. It took a lot baby sitting. I hope I never have the need to restore those servers from backup. That would be a nightmare.

[GROOVY1975]

Have you tried to seed the backup (take the backup locally to a usb device and ship it to your cloud connect repository)?

Yes, for the ones we can, I always pre-seed the data, unfortunately this is not always possible and the reason I originally resurrected this forum. One of my clients is overseas, remote, very remote, so to pre-seed the data, I would first have to get a recent backup, then ship it overseas (which can take over a week) to my colo where the repo sits, but thats ONLY possible if I can get the remote hands at the remote site (who are clueless) to figure out what I am telling them to do (AND who barely speaks English). This means, even "IF" I can get them to understand me and to do what I need them to do, I still have a week old backup seeded from the source (overseas) which is already outdated when it arrives to the colo a week + later. This will require a new delta sync, and guess what, this takes OVER a week to complete on multiple VM's so no, not a solution. Some VM's are multiple TB's which all have to be read over a painfully slow WAN link.

Again, the 7 day timeout needs to be changed or allow us to configure the threshold. As I already stated, seeding is not always an option, so this is unacceptable in my book. Dont get me wrong, I love Veeam and Veeam has saved my clients more times than I can count, so I am not faulting the software but the decision to leave it at 7 days before it kills the job. This does not seem to me a wise decision, especially when others are having similar issues and making the same comments/requests.

[MarioS]

It seems that this problem still exists in version 4 of the agent. We have a customer reporting this exact issue with his windows backup client.
Is there a work around for version 4 or is this still unresolved ?

[Dima P.]

Hello folks,

You can enable the backup cache functionality to store the backup locally and sync it with the target later. Additionally we've added so called 'resume backup' which allows to continue the backup in case of connectivity issues.

[mamosorre84]

Hi Dima,

I have the same problem, and I cannot use local cache.

Do you have a registry key solution to increase this limit?

Thanks

Marco S.

[Dima P.]

Hello Marco,

Unfortunately we don't have a key to increase this timeout. Cheers!