Hi

Can you elaborate a bit more?
I will be happy to assist, but Im not understanding what you are asking for.
 

cheers.

Unfortunately, your problem is not written clearly.

Is the problem that the backup takes too long?
Is the problem that the backup of the VM only starts 5 minutes after the job starts?

Please specify the problem again more clearly

Did anyone experience a similar issue. I have the same with one of our customers. We have upgrade veeam from 12.1 to 12.2 and migrated the configuration DB from MS SQL to postgresql. We noticed since then that the jobs are getting triggered with a delay of 3 to 5 minutes while others are not started at all, as per the scheduling unless you go and start them manually.  All the jobs are successfully running. Though there is clearly an issue to trigger them by Veeam. 

Now, we wonder whether this is because of the upgrade or because of the migration to Postgresql. 

Just wanted to hint that we did apply the Set-VBRPSQLDatabaseServerLimits cmdlet to extend hardware resources of PostgreSQL instances that is used as a configuration database by Veeam Backup & Replication

@msmida237, open a Support Case and let Veeam Support take a look. There are simply too many elements that might be affected, and while I’m sure you will find blogs or other such media confidently telling a solution, from experience, there are too many factors that may influence it based just on the description. 

When you open the case, specify which of the following is true and be sure to include logs from the affected job (use the 1st radio option and select one of the affected jobs).

• The job is delayed several minutes after the scheduled start time
• The job starts at the scheduled time but it takes several minutes before it advances to processing
  • If there is a “Waiting for _____ availability” message or something like that, screenshot it and include it for support)
• There is a specific operation in the list which waits for several minutes

I’m sorry to tell, but such delays can come from many environmental factors, but we will be guessing far too much to do this over a forum. Support case is best way to go

Thanks @ddomask for your reply. This is exactly what our customer ended up doing. We in fact have raised a case with Veeam support and they suggested to change the value of the registry key which is SQLSTAEMENTTIMEOUT to 1800. This looks to be fixing the issue, (no delay to start the scheduled backup anymore) but we noticed that the size of the configuration database has reduced significantly. We are following up with the support to find out the reason behind that. The good thing is that we tested a couple of restore from different area of the backup and we feel comfortable with the data integrity. 

Hi @msmida237, you’re very welcome, and the solution sounds reasonable.

That the database size dropped significantly is a little unexpected, but I do have a theory that it was related to the Tombstones table in the Veeam Configuration Database -- this table is used to temporarily hold entries that were deleted from a few key tables by normal operations (usually backup related entries, these are kept to allow rollbacks if necessary) The table should be cleared automatically when all console connections to the Veeam server are closed, but it’s possible the clearing has been failing due to the query to clear these entries hitting a client timeout, which you fixed with the registry value. Just a guess, but would make sense as perhaps there were tons of entries there that weren’t being cleared, or another similar one.

If backups and restores are working well, I wouldn’t worry about it, but if you have concerns or curiosity, you can restore from a previous configuration backup to a new database without pointing Veeam at the new database (perhaps do so on a temporary VBR server without network connection that you can discard later). Then use the native reporting tools and check the top table usage between the current Configuration Database and the previous one -- if you see that tables like *Sessions or Tombstones* have decreased, I would not worry as it’s what I suspect.

If it seems like a lot of work though and you’re comfortable everything is working, then I wouldn’t worry about it.

Hi @Masoudkhb, it’s quite normal for a job to take a few minutes to start moving data and this tends to take longer the bigger the job is. During this “pre-work” time it does things like refresh inventory of both the production VMs, backups and restore points, and required backup infrastructure. There are also other admin tasks that are performed. Here’s a synopsis of everything that happens in a job, all the way up through step 8 is done prior to moving data https://helpcenter.veeam.com/docs/backup/vsphere/backup_hiw.html?ver=120.

We just got an explanation of the whole phenomena including the DB size getting reduced. And this was actually  all because of the deployment of the Enterprise manager. In fact as soon as we added the VBR to the Enterprise manager, the latter started collecting the data from the VBR but also applying it’s own default configuration including the licences and the sessions history settings. We found out that the default configuration of this property is set by default at 13 weeks within the enterprise manager while it was configured at 52 weeks within the VBR. And whether this was the default configuration or whether this has been previously manually configured, it was the reason behind the delay of the jobs getting started, because there was a process running to clear all the session history previous to 13 weeks. As soon as this process has been completed, the jobs resumed running as per the schedule and the DB size has reduced.

We found out actually that the session history setting turned to 13 weeks within the VBR as well and greyed out. Which means that you can not change that from the VBR. A message under that value was displayed saying that this server is managed by the Veeam enterprise manage and that you need to go to that setting within the VEM to change the value 

This is the article confirming the same :

https://helpcenter.veeam.com/docs/backup/em/configuring_retention_settings.html?ver=120

Thank you all for your support