Periodic jobs schedule in v8

[jasonpearce]

[MOD] Topic split from Custom schedule?

I don't want the start times (aka Next Run) to be fixed, which you've done for Version 8. I do want the Next Run to creep and carry over into the next day.

The changes you made to Veeam 8 cause all periodically scheduled backup jobs to run between midnight and 1 am every day. Previously, if a job was configured to run every 5 hours and last ran at 10 pm, it would next run at 3 am. This is desired. But with Veeam 8, a job that last ran at 10 pm would next run at midnight, then 5 am, then 10 am, etc. This is not desired.

Having all periodic backup jobs reset their Full Period (the time between Latest Run and Next Run) when crossing into the next day a) messes up our backup schedules so they no longer run when we expect them to run and b) causes all periodic backup jobs to run shortly after midnight.

[Gostev]

I do want the Next Run to creep and carry over into the next day.

Creeping is exactly what was causing massive issues in the previous version of scheduler in certain scenarios, generating incredible amount of support cases. As a matter of fact, creeping and carrying over into the next day as such is simply impossible in v8, as allowed time periods have been limited to factors of 24 hours (i.e. 1, 2, 3, 4, 6, 8, 12, and 24), with reference point tied to midnight every day. Your job still runs every 5 hours only because it was created before the upgrade.

But with Veeam 8, a job that last ran at 10 pm would next run at midnight, then 5 am, then 10 am, etc. This is not desired.

You can easily prevent jobs starting at undesired times by simply blocking those times. For example, the job will never "run between midnight and 1 am every day" if you simply block this time slot in the Schedule control of the specific job. Just let us know some specifics of the periodic schedule you are trying to achieve (period and desired start times), and we will tell you how the job schedule should be set up for this.

One thing you certainly lose with v8 is the ability to run the job every 5 hours (you have to pick between 4 or 6, whichever works best for you). It was the price for making the scheduler predictable, and for good as this reduced the number of support cases around unexpected periodic jobs behavior over 10 times (to close to zero, not counting legacy jobs).

Thanks!

[jasonpearce]

In Veeam B&R 7, the Edit Backup Job > Schedule > Run the job automatically > Periodically every xxx minutes/hours was much more flexible. Veeam B&R 8 has reduced functionality that we'd like to have return to the product.

Objective 1: Accept a greater range of minutes/hours
For Periodically Every XXX Minutes/Hours, allow your users to enter any positive and whole-number value. These formally available configurations are no longer available, but we desire to have returned to the product:

* Periodically every 5/7/9/10/11/13/14/15/16/17/18/19/20/21/22/23 hours
* Periodically every 25/48/50/72/96/100/etc hours

For the former, it is helpful to set jobs A/B/C to run every 11 hours and jobs D/E/F to run every 13 hours -- creating some random overlap and staggering regarding concurrently running jobs. For the latter, not all jobs need to run every day. Having jobs run periodically every other day, or every three days, is sufficient. With Veeam B&R 8, all periodic jobs run at midnight, creating a large strain on resources and wipes out all efforts to stagger the schedule of backup jobs so many do not run concurrently.

Objective 2: Set periodic backup jobs by policy instead of a fixed schedule
Schedule my jobs for me, by policy, so I don't have to micromanage when jobs run. Options like this would be helpful:

* Run the job periodically so that XX to XX backups are performed each day (e.g. randomly run this job every 5 to 9 hours)
* Run the job periodically every XX hours, plus or minus random XX minutes/hours (e.g. randomly run this job every 12 hours, plus or minus a random 0-3 hours)
* Run the job periodically every XX hours, but delay the task for up to (random delay) XX minutes/hours (e.g. randomly run this job every 7 hours, plus a random delay up to 3 hours)

Any of these options, if applied to many periodic backup jobs, would reduce the chance of all jobs running at the same time (like between midnight and 1 am the way Veeam B&R 8 currently operates).

Objective 3: Automatically forecast and stagger my schedules for me
Have users define a few tiers of backup levels (gold, silver, bronze), have them group backup jobs into one of these tiers, and then based on previous backup performance, suggest an optimal backup schedule for all backup job. You'd calculate that a user's infrastructure could perform XX backup a day. You could then suggest that to backup the gold tier six times a day, the silver tier three times a day, and the bronze tier just once a day; staggering all jobs so as few run at the same time as possible.

Something similar to VMware DRS, but for backup schedules (e.g. "based on your resources and past performance, we recommend running these backups XX times a day"). If resources are insufficient, like with vSphere, we add more backup nodes and automatically balance backup repositories when a new one is added.

