How to chain "Backup to Disk to antoher Disk" like "Backup to Disk to Tape" ?

[arec]

Hello,

we usually use Veeam to first backup to internal disks using a Backup Job, and then copying this to tape using a Tape Job, which is chained by "Secodary Target" in Backup Job and "Schedule">"After this Job" in Tape Job.

This always works absolutely perfect and reliable:
- Disk Backup runs at specified time
- When Disk Backup is completed, it calls the Tape Job wich starts without any margin for error.


Now we want to do the same, but with a NAS Storage as secondary target instead of a Tape.
I sadly can't figure out an absolutely reliable and simple way to do this.


These are the only solutions I'm aware of:

1. a second backup copy job
Positive:
- can be chained and runs reliable after first backup
Negative:
- pulls data from production servers and not from backup repository
- all settings from job1 need to be set and maintained redundandtly in two jobs (Credentials, Exception, App. Aware. Settings. etc.)

2. backup copy job:
Postive:
- pulls data from existing backups out of the repository
Negative:
- can't be directly chained to the Backup Job, even if linked as "Secondary Target"
- Instead it uses an interval which needs to specify a fixed starting time per day, or an hourly/minutely interval where the only timing control is restarting the Job manually at the desired time
- this interval gets easily out of sync, coping none or legacy backups to the second location, without sending a warning, counting this as "success" (because it successfully copied what was there at time of checking)
- it does not send mails after it has copied the backups, but instead when the interval ends


Is there any way to get rid of this 24h checking interval for Backup Copy Jobs, telling it to just start when the first backup job is done "after this job", like tape jobs do?
I found that a lot of our customers Administrators were not aware of this behaviour, and they were shocked to see, thier interval backup copys were not from todays backup but from yesterdays or even mixed. You have to look close every day to notice this delay.


Thank you!

[nmdange]

For Backup Jobs that start daily, you want the backup copy job interval to start at the exact same time as the backup job. The copy job will then start copying immediately after the backup job finishes. For backup jobs that run more than once per day, yes it can be tricky to get them to line up.

[arec]

Thanks for your Reply, but in my experience this sadly doesn't solve it.


Yes, this is about daily backups.

I have experienced Problems even when setting the interval start time to backup job start time.
This can still easily get out or sync.

Example:

You set both to start at 10pm.
- Backup Job starts to backup
- Copy Job starts to listen
- Backup Job finishes
- Copy Job finds new backups and copys them to second location

That's fine and how it sould work.


But if there is just a small interruption, it is out of sync:

- Backup Job starts to backup
- Copy Job starts to listen
- Copy Job finds yesterdays backups and copys them to the second location
- Backup Job finishes
- Copy Job doens't care about new backup and will copy them tomorrow

I'll bet, a decent amount of people reading this, who think "what's that guys problem?", actually have this issue without knowing.
You have to look close into the logs to notice this.

This can easily happen, even more if your second target are rotating disks.
This might be solveable for bigger companys with thier own Administrators, who look close everyday.
But for small companys, (which I have seen hundreds of) where someone without IT knowledge just checks everyday if the Backup says "success", there is now chance.


Setting the copy time earlier, leads to the same issue.
Setting the copy time after the backup job, can lead to the Copy Job copying half form today, half from yesterday, when the backup takes longer and overlaps.
Setting the copy time way after the backup Job, leads to a verry dangerous and unnecessary long delay for business critical data backup.
Setting the copy intervall to several times a day creates multiple customer irritating "Success" mails per day with 0byte backed up, also the sync is hard to control as there is no fixed start time.

In all cases there is this additional issue of the time when the success or failure message for Copy Jobs is sent.

I just can't believe, there is no way to hardly coded and reliable chain the Backup Copy Job to a Backup Job, like we can do with Tape Backups.
"Backup Job finished" > "Copy Backup" > "End Copy and send mail"
I'm sure this should be easily to implement, and helps a lot of People.

[foggy]

But if there is just a small interruption, it is out of sync:

- Backup Job starts to backup
- Copy Job starts to listen
- Copy Job finds yesterdays backups and copys them to the second location
- Backup Job finishes
- Copy Job doens't care about new backup and will copy them tomorrow

To avoid such cases, you can set the backup copy job to "look only forward" with the help of the BackupCopyLookFoward registry value. After that it will wait for the backup job to finish, new restore point to appear and then start processing.

[skrause]

For Backup Jobs that start daily, you want the backup copy job interval to start at the exact same time as the backup job. The copy job will then start copying immediately after the backup job finishes. For backup jobs that run more than once per day, yes it can be tricky to get them to line up.

That is not necessarily the case. Sure it makes it easy in terms of "file is copied right away," but there are cases where your backup infrastructure might not be able to handle the copy traffic running concurrently while other primary backup jobs are also running.

If your backup storage has relatively slow random I/O (and let's be honest, most people's backup repositories are configured for better capacity and sequential reads/writes, not random IO) and you are trying to write a backup to a repository at the same time as you are reading another one for a copy job, it will slow down both. And slowing down a primary backup job impacts your production systems, whereas a copy job that has its interval start staggered so that it doesn't run at the same time as any primary backup jobs won't.

[arec]

To avoid such cases, you can set the backup copy job to "look only forward" with the help of the BackupCopyLookFoward registry value. After that it will wait for the backup job to finish, new restore point to appear and then start processing.

Thank you, that's definitely one step into the right direction!

Where have you found this information?

[foggy]

It was first introduced in v8, here's the excerpt from the corresponding version's What's New document:

Forward lookup: Backup Copy jobs can now be configured to wait for the new restore point to be created by a primary backup job, instead of using the latest non-copied restore point already available. To enable the new behavior, create the BackupCopyLookForward (DWORD) = 1 registry value under
HKLM\SOFTWARE\Veeam\Veeam Backup and Replication key.