Hello,
when a Copy Job fails for several machines only, you can only run an Active Full for the whole job to restart the chain.
If the job contains many machines it is very time and resource waste.
I.e. imagine that your destination is an immutable cloud storage: you'll need to upload again all your machines, instead of upload only the corrupted ones.
So, I am requesting to be able to run an Active Full Copy for specific machines only, not for the whole job.
Thank You and Best regards
-
danilo.brambilla
- Novice
- Posts: 8
- Liked: 2 times
- Joined: May 24, 2019 1:56 pm
- Full Name: Danilo Brambilla
- Contact:
-
vnikiforov
- Veeam Software
- Posts: 148
- Liked: 51 times
- Joined: Aug 17, 2022 5:03 am
- Full Name: Vladimir Nikiforov
- Location: Romania
- Contact:
Re: Feature Request: Ability to run Active Full for single machines on Copy Jobs
Hello, Danilo,
Active full for individual workloads already exists for regular backup jobs, while on a backup copy job active full is still job-wide.
Can you please share what scenario you are trying to avoid or resolve?
So, if we are concerned about source backup vbk\vib files deliberate corruption (on binary level) backup copy will not even copy these files to the immutable object storage repository, as CRC check will fail, while the other machines in the job keep copying normally.
And on the immutable repository itself, it is already impossible to change anything by design.
If, for some reason, you need to redo per machine active full, do that on the source side, remove the corrupted chain, and the copy job forwards only that machine's new restore points onward.
Backup copy moves just the changed blocks per workload, so you send one machine's data to the immutable repository rather than the whole job.
Active full for individual workloads already exists for regular backup jobs, while on a backup copy job active full is still job-wide.
Can you please share what scenario you are trying to avoid or resolve?
So, if we are concerned about source backup vbk\vib files deliberate corruption (on binary level) backup copy will not even copy these files to the immutable object storage repository, as CRC check will fail, while the other machines in the job keep copying normally.
And on the immutable repository itself, it is already impossible to change anything by design.
If, for some reason, you need to redo per machine active full, do that on the source side, remove the corrupted chain, and the copy job forwards only that machine's new restore points onward.
Backup copy moves just the changed blocks per workload, so you send one machine's data to the immutable repository rather than the whole job.
---
BR,
Vladimir
Veeam Software
BR,
Vladimir
Veeam Software
Who is online
Users browsing this forum: Amazon [Bot] and 182 guests