Timing of Backup Copies

[sosborne]

Background - When I first implemented our Veeam B&R I never quite got the hang of backup copy jobs as a means of "archiving" using GFS. My problem was getting the timing of the restore points right as they would never happen quite when expected. So I ended up doing a more custom solution which involved initiating backup jobs with active full RP's by script/task. Very convoluted but it worked. Recently I experienced some difficulties with the offsite copy which I will not go into here. Veeam's support were consulted and a workaround was found but the ultimate recommendation was to use backup copies for long term retention.

Issues - Since then I revisited backup copies to try and get a GFS retention in place with the assistance of one of Veeam's support guys who was again thorough. But we did run into the same timing issues again. Basically I want to take a full weekly restore point from a Saturday and a monthly from the 1st each month. It was recommended to have an interval at 00:00 which I did but we found that unless the backup job was also at 00:00 then both the weekly and monthly restore points have time stamps of the day before despite running on schedule. But to be honest it's not really reasonable to have all backup jobs running at the same time. So the only other way seems to date the GFS RP's to be a day later than required (so Sunday and 2nd). The Veeam guy also echoed this. I have read all the Veeam docs on Restore Point selection so the previous day rings true here, but when talking about Active Weekly Full backups it mentions that if its 00:00 its created on the selected day (only if the backup job is the same time in my experience). Alternatively match the interval to the backup job time (a test job at 1:00 and an interval at 1:00 were ok).

So is it best practice to schedule RP's for GFS on a Sunday and 2nd of month if you want the RP's actual time stamp to be the Saturday and the 1st or match the interval to the original job? And how reliable is this given occasional timing issues with backup jobs? I need precision with this given I work in the financial sector and we need to keep month ends and tax year ends for sometime.

I would love to get consistency on this because it shouls be low effort, and give much more time and flexibility with the backup window. Not to mention reduce some complexity in our setup.

[foggy]

Hi Simon, while it is actually recommended to have all backup jobs run at the same time and let automatic resource scheduler to schedule tasks optimally (unless you have some specific requirements in this regard), I think what could help in case you still want to have them scattered in time is using forward lookup mechanism in backup copy. Haven't you tried it?

[sosborne]

BTW in your first sentence do you mean backup copy jobs?

When it comes to critical customer facing VM's its definitely good to have some control over it as we tend to have a specific window after a batch process. Also, if there are any lengthy backups particularly when talking about fulls it can tie up resource so control is handy (especially if it has multiple virtual HD's).

I don't have that setting currently set. I will try it and see how it goes in testing.

Although to be honest with my current backup copy jobs (for live backup jobs with Simple Retention only) and the current interval set to 00:00 across the board and backup jobs at different times the increments copy shortly after the backup jobs it is only when the fulls are scheduled or the GFS retention is being tested that the restore point comes from the previous day

[foggy]

I meant both since the automatic scheduler does its job. But it's of course up to you - setting at least the backup copy to start a few minutes after the corresponding source backup job is a good practice since it starts copying backup immediately after they appear on the source.

[sosborne]

Any idea why the full/GFS restore points seem to behave differently?

[foggy]

What do you mean?

[sosborne]

Although to be honest with my current backup copy jobs (for live backup jobs with Simple Retention only) and the current interval set to 00:00 across the board and backup jobs at different times the increments copy shortly after the backup jobs it is only when the fulls are scheduled or the GFS retention is being tested that the restore point comes from the previous day

@ Foggy - It was in reference to this comment that the intervals on my other backup copies are backing up as expected but the full restore points are from the previous day. As has been the case with my testing GFS jobs where the GFS active fulls also back up from the previous day.

I will be testing that other setting this weekend.

[foggy]

I'd suggest showing the behavior to our engineers, if it persists, could be several things, but hard to investigate via forums.

[sosborne]

Hi Simon, while it is actually recommended to have all backup jobs run at the same time and let automatic resource scheduler to schedule tasks optimally (unless you have some specific requirements in this regard), I think what could help in case you still want to have them scattered in time is using forward lookup mechanism in backup copy. Haven't you tried it?

I have had the opportunity to use that registry tweak for a couple of weeks and it is producing the weekly GFS copies on the intended day E.g a weekly GFS is required on Saturday so the interval is 00:00, the backup job 17:00, and the GFS RP full backup copy will happen just after and be sourced from the same day as the backup job. I don't see why it should be any different for the monthly but we will see. Its much better than trying to put them at the same time or date the GFS a day ahead (as I feel that is more prone to issues from other errors). It will also allow me to be particularly precise when it comes to the end of month. So kudos.

Now I just have to gradually merge my archive jobs and backup copies, rearrange the repositories, and slowly phase out the archive job RP's