Backup Copy conumdrum

[rogerdu]

I am trying to setup a schedule whereby I get incremental backups 6 days of the week and do a Backup Copy on the 7th..

The day I want to do the Backup Copy (well 2 of them) is Saturday with a window from Saturday evening until Sunday at Midnight.

What is happening is that the backup copy starts Sunday evening... How can I force it to start on Saturday evening?

Would this be a case where I set the Copy every: value to less than 7, but ensure that I set a window that starts on Saturday at 7:00 PM (or whatever time I want it to start)???

Thanks in advance,

Roger

[veremin]

You can set copy interval ("Copy every") to 7 days, and prohibit backup copy job execution during all days, but Saturday, using Backup window. Otherwise, you can PS script into use in order to execute backup copy job, once the source backup job is finished.

Thanks.

[rogerdu]

That's how I have it setup right now, and it doesn't start until Sunday evening...

The only change I made is to open the window one hour earlier than the start time (for Dev, start time is 7PM, Window is Sat 6PM to Sun 23:59, for Prod, Window is Sat 10PM to Sun 23:59).

[veremin]

What is it doing during Saturday? Sitting in the "idle" with "waiting for new restore point" status? Or something different? What happens if you try to force its execution at this time by using "Sync now" option?

Thanks.

[rogerdu]

Yes, it sits Idle, and since I'm not in the office, I have no access to force a Sync Now... (I'm on contract so would have to arrange it with my customer)... even from the first day this was setup I've not been able to force it to run Saturday PM though...

[veremin]

