Copy interval has expired Incremental copy was not processed

[albertwt]

Hi All,

Why is that when I still got enough disk space in the Backup Copy (Secondary), the backup copy job still failed with the below error:

Copy interval has expired, Incremental copy was not processed during the copy interval

Some VMs were not processed during the copy interval
Backup location [E:\Backups] is getting low on free disk space (628.4 GB free of 13.5 TB).

Thanks in advance.

[foggy]

The message itself means that the job didn't get enough time to copy all the required data within the copy interval. What are the job interval and scheduling settings?

[albertwt]

The message itself means that the job didn't get enough time to copy all the required data within the copy interval. What are the job interval and scheduling settings?

1 copy everyday starting at 10:00 AM and the interval is continuously.

[veremin]

That means that one day is simply not enough for the backup copy job to process all of the changes generated. Have you thought about increasing it? Thanks.

[albertwt]

OK, do you mean by changing it from:

[Gostev]

If you are doing full (initial) pass without seeding, then you can just try leaving everything as is: the job will finish transferring full backup, and incremental backups should be fine since generally they are at least 10 time smaller. You can check out the job report to estimate how much more time is needed to complete full backup transfer.

[bryan3636]

I don't understand why copy even uses an interval. If there's new data to copy, then just start copying. Don't stop until everything has been copied. It it wasn't for me going over WAN I would think xcopy does a better job than veeam's copy. I'd love to learn why I'm wrong.

[Gostev]

Because it's not just a copy of existing backup files, like xcopy - Backup Copy allows you to pick and choose only selected VMs from different jobs. And "don't stop until everything has been copied" approach is simply not suitable for an enterprise IT that needs to ensure offsite RPOs are met.

That said, I've long wanted to add basic, "dumbed down" mode for Backup Copy jobs that basically repeats xcopy and only copies entire backup files - this will allow some major simplification at the cost of major functionality loss, but it seems that quite some customers just want something simple like this.

[JaySt]

That said, I've long wanted to add basic, "dumbed down" mode for Backup Copy jobs that basically repeats xcopy and only copies entire backup files - this will allow some major simplification at the cost of major functionality loss, but it seems that quite some customers just want something simple like this.

i agree, and i can confirm the request for simplification. Almost every customer has difficulty understanding copy job intervals and scheduling of it. This tells something about the current implementation in my opinion. People seem to expect a simpler approach. I don't see many users(not yet) think of configuring things in a way SLAs are enforced in a strict/enterprise way. But that could also tell something about the type of users i get to deal with

[ober72]

I agree fully with JaySt, it seems people have a hard time understanding this. I keep getting the question, can't it just copy today's backups until finished. Of course the error email also does not help as it seeds panic

[BGA-Robert]

Yes, I'll take the dumbed down version too. Meeting an Enterprise RPO is only one aspect of what's trying to be accomplished with a backup copy job and I'm not always looking to be shoe-horned into this functionality. Lack of flexibility with backup copy scheduling can be very frustrating

[dellock6]

But whatever is the approach, if a backup copy cannot be completed in a given interval, why are you configuring that interval? It will never be completed regardless the software uses xcopy or the native backup copy job... I think you have better chances to complete a copy without raw xcopy that has no data reduction capability. Xcopying daily when the infrastructure only allows you to do it every three days for example, is non-sense to be honest.

[albertwt]

Because it's not just a copy of existing backup files, like xcopy - Backup Copy allows you to pick and choose only selected VMs from different jobs. And "don't stop until everything has been copied" approach is simply not suitable for an enterprise IT that needs to ensure offsite RPOs are met.

That said, I've long wanted to add basic, "dumbed down" mode for Backup Copy jobs that basically repeats xcopy and only copies entire backup files - this will allow some major simplification at the cost of major functionality loss, but it seems that quite some customers just want something simple like this.

Selecting a specific VMs for the Backup Copy job is the nicest thing that I like so that I do not have to copy the whole backup job.

[veremin]

Selecting a specific VMs for the Backup Copy job is the nicest thing that I like so that I do not have to copy the whole backup job.

Thinking aloud - with dumbed down mode (assuming we had one), it would be only possible if you're utilizing per-VM chains. Thanks.

[dellock6]

Thinking aloud - which you should anyway, as there are really not that many reasons to keep using the monolithic files