Closing
While my latter feature requests would better meet our needs, my top request is for you to simply remove the rigid Veeam B&R 8 periodic scheduler by reverting back to the flexible Veeam B&R 7 periodic scheduler. Having all periodic jobs run at midnight creates a burden on resources that was best avoided by simply staggering when backup jobs ran.

[Gostev]

Hi, Jason - see my previous response to you above. Legacy scheduler is not coming back, because we had many users experiencing issues due to its unpredictability, which caused them to miss their target RPOs. And there is nothing worse for a backup admin than missing their target RTOs and RPOs.

However, I noted that all your feature requests (objectives) above indicate that you are not aware about our task scheduler capabilities, which was actually specifically designed to address all perceived issues you are listing.

First and foremost, we do already provide you with the ability to prevent periodic jobs from running on the certain days by simply disallowing them during the entire corresponding day.

"Large strain on resources" (and a few similar notes you've made along these lines): this is very easy to avoid by reducing available proxy slots on source and/or target proxies or repositories. This will keep the maximum amount of concurrent tasks to the acceptable level, which you yourself will define with the processing slots count.

Likewise, this functionality also addresses your desire not to "micromanage tasks", by starting tasks only when processing resources become available (effectively randomizing their start times). However, this is significantly better than pure randomization that you are suggesting which a) cannot guarantee that bad overlaps will not happen occasionally and b) will result in the opposite situations too - time periods when no jobs are running. Resource scheduling, on the other hand, 100% guarantees both of these issues never happen.

And, as you can probably see by now from my explanations, "staggering all jobs so as few run at the same time as possible" is also achieved natively - this is just how our task scheduler works already. We will never process more VMs than available processing resources allow us to, the rest will be staggered according to their start times - waiting for the processing resources to appear (which will happen as previously started jobs finish processing their VMs).

There is one request from you that does NOT make sense to me though: our product "suggesting" how many times per day the given jobs should run. This seems totally disconnected from the core data protection concepts? Every company has certain RPO requirements backup admins have to meet, and they set the job period according to that requirement. We simply cannot "recommend running these backups XX times a day" because we do not know your company's policy on maximum acceptable data loss in case of a disaster, which is the only thing that defines how many times a day the particular job should run.

In any case, note that you still have the flexibility to start the jobs using Windows Scheduler or other 3rd party scheduling app or script, if you don't feel built-in scheduler provides sufficient flexibility for your needs. This option is always there for you to use, and it will let you create just about any schedule you like.

Thanks!

[jasonpearce]

Gostev,

Thank you for taking the time to comment on my concerns.

And there is nothing worse for a backup admin than missing their target RTOs and RPOs.

Perhaps. But I can say that doctors and clinical staff do not appear to appreciate that every virtual machine is being backed up between midnight and 1 am.

we do already provide you with the ability to prevent periodic jobs from running on the certain days by simply disallowing them during the entire corresponding day.

I'm aware that I can go to Edit Backup Job > Schedule > Run the job automatically > Periodically every xxx minutes/hours > Schedule > Time Periods to Permit or Deny when backups can occur in 30 minute increments. This functionality existed in v7, if not earlier.

And yes, I suppose I could use this to micromange all of our backup jobs to achieve the staggering I desire. But what a pain. I would have to track every job on every backup server/repository to set unique Permitted or Denied schedules. With v7, all we had to do is set Tier 1 jobs to run every 11 or 13 hours, Tier 2 jobs to run every 23 or 25 hours, and Tier 3 jobs to run every 47 or 49 hours (all permitted to run any day of the week at any time). This simple configuration staggered all jobs, preventing them from running at the same time, by random chance.

"Large strain on resources" ... this is very easy to avoid by reducing available proxy slots on source and/or target proxies or repositories. This will keep the maximum amount of concurrent tasks to the acceptable level, which you yourself will define with the processing slots count.

This hasn't helped. While I set "Limit maximum concurrent tasks to" for backup repositories, I/O control (both Enable parallel processing and Enable storage latency control), all periodic jobs still shift their Next Run schedules to run at midnight. If I configured all jobs to not run between 00:00 and 01:00 via a Deny rule, then I assume they'd all try to run between 01:00 and 02:00. I'd have to specifically configure all jobs to have unique Permitted/Denied schedules to prevent all from running at midnight. Right?

