Best way to configure quarterly backup copy’s ?

[AKSI]

Hello,

With some of our servers I would like a backup copy every Quarter, as an addition to our regular backups.

The current configuration is that a copy job is scheduled to “Copy every:” 90 Day at 01:00
The job contains one server added by Backup job and has “Restore points to keep:” on 4
So I should have 1 full and 3 incrementals going back for a year.
Data transfer is direct and schedule Any time.
The file is copied to local storage by local proxy.

Key is to minimize impact on the resources (disk space and cpu) that's why i've configured copy jobs and not backup jobs/ active fulls/archival purposes
Problem is that je job only creates 4 empty files, 1 vbk and 3 vib all 16.500KB in size.
What is wrong in this configuration?

[Shestakov]

Hello,
Your configuration looks fine in general.
Probably the problem is that your source backup job doesn`t run. Is it scheduled to run periodically and works fine?
Thanks.

[foggy]

What error/warning messages do you have in the backup copy job session log? It cannot have successful status if valid restore points are not created.

[AKSI]

Hello,
Your configuration looks fine in general.
Probably the problem is that your source backup job doesn`t run. Is it scheduled to run periodically and works fine?
Thanks.

The original job that is added in the copy job runs daily with no issues at all.

What error/warning messages do you have in the backup copy job session log? It cannot have successful status if valid restore points are not created.

The first run has an end time of 06:00:39(+90) so it runs for 90 days and has status "Initial copy did not complete, and will resume on the next copy interval"
subseqent tasks run for 10:32:18(+24) and end with status "Task has been cancelled"

The active status is always on pending. With message waiting for new restore points.
But this copy job runs every 90 day's and the daily job, every day so there should always be a new restore point..

[veremin]

Initial copy did not complete, and will resume on the next copy interval

The backup copy job was unable to finish processing during initial run, the missing data would be transferred during subsequent run (90 days after initial run).

Task has been cancelled

It seems that source backup job took place, and backup copy job has been canceled due to that.

The active status is always on pending

With 90 day sync interval backup copy job will be in the idle state most of the time.

Thanks.

[foggy]

You should allow it to run longer during the first sync, so that it could copy all the data (or use seeding).

[AKSI]

You should allow it to run longer during the first sync, so that it could copy all the data (or use seeding).

Doesn't the job have 90 day's to complete when that is the interval?
I just created a new copy job as a test, and the result was the same. I selected the daily job as source interval set to 1 day.
a .vbm and .vbk (16.500KB) file are created But then the job go's to Pending with status No restore points found.

Im expecting the job to fill that .vbk imediately and than after 90 day's create an vib and merge the 2

All my other copy jobs are seeded offsite jobs these run as expected, so i would expect similar behaviour on a local copy job

Reason i don't use seeding is that i recall seeding is only possible with a vbk that is not part of a chain, so i can't just copy the recent vbk from the regular backup chain.

[veremin]

Doesn't the job have 90 day's to complete when that is the interval?

Most likely, the source backup job took place, and backup copy job has been interrupted due to that.

I selected the daily job as source interval set to 1 day.

Were there points created by source backup job within the specified interval. Haven't you tried to use "Sync Now" option?

[Shestakov]

Reason i don't use seeding is that i recall seeding is only possible with a vbk that is not part of a chain, so i can't just copy the recent vbk from the regular backup chain.

It doesn`t matter if the .vbk is a part of a chain or not. You can seed the most recent .vbk and backup copy job will work fine. Thanks.

[foggy]

To be more precise, seeding is possible with any valid forward incremental chain. So no need to take a full from it, just use the entire chain to map the job to.

[AKSI]

It's been a while sinds i looked at this had to upgrade all our servers to V8 first

But problem found: It has to be to a different repository than where the source backup is written to!!

What makes sence in a lot of configurations, but not in this case.
i alway configured the same local repository (server only has 1 local and 1 offsite) because it's just an extra backup that might come in handy sometimes all offsite backups are run with other jobs.
Now i've configured a second repository on the same nas Changed the copyjob and it started creating/filling the vbk immediately

[Shestakov]

Indeed there is a restriction of using same repository for the backup copy job, because it`s not considered as the best practices and contradicts the initial purpose of backup copying.
In your case, you will have both copies on the same NAS, what is not the great in terms of data protection. I`d suggest to backup copy offsite, to tape or to a cloud.
Thanks!

[AKSI]

Indeed there is a restriction of using same repository for the backup copy job, because it`s not considered as the best practices and contradicts the initial purpose of backup copying.
In your case, you will have both copies on the same NAS, what is not the great in terms of data protection. I`d suggest to backup copy offsite, to tape or to a cloud.
Thanks!

I understand the thought behind the decision to do so.. but in this case it was hard to find out why it didn't work. An error/warning or grayed out during config would be better. Now everything configures fine but just sits there generating a warning every 90 days.

I'm using backup copy in this case to run jobs to create a quarterly backup going back for about a year as an addition to regular en offsite backups.
The reason for this configuration is to save disk and minimize resource impact, witch is perfect this way
My off site backups are run with different copy jobs so the overall configuration complies with the 3,2,1 strategy

thanx everybody for the support

[Shestakov]

Thanks for the feedback. It makes sense to warn users beforehand.
Also, in your case instead of creating backup copy job on the same target, you can just make another backup job to run quarterly.

[ACC]

Indeed there is a restriction of using same repository for the backup copy job, because it`s not considered as the best practices and contradicts the initial purpose of backup copying.
In your case, you will have both copies on the same NAS, what is not the great in terms of data protection. I`d suggest to backup copy offsite, to tape or to a cloud.
Thanks!

I can understand that Veeam makes choices to guide inexperienced administrators to a solid backup strategy, in my opinion it also creates artificial limitations for those who wants / needs to build a backup solution that doenst adhere to the “Veeam vision”.

For example one of our customers prefers to have the nas do the copying, because the nas doest it for “free”, where as Veeam is burning the expensive resources of the cluster to copy to a secondary storage device. Still we have Veeam burn resources for a copy job to have gfs available to meet the retention requirements. I would like to have the option to use gfs on the regular backup job.

Thanks for the feedback. It makes sense to warn users beforehand.
Also, in your case instead of creating backup copy job on the same target, you can just make another backup job to run quarterly.

In my opinion your suggestion has some downsides. For one, the backup window have to fit an additional backup run. Secondly, it puts the entire production environment through an extra backup cycle.

I would suggest to keep using a copy job and depending on how big the backup is and how much data is changed between two quarterly backups the copy cycle is picked that it completes before the next backup starts, my personal preference is have the copy cycle on a weekly cycle so the data chunk is relative small.

[foggy]

I can understand that Veeam makes choices to guide inexperienced administrators to a solid backup strategy, in my opinion it also creates artificial limitations for those who wants / needs to build a backup solution that doenst adhere to the “Veeam vision”.

No one prevents you from creating another folder on the same NAS and make it a target repository for the backup copy job. Allowing backup copy within the same repository could result in backup copy copying backups created by itself and subsequent total mess.