job scheduling: weekly active full at certain time? (with 24/7 incrementals)

[Reboot]

Hello, I am testing Veeam B&R V12 Community Edition and having a problem with job scheduling. I want to schedule one job with "24/7" hourly incrementals (that's 1 incremental every hour of every day, 7 days a week), and with a weekly Active Full backup on Saturday at 6:00 AM. I fill in all the green boxes in the "Time Periods" window for the incrementals to be run 24/7. But how can I force the Active Full backup to start at the exact time (6:00 AM), while preserving 24/7 incrementals?

I realize I can set a denial period (white boxes) in "Time Periods" window to make the Active Full backup run immediately after the denial period, but then, the hourly incrementals will be skipped during the denial period which defeats the goal of "24/7" incrementals.

Our current backup solution provides one set of 'day+time' for the full backup, and another 'time period' for 24/7 incrementals which makes it very easy to achieve this kind of schedule, but B&R's scheduling is quite different in this regard.

Surely there's a solution to this and I'm just missing something?

[PetrM]

Hi Jon,

Let's count your feature request for separate schedules for full and incremental backups, it might be an improvement in our future versions but I cannot comment on ETA. As a workaround, I can propose to start active full using PowerShell.

Thanks!

[Reboot]

Hi Petr, thank you for confirming this type of scheduling is not yet possible in Veeam B&R. I am quite surprised this cannot be achieved in Veeam when it has already been available in other backup solutions for years. It really should be added in a future release. I will look into your powershell workaround, but we will probably stick with our current backup solution until Veeam can implement this type of scheduling.

Is there an official forum or portal where I should submit this feature request, or you already handled it?

[Moopere]

@Reboot: You want an incremental every 1 hour, so you'd schedule for that. You also want a once a week active full at circa 6am ...

... this is the bit I'd query with you. Whats the problem you are experiencing? Do you want a different start time for the incrementals versus the active fulls? Or are you happy for both jobs to start at the same time (6am)?

With every backup software I can remember using, including Veeam, this situation would see the active full override the incremental. So, instead of an incremental at 6am you'd get an active full. Is this not what you want? Do you want an incremental at 6am which is separate from the active full which also runs at 6am?

Of course without more information I can't guess what you're doing - perhaps the incrementals get stored offsite in a different way to the fulls?

The thought occurs though that data wise, you're protected right? You want a data backup at 6am and you're getting that. In my mind it then (potentially) becomes a question of how you duplicate/store or otherwise manipulate that backed up data. If you need hourly exports of data then there must be a way to get this done - depending on what outcome you're looking for.

[Reboot]

@Moopere Fair question, the issue isn't having an active full replace the incremental because that would be perfectly fine for us. We are a small shop but with multiple servers. To keep the backup repository from being hammered we stagger our active fulls in a single day (Saturday), where one full job runs after another (with some buffer in between) and those jobs were manually scheduled after measuring how long each active backup takes, and it takes about 8-10 hours to backup everything in total. For ease of use, I like knowing when exactly this 8-10 hour window will occur so that I know when not to patch/reboot servers, or do testing work that requires reboots, during that time.

Veeam BR's full backup scheduling (with 24/7 incrementals) is automated which unfortunately takes away the granular control in this regard. If left to Veeam at its present state, this 8-10 hour backup window might balloon to a much larger and/or randomized window, and I wouldn't know offhand when it's safe to patch/reboot servers. I would be forced to look at the backup server first to make sure it's safe to reboot the other servers, which is just another task on top of a heap of existing tasks that I'd rather avoid. Backups imo should be as close to "set and forget" as possible, and to also be as efficient as possible in regards to time.

Admittedly, I haven't done much testing with Veeam jobs so maybe with trial and error I could eventually get close to this type of schedule? But it would just be a lot easier if a future release of B&R could have this type of scheduling available out of the box, like many other backups apps already do.

[Moopere]

I have the problem you're describing as well. I spent a fair bit of time a few years back when first moving to Veeam from other products, primarily Backup Exec. After all this time I've sort of got my head around it, but Veeams chosen method of scheduling is still not that flexible in my mind. I seem to spend most of my time fighting it and working around it rather than with it.

Having said that, there are inherent dangers in always assuming that incrementals are going to be shorter in duration than fulls. Under the right conditions an incremental _is_ a full. Minimum size of an inc might be 1 byte, maximum size could be everything.

Perhaps I gave in to reality on this, or, more likely, I gave up fighting Veeams way of doing this stuff. My main concern with backup time windows is dumping change from production systems. After that, when the data is safely on the backup machine I try to manipulate that data without interrupting the production systems. I tend not, therefore, to use active fulls. Synthetic fulls or even continuous inc's work pretty well in conjunction with copy jobs. So, live backup data might be a continuous inc and throughout the week various copy's are made of those systems for offsite storage - essentially these copy jobs are synthetic fulls going to different media.

Over the weekend when production systems are at their lowest use we'll do integrity checks and compression and whatnot. Compression of the continuous inc jobs in particular thrashes the heck out of the backup server and needs to be done serially, not concurrently which in turns puts pressure of the likely start time of these jobs which in turn essentially mandates when the 'normal' backup job will be run (as there are not separate schedules).

Spend some time on a sandbox setup of Veeam and you'll eventually get where you want to be - but yes, its quite a learning curve coming from a different and more traditional backup system

[BackupBytesTim]

I will say coming from other software as well, there's a lot about Veeam, as in nearly everything, that took adjusting to, as it seems designed from the perspective of backing a company's entire infrastructure at known points in time. Whether that infrastructure is a rack with a couple servers on it, or an entire data center. It's meant to back that up at a known time, and a consistent time across the entire environment such that you can restore the entire environment. Anything added since then, like backing up individual workstations or backing up different components with different schedules or backing up things on an actual custom schedule, all seem like an afterthought, as another user (who I won't name) described to me, "slapped on with bubblegum".

I too wish Veeam had proper flexible scheduling options like other software has, had what seem like basic features like automatic retries, the ability to back up a workstation more than 1 time a day (really? my personal computer can back up every hour using the free built-in software). And from a management perspective Veeam isn't really intended for remote management, and the setup tasks needed to actually back up a computer, whether that's a workstation with an agent, or the oh so unnecessarily complicated VBR server, are way more elaborate and time consuming than anything else I've ever used. I've grown accustomed to a lot of it, but the simple fact that Veeam is actually something that we have a team of people to work on a daily basis to maintain is troubling to me as it definitely isn't "just working" as Veeam's marketing team is so insistent on being the case.