Also, when I adopted I/O control and limit concurrent tasks, jobs took longer to run and waiting jobs failed because they no longer had enough resources to run at the same time -- generating errors. Starting each day with reports that many jobs failed hasn't been ideal and was not something we experienced with V7. We even added an additional Veeam V8 backup repository/proxy (without adding more backup jobs) and still could not complete all of the midnight backup jobs without error when the constraints were in place.

Likewise, this functionality also addresses your desire not to "micromanage tasks", by starting tasks only when processing resources become available (effectively randomizing their start times).

Except for all of the errors failing jobs generate each morning because they no longer have sufficient resources to run in time. Yes, they eventually run, but not after failing one or more times. And some of the jobs have 10 or more VMs to backup. With resource constraints in place, I'm not maximizing the power of my Veeam servers causing the jobs to take longer to complete.

However, this is significantly better than pure randomization. ... Resource scheduling, on the other hand, 100% guarantees both of these issues never happen.

I agree with you that randomization has some risk in that many jobs could try to run at the same time (or not at all). But our V7 random experience was much better than all V8 jobs wanting to run at the same time between midnight and 1 am.

We will never process more VMs than available processing resources allow us to, the rest will be staggered according to their start times

I have resources. My Veeam backup servers have 16 2.30 GHz cores (32 logical processors), both fiber and 10 Gbps Ethernet, 48 GB of RAM, and a 16-drive RAID 10. My source storage is a solid state SAN than can handle more IOPS than I can use. I'd like to use these resources not to complete as many concurrent backup jobs at the same time (e.g. midnight to 1 am), but to have each individual job complete as quickly as possible. When jobs complete quickly, they have smaller vSphere shapshots, which take less time to commit, that results in users noticing fewer performance issues.

Staggering when backup jobs occurred in V7 was a very easy solution that effectively evenly distributed backup workloads so that only a few jobs were running at a time, and thus completed quickly. With V8, it sounds like we're now going to have to define unique Permit and Deny schedules for every job across multiple backup proxies to avoid having them all run at midnight.

There is one request from you that does NOT make sense to me though: our product "suggesting" how many times per day the given jobs should run. This seems totally disconnected from the core data protection concepts? Every company has certain RPO requirements backup admins have to meet, and they set the job period according to that requirement. We simply cannot "recommend running these backups XX times a day" because we do not know your company's policy on maximum acceptable data loss in case of a disaster, which is the only thing that defines how many times a day the particular job should run.

My Veeam backup servers are not running at capacity. If my objective is to backup my Tier 1 workloads at least twice a day and my Tier 2 workloads at least once a day, your automatic scheduler could say "It looks like I can easily beat your RTO/RPO objectives by backing up your Tier 1 workloads four to five times a day and your Tier 2 workloads two to three times a day. Would you like for me to dynamically configure, stagger, and adjust the schedule of your backup jobs to exceed your RTO and RPO objectives?" I'd click yes if you'd offer me that option.

I wasn't expecting you to "know your company's policy on maximum acceptable data loss in case of a disaster". Sorry if I was unclear. I was expecting you to look at my defined objectives (e.g. "Have users define a few tiers of backup levels"), look at past backup performance, look at the resources available, and then tell me that you can meet or exceed my RTO/RPO objectives. If so, then give me the option to have your scheduler stagger everything for me. That's what I'm having to do right now by hand with V8 because of the removed scheduler functionality that was available V7.

note that you still have the flexibility to start the jobs using Windows Scheduler or other 3rd party scheduling app or script, if you don't feel built-in scheduler provides sufficient flexibility for your needs. This option is always there for you to use, and it will let you create just about any schedule you like.

I know, which is why I wrote this PowerShell script: https://www.jasonpearce.com/2015/03/12/ ... owershell/. And while I'm able to randomize how often the jobs run, the hourly offset, the retry timeout, the last time the job ran, and the next time the job ran; Veeam B&R V8 still ignores my Next Run settings and overrides my script by having all jobs run at midnight. If there was an object, cmdlet, or way for me to disable the required "all periodic jobs have their schedules reset at midnight" option, then I think I would be able to use my third party script to meet my needs. But I don't think you made the "Periodic Schedule Reset / your desired Next Run is overruled" feature a configurable option.