[albertwt]

Luca,

So for the Backup copy job, can I utilize per VM backup job chain even if I'm not using the Dedupe storage system as the Backup Repository ?
What's the benefits ?

[mkretzer]

The performance of per-VM is SO MUCH BETTER especially for synthetic operations.

The downside is that if you have many VMs (we have about 1400) you can get deadlocks and other problems which in our environment lead to defective backup chains.

This should be fixed in 9.5 according to support!

[albertwt]

Mkretzer,

What does it means by "synthetic operations" is it the merging of the backup chains into the VBK file on both Reverse & forward incremental ?

[mkretzer]

Yes exactly...

Gesendet von meinem Nexus 6P mit Tapatalk

[foggy]

So for the Backup copy job, can I utilize per VM backup job chain even if I'm not using the Dedupe storage system as the Backup Repository ?

Per-VM backup chains setting can be used for the repository of any type.

[JaySt]

But whatever is the approach, if a backup copy cannot be completed in a given interval, why are you configuring that interval? It will never be completed regardless the software uses xcopy or the native backup copy job... I think you have better chances to complete a copy without raw xcopy that has no data reduction capability. Xcopying daily when the infrastructure only allows you to do it every three days for example, is non-sense to be honest.

That's true, in theory. What's your take then, on why users could get confused by copy job process implementation as it currently is? I think it's the interval itself. Back-up jobs for example are scheduled with a start time, but no configured duration (or interval) either. Maybe users expect the same from a copy job: 1)Start it at set time, just run and do what i configured it to do 2) finish when you finish and 3) i'll monitor if it takes to long , just like with my back-ups. 4.) oh, and when the next copy job scheduled start kicks off , and the last didn't finish just yet, just say "job already running" without interupting (just like back-up jobs) which will show up in my reports.

Maybe lots of disadvantages....but i still see a "dumbed down" version(as an option) as a welcome feature.

[tsymons@ventra.us]

These frustrate me too. I just want a job that I can configure to copy offsite on the weekends and not get useless error messages in my inbox. I just want to know when it's done. Please add a way to configure this.

[foggy]

Hi Tom, what kind of messages are you getting?

[tsymons@ventra.us]

I just looked at the error message again. I think I just have something goofy going on. My copy job is allowed to run from 12am saturday morning to midnight sunday night. At 12:00:08 AM Saturday I get an email ever week that the job failed: "Incremental copy was not processed during the copy interval". The job then restarts sometime after that and finishes. Perhaps my problem is different.

[foggy]

Your issue looks more like this one, so I recommend to contact support after reviewing the referred thread.

[itrabbit]

I would really like the option to just copy backup until complete or an option to continuously copy. i.e as soon as a new backup is found it will upload until complete.

I wanted to set my copy to copy every 1 hour any new snapshots, if it finds one it starts copying, if it doesn't it will check the following hour. However, I am uploading over the WAN and if a new backup occurs the time to upload is 4 hours.

While I understand RDOs and all that enterprise nonsense, if its in the middle of copying a backup, don't stop just continue and skip the next hour.

While you might say just set your copy interval to 5 hours. However, it must wait 5 hours to recheck again? and even then the new backup occurs it still could be in the middle or towards the end of the 5 hours, so it will get to the 5 hour mark and cancel it again.

I don't know why Veeam hasn't implemented, a simple check box "Continue copy even if next next interval is reached".


Please

[kubimike]

Hello, Im hoping someone would help me think through why I have a failed job. Perhaps a sync issue and just let it run, next job might be OK?

job details:
Copy Every: 1 Day 3:30AM
Schedule: 3:00AM - 11:59AM Everyday of the week.

From the looks of it the copy job is starting a new interval right in between the job.
Here are two pictures from the failed job.



Successful job retry?

[veremin]

Backup job job failed to process all source VMs, as a result the given error was generated. During next interval the job managed to catch up. Thanks.

[paallergy]

Simplified Backup Copy Job Request:
- Remove copy interval
- Start backup copy job after backup job finishes
- Continue backup copy job until job is finished
- Backup copy job still subject to network throttling
- Backup copy job still subject to schedule

Keep full options (including copy interval) for those who still need them

[veremin]

Your request has been noted. There are plans to add something similar down the road, so stay tuned.