You can write a custom script that forces backup copy job to start synchronization interval and it schedule(via Windows Schedule on Saturday evening. Or even schedule the script to run as a post job activity, so that, it will be executed, once the source backup job is finished. And, then, see whether this solves the issue or not.

If doesn't help, you can open a ticket with our support team and let them confirm your environment.

Thanks.

[rogerdu]

So, if I have a definition already and I want to force it to run at a specific time, the "script" could be as simple as a file "D:\Scripts\Start-Prod-Full.ps1" that contains the lines:

Code: Select all

Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue
Sync-VBRBackupCopyJob -Job "Prod - Full"

And in the Windows Task Scheduler, define a task to run it at 7PM Saturday evening.

[veremin]

Sorry, I must have forgotten to provide a link in my previous post. This is the script I was talking about. This script can be either scheduled via Windows Scheduler or set as a post job activity.

Thanks.

[rogerdu]

Sorry, I must have forgotten to provide a link in my previous post. This is the script I was talking about. This script can be either scheduled via Windows Scheduler or set as a post job activity.

Thanks.

I just saw that... thanks

[veremin]

Let me know how well it goes. Thanks.

[rogerdu]

on the same vein (well kinda)...

The Incremental job (regular backup job) it shows 17 clients, but on the backup copy job (which uses the incremental job as its "source") it only shows 4 clients... Is this something I should be concerned with? (IE will the full 14 clients still backup), or is there a way to force the full list to be in the display?

[foggy]

Roger, what "clients" are you referring to here?

[rogerdu]

sorry wrong word... the Incremental backup job lists 17 VMs and the Backup Copy job is only listing 4.... The last backup Copy run didn't have time to copy all 17 VMs worth of data before the window closed... thus the reason I want to have things start on Saturday insted of Sunday...

[veremin]

In fact, the backup copy job doesn't t copy backup file as a whole, but rather synthetically creates required restore points in "target" location from VM data in source backup repositories. So, the number of restore points the source backup job has shouldn't coincide with the number of restore points of backup copy job, as everything depends on specified "Copy interval", which, in general, tells the backup copy job how its restore points should be created.

Thanks.

[rogerdu]

In fact, the backup copy job doesn't t copy backup file as a whole, but rather synthetically creates required restore points in "target" location from VM data in source backup repositories. So, the number of restore points the source backup job has shouldn't coincide with the number of restore points of backup copy job, as everything depends on specified "Copy interval", which, in general, tells the backup copy job how its restore points should be created.

Thanks.

So if I'm understanding this right, once I successfully Sync Now on Saturday (this weekend), by having the interval set to 7 days, from here on out the Sync should happen every Saturday and use the latest restore point (which would be Friday Night/Saturday AM).

Also, there is no actual data transfer from the VM (or at least no snapshot then delta then transfer), its all done on the backup Proxy system (which in this case is a different system than the backup system).

The light is less dim...

[foggy]

the Incremental backup job lists 17 VMs and the Backup Copy job is only listing 4.... The last backup Copy run didn't have time to copy all 17 VMs worth of data before the window closed...

Still need to clarify: are we talking about VMs backed up in the job or restore points these VMs can be restored to? The number of backup copy job restore points is independent from the source backup job and depends on its own retention settings, while the number of VMs contained in each restore point should reflect the same from the source backup job (given that this backup job is specified as the source for the backup copy job and there are no exclusions configured). If backup copy job is not able to process all the data within the allowed backup window, you may want to consider performing initial seed.

So if I'm understanding this right, once I successfully Sync Now on Saturday (this weekend), by having the interval set to 7 days, from here on out the Sync should happen every Saturday and use the latest restore point (which would be Friday Night/Saturday AM).

Correct.

Also, there is no actual data transfer from the VM (or at least no snapshot then delta then transfer), its all done on the backup Proxy system (which in this case is a different system than the backup system).

Correct, as Vladimir has explained above, the actual production VM is not touched by the backup copy job. VM data is synthetically retrieved from its (previously created by a regular backup job) backup file and transferred to the target repository.

[rogerdu]

Question on this as it seemed to work, althoug my proxy server ran out of resources... so I increased the memory to 12G (from 4)...

There are 3 settings for the Schedule:

• Job Pane - Copy Every XX yyy at TIME
• Target Pane - select Schedule - Weekly Backup DAY / TIME
• Schedule Pane - Window (start DAY / TIME through to end of window

I have all 3 set to 06:00 Sunday for my Prod backups, and all 3 set to 06:00 Saturday for my Dev backups... am I trying to do too many things at once?

Does the "Weekly Backup" use resources at the same time that the transformation is trying to take place? I don't find that the documentation is very clear on what these various "schedule" options do...

[foggy]

Please review the following sections of the user guide for details on these options, should clarify what each of them is intended for (as they have completely different meanings and together comprise the frequency of the backup copy activities and allowed execution time):

[*]Job Pane - Copy Every XX yyy at TIME

Synchronization interval

[*]Target Pane - select Schedule - Weekly Backup DAY / TIME

GFS retention - weekly backup cycle

[*]Schedule Pane - Window (start DAY / TIME through to end of window[/list]

Backup copy job window

[rogerdu]

I have read those sections... that's why I posted here... I'm still confused, and the documentation did not help.

I want a weekly backup to be created in the repository I have created. I would like the activity to start at 06:00 Saturday and finish before 21:00 on the same day. I would like the full images to be retained as such: 5 weekly backups, and 13 monthly backups. I would also like these backups to be based off the incremental backups that start at 21:00 daily, roll up on Friday to a synthetic full and are retained for 2 weeks (this part is working fine).

While I was able to get the copy to start by using a script to force the resync, I then ran into contention for resources... I have tripled the memory on the VM that is my proxy server.

To date, I have not been able to schedule the above GFS Copy Backup consistently. Yes I have read the documentation.

What am I doing wrong?

[foggy]

Were you able to get at least one full successful restore point at the secondary target repository? How many backup/backup copy tasks are performed simultaneously by the said proxy?

[rogerdu]

Were you able to get at least one full successful restore point at the secondary target repository? How many backup/backup copy tasks are performed simultaneously by the said proxy?

Yes. The Sync Now activity had the backup copy starting at the correct time (at that point, 19:00).

The problem occurred because I had 2 backup copy jobs, then 3 regular backup jobs processing by the time the system decided to error out on the resource contention problem. The backup definitions have 9, 17 and 21 VMs in them (sizes of .56 2.9 and 4.1 TBytes of data respectively), do incremental backups 7 daysof the week, and roll up the synthetic on Friday. Only 2 of these (the larger 2) have backup copy jobs that were done Saturday. The proxy server only had 4 GBytes of RAM associated with it, 1 production GbE NIC and the required disk storage to house the backups. These filesystems are on an EVA P2000 which is SAN attached to the VM as a Mapped RAW LUN.
I've re-scheduled the copy jobs to happen between 06:00 and 21:00 (one Saturday and one Sunday) so they do not impact the incremental backups... I've also scheduled a one time task to Sync Now at 06:00 Saturday and Sunday to re-sync the start times to then. Hoping this all works as I think it should...

[foggy]

The problem occurred because I had 2 backup copy jobs, then 3 regular backup jobs processing by the time the system decided to error out on the resource contention problem.

You may want to limit the maximum number of concurrent tasks assigned to the proxy server to avoid contention of resources.