rebooting B&R servers best practice (agent based)

[edison5000]

I found a single doc on this - https://www.veeam.com/kb2991

Do not see anything in forum FAQ or quick start guides.

While kb2991 seems to answer how to stop every related Veeam service, it doesn't exactly indicate this is what you should do if you regularly patch a Windows server that it resides on.

1. I figured stopping & disabling all jobs would be enough; when you see they are all completely stopped, patch the server and reboot it. Is this the best practice?

2. If that is the correct procedure, how are people typically doing this in places that have hundreds of agents, when simply disabling and stopping the jobs can take most of a day before every agent gets the message? Seems like you sacrifice those hours of backup, I guess, unless you have multiple B&R servers.

Thx!

[david.domask]

Hey e,

1. This is plenty. If you cannot schedule the maintenance window outside of the backup window (e.g., backup window never gives a gap), bulk-disabling is perfectly fine. Even if you miss a job or two, most ought be just fine, albeit with some errors. There are cases when the impact might be greater, so a proper maintenance window is ideal, just like any other application.

2. A few customers I've worked with just implemented a check on a script to schedule a reboot. Disabling a job doesn't stop the job (backup copies are an exception) so you just basically start a wait loop that checks for running jobs (all job objects to my knowledge have an IsRunning property (maybe a method I forget) that can be polled). A simple loop of getting all jobs where IsRunning -eq $true and if any results, sleep the script for 10 minutes typically is sufficient.

Agent jobs in particular are resilient towards such outages with the Backup Cache so it's not as much of a deal as it is with snapshot-based backups on hypervisors: https://helpcenter.veeam.com/docs/agent ... tml?ver=50

So I wouldn't put too much thought into this for Agent backups, the backup cache mitigates a lot of the issue of the backup repository/Veeam server being unreachable.