I'm sure you and the Veeam team are constantly trying to make the product better -- which I appreciate and expect. In this case, however, the changes to the periodic scheduler with V8 causes jobs to cluster (particularly at midnight), which results in backup jobs taking longer to run. With V7, our strategy to avoid jobs from running at the same time was easy (just +- by one hour). With V8, this simple strategy was not only removed, but overridden for all periodic schedules that cross over into the next day. With V8, we now had to learn Veeam PowerShell to see if we could override this behavior (could not). And now it appears we are going to have to micromanage the Permit/Deny schedule for each backup job (because providing resource constraints generates errors).

I recognize that my feature request is in the minority and will thus be ignored. No longer can we have jobs run every 13 (now runs every 13 then 11 hours) or 25 hours (now runs every 24 hours). Periodic jobs must now have Deny times to prevent all jobs from attempting to run as soon as possible after midnight. Otherwise, your suggestions to use resource constraints cause jobs to take longer to complete and for waiting jobs to eventually error. Lastly, I could disable the periodic scheduler and attempt to write my own via Veeam PowerShell. All of these options add complexity to a Veeam project I formerly adored. It's too bad that you did not provide users the ability to enable or disable the new "Periodic Schedule Reset / your desired Next Run is overruled" feature that was added in V8.

[Gostev]

This hasn't helped. While I set "Limit maximum concurrent tasks to" for backup repositories, I/O control (both Enable parallel processing and Enable storage latency control), all periodic jobs still shift their Next Run schedules to run at midnight. If I configured all jobs to not run between 00:00 and 01:00 via a Deny rule, then I assume they'd all try to run between 01:00 and 02:00. I'd have to specifically configure all jobs to have unique Permitted/Denied schedules to prevent all from running at midnight. Right?

I think you are confusing job start time with actual VM processing start time... and perhaps still not understanding our core load control concept. Because there is zero issue with all jobs starting at the same time. In fact, this is the recommended way to schedule jobs with Veeam. Even when people have hundreds of daily backup jobs created, our recommendation is still to schedule them all to start at the beginning of backup window (at 8pm, for example). With any other product, this approach would completely slam the environment of course, but this is not the case with Veeam.

While all these jobs will all start at the same time, actual VM processing start time for every job will be different due to the limited processing resources. For example, all jobs going to the same repository that has 4 task slots will never process more than 4 virtual disks at once. As the results, first job will be processing its VMs, and all other jobs will be waiting for previous jobs to finish execution. In my example, some jobs may only get to processing their VMs at 4am - despite the actual job was started at 8pm.

I'd like to use these resources not to complete as many concurrent backup jobs at the same time (e.g. midnight to 1 am), but to have each individual job complete as quickly as possible. When jobs complete quickly, they have smaller vSphere shapshots, which take less time to commit, that results in users noticing fewer performance issues.

What's interesting is that with this, you have provided the ideal description of our existing intelligent load balancing engine, and then the reason why we have designed it this way. First sentence describes EXACTLY how it works today.

I know, which is why I wrote this PowerShell script: https://www.jasonpearce.com/2015/03/12/ ... owershell/. And while I'm able to randomize how often the jobs run, the hourly offset, the retry timeout, the last time the job ran, and the next time the job ran; Veeam B&R V8 still ignores my Next Run settings and overrides my script by having all jobs run at midnight.

Actually, when I was talking about a script, I did not mean a script that would set "Next Run" settings. I am meant the script that literally starts the jobs. This way, you are able to completely bypassing Veeam scheduler, and configure any desired custom behavior for your jobs start times.

I always recommend against this approach though, because our load balancer will always do better than manual scheduling and randomization, as the later only works in the ideal world (when each job runs exactly as long as you expect it to). While in the real world however, even a single minor environment change (even most basic one like larger size of incremental data to process) may cause unexpectedly longer run times, instantly causing a mess of dozens of overlapped jobs caused by carefully thought out schedule from the ideal world.

[jasonpearce]

Here's a potential PowerShell means of partially accomplishing what I desire.

Option A: What I'm currently doing

Step A1: Follow my "Randomize your Veeam backups via PowerShell" (https://www.jasonpearce.com/2015/03/12/ ... owershell/) blog post to create somewhat random, yet staggered, periodic backup schedules.

Step A2: Follow my "Fixing Veeam Backup v8 Periodic Scheduling" (https://www.jasonpearce.com/2015/03/23/ ... cheduling/) blog post to create a Windows Scheduled Task to run a PowerShell script that will carry over the FullPeriod when beginning a new day by correctly calculating the NextRun value. My only adjustment would be to have the Scheduled Task run every 10 minutes, since it appears that Veeam will try multiple times to reset the NextRun to midnight.

Option B: If you don't want to rely on Windows Task Scheduler

Step B1: Use this script to randomize your Veeam backups via PowerShell AND randomize your Deny rules so that all jobs don't run at midnight. Some jobs will have no deny rules and run at midnight, while others will have to wait to run until 1 am, 2 am, 3 am, 4 am, 5 am, or 6 am.

Code: Select all

# Randomize Veeam Backups, a Veeam PowerShell script (Version 2)
# This script will add randomness to Veeam backup jobs by configuring them to use different periodic backup intervals
# Run this on a Veeam Backup and Replication version 8 update 1 server
# You could even copy and paste it into Veeam Backup and Replication > Menu > PowerShell
# Written by Jason Pearce of www.jasonpearce.com in March 2015
# Use at your own risk, freely share, and comment on improvements

# BEGIN Random variables #####################

# RandomFullPeriod: Variable for Schedule > Run the job automatically > Periodically every XX minutes. Must be a value between 0 and 999.
# Key: 1-8 hours 1h=60min, 2h=120min, 3h=180min, 4h=240min, 5h=300min, 6h=360min, 7h=420min, 8h=480min
# Key: 9-16 hours 9h=540min, 10h=600min, 11h=660min, 12h=720min, 13h=780min, 14h=840min, 15h=900min, 16h=960min
$RandomFullPeriodMinimum = 540
$RandomFullPeriodMaximum = 720

# RandomHourlyOffset: Variable for Schedule > Run the job automatically > Periodically every > Schedule > Start time within an hour. Must be a value between 0 and 59.
$RandomHourlyOffsetMinimum = 0
$RandomHourlyOffsetMaximum = 59

# RandomRetryTimeout: Variable for Schedule > Automatic Retry > Wait before each retry attempt for. Must be a value between 0 and 59.
$RandomRetryTimeoutMinimum = 10
$RandomRetryTimeoutMaximum = 50

# RandomMidnightDelay: Variable to prevent all periodic backup jobs from running at midnight (Schedule Denied).
$RandomMidnightDelay0Hours="<scheduler><Sunday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

$RandomMidnightDelay1Hours="<scheduler><Sunday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

$RandomMidnightDelay2Hours="<scheduler><Sunday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

$RandomMidnightDelay3Hours="<scheduler><Sunday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

$RandomMidnightDelay4Hours="<scheduler><Sunday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

$RandomMidnightDelay5Hours="<scheduler><Sunday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

$RandomMidnightDelay6Hours="<scheduler><Sunday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Sunday><Monday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Monday><Tuesday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Tuesday><Wednesday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Wednesday><Thursday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Thursday><Friday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Friday><Saturday>1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Saturday></scheduler>"

# END Random variables #######################

# BEGIN Other variables ######################

# BackupRetention: Variables for RetainDays (amount of restore points) and RetainCycles (amount of days for Deleted VMs retention period).
$RetainDays = 16
$RetainCycles = 16

# Get All, Some, or One backup jobs.
# You MUST uncomment and modify one of these lines to target one or more backup jobs.
# Only one line should begin with "$jobs =". These are just four helpful examples.
#By-All# $jobs = Get-VBRJob | Where-Object { $_.IsBackup -eq $true -and $_.IsScheduleEnabled -eq $true } | Sort Name
#By-PREFIX# $jobs = Get-VBRJob -Name "Test-*" | Where-Object { $_.IsBackup -eq $true -and $_.IsScheduleEnabled -eq $true } | Sort Name
#By-LIST# $jobs = Get-VBRJob -Name "Test-1","Test-2" | Where-Object { $_.IsBackup -eq $true -and $_.IsScheduleEnabled -eq $true } | Sort Name
#By-NAME# $jobs = Get-VBRJob -Name "Test-Job" | Where-Object { $_.IsBackup -eq $true -and $_.IsScheduleEnabled -eq $true } | Sort Name


# END Other variables ########################

# BEGIN foreach loop #########################

# Make the following changes to all backup jobs
foreach ($job in $jobs) {

	# BEGIN Job Options ######################

		# Read current job settings
		$jobOptions = Get-VBRJobOptions -Job $job

		# Set more Job Advanced Storage Options 
		$jobOptions.BackupStorageOptions.RetainCycles = $RetainCycles
		$jobOptions.BackupStorageOptions.RetainDays = $RetainDays

		# Apply these additional Backup Mode settings
		$jobOptions = Set-VBRJobOptions -Job $job -Options $jobOptions

	# END Job Options ########################

	# BEGIN Job Schedule Options #############

		# Create a new job schedule 
		$jobScheduleOptions = New-VBRJobScheduleOptions

		# Disable Other Schedules
		$jobScheduleOptions.OptionsDaily.Enabled = $false
		$jobScheduleOptions.OptionsMonthly.Enabled = $false
		$jobScheduleOptions.OptionsContinuous.Enabled = $false

		# Enable Periodically Schedule
		$jobScheduleOptions.OptionsPeriodically.Enabled = $true

		# Configure Periodic Schedule in Minutes (0 = Hours, 1 = Minutes)
		$jobScheduleOptions.OptionsPeriodically.Kind = 1

		# Generate random number for FullPeriod (Minimum and Maximum variables are defined above)
		$RandomFullPeriod = Get-Random -Minimum $RandomFullPeriodMinimum -Maximum $RandomFullPeriodMaximum

		# Create a random FullPeriod offset
		$jobScheduleOptions.OptionsPeriodically.FullPeriod = $RandomFullPeriod

		# Generate random Midnight Delay (Schedule Denied)
		$RandomMidnightDelay = Get-Random $RandomMidnightDelay0Hours,$RandomMidnightDelay1Hours,$RandomMidnightDelay2Hours,$RandomMidnightDelay3Hours,$RandomMidnightDelay4Hours,$RandomMidnightDelay5Hours,$RandomMidnightDelay6Hours

		# Create a random Midnight Delay (Schedule Denied)
		$jobScheduleOptions.OptionsPeriodically.Schedule = $RandomMidnightDelay

		# Generate random number for HourlyOffset (Minimum and Maximum variables are defined above)
		$RandomHourlyOffset = Get-Random -Minimum $RandomHourlyOffsetMinimum -Maximum $RandomHourlyOffsetMaximum

		# Create a random HourlyOffset
		$jobScheduleOptions.OptionsPeriodically.HourlyOffset = $RandomHourlyOffset

		# Generate random number for RetryTimeout (Minimum and Maximum variables are defined above)
		$RandomRetryTimeout = Get-Random -Minimum $RandomRetryTimeoutMinimum -Maximum $RandomRetryTimeoutMaximum

		# Create a random RetryTimeout
		$jobScheduleOptions.RetryTimeout = $RandomRetryTimeout
		
		# Do some math to randomly stagger LatestRun (past) and NextRun (future), while correctly calculating the FullPeriod difference
		$RandomlyStagger = Get-Random -Minimum 1 -Maximum 9
		$jobScheduleOptions.LatestRun = (Get-Date).AddMinutes(-([math]::Round($RandomFullPeriod * $RandomlyStagger * .1)))
		$jobScheduleOptions.NextRun = (Get-Date).AddMinutes([math]::Round($RandomFullPeriod * (10 - $RandomlyStagger) * .1))

		# Apply the new job schedule
		Set-VBRJobScheduleOptions -Job $job -Options $jobScheduleOptions

	# END Job Schedule Options ###############

	# Report which jobs received these changes
	Write-Host "Changed settings for" $job.Name
}
# END foreach loop ###########################
# END Randomize Veeam Backups script #########


# BEGIN REPORT ###############################
# Optionally Report New Job Schedule Options #
# Safe to delete this report #################

# Get all enabled backup jobs.
$jobs = Get-VBRJob -Name "*" | Where-Object { $_.IsBackup -eq $true -and $_.IsScheduleEnabled -eq $true } | Sort Name

# BEGIN foreach loop #########################
foreach ($job in $jobs) {

	# Report which jobs have what schedules
	Write-Host "------------------------------------"
	Write-Host "Job Schedule settings for" $job.Name

	# Get job schedule
	$ReportJobScheduleOptions = Get-VBRJobScheduleOptions -Job $job
	
	# Report on a few values
	Write-Host "FullPer: " $ReportJobScheduleOptions.OptionsPeriodically.FullPeriod
	Write-Host "HourOff: " $ReportJobScheduleOptions.OptionsPeriodically.HourlyOffset
	Write-Host "LateRun: " $ReportJobScheduleOptions.LatestRun
	Write-Host "NextRun: " $ReportJobScheduleOptions.NextRun
	Write-Host ""

}
# END foreach loop ###########################

# Write current date and time
Get-Date

# END REPORT #################################

This disadvantage to Option B is that you'll want to have shorter FullPeriods. If your FullPeriod was 15 hours, for example, your job would run only seven times a week instead of 11 times in a week (which Option A would offer).