Good day, a customer of mines, called me to remark this fact.
Scenario:
VBR 12.3 and protecting vSphere environment, mostly using TAG based jobs (which I like very much too)
he has a repository hosted on an old DataDomain, and another repo hosted on a Linux Hardened Repo.
he is moving gradually (because the DD is slow) VMs from the DD repo to the hardend new one.
he has a job named JobVM-2DD which saves VMs with the vSphere tag "DD" on the Datadomain Repo
and another job named JobVM-2Apollo which saves VMS with the vSphere tag "Apollo" on the hardened repo.
Fact:
When he is ready to move one VM to the new repo he uses the "move backup feature" of Veeam. After the backup chain is moved to the new repo, he edits the JobVM-2Apollo removing the VM from the list of protected objects (automatically added by the Move process) and changes the vsphere tag of the VM from DD in Apollo. This runs smoothly with no issues.
Issue:
in some cases, he forgot to perform the last step and the VM still had the vsphere tag DD.
What's happened in this situation? The VM has been no longer protected, he (and me too) was expecting that in this situation the JobVM-2DD should have saved the VM anyway, by starting a new backup chain on the old repo on the DataDomain.
He would like to know why and I think it's an interesting situation to be put in evidence. Ok it's been a mistake of the Veeam administrator, but we are both curious why the old job is no longer protecting the VM.
(a case had been opened, #07592012)
P.S.: i always stress people that the VM protection status should be always monitored i.e. with ONE or other methods, in order to be always alert when a VM has no recent backup, for any reason it happened.
-
- Veeam Legend
- Posts: 143
- Liked: 41 times
- Joined: Sep 26, 2013 8:40 am
- Full Name: Alessandro T.
- Location: Bologna, Italy
- Contact:
Move Backup between Tag-Based jobs, unexpected behaviour
Alessandro aka Tinto | VMCE 2024 | Veeam Legend | VCP-DCV 2023 | vExpert 2025
blog.tinivelli.com
blog.tinivelli.com
-
- Veeam Software
- Posts: 2810
- Liked: 641 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Move Backup between Tag-Based jobs, unexpected behaviour
Hi Alessandro,
Thanks for the write-up and for sharing the case number.
Regarding this:
If you check the exclusions tab on the original job, the VMs that were under the DD tag should be present there, can you confirm?
I understand the situation and it can result in a blind spot due to a simple mistake like this. As a safety for the process, it might make sense to leave the newly added VM entries in the destination job and first re-tag the VMs, and then go back and remove the extra entries. This will NOT result in double-processing in the job (having both the VM added and the tag containing the VM), Veeam will only process the VM once.
I get the procedure, and think just switching the order of those steps saves a lot of headaches.
Thanks for the write-up and for sharing the case number.
Regarding this:
I think that this part of our User Guide was maybe missed, as one of the steps for Backup Move to a new job is "Excludes the selected workloads from being processed by the source job."The VM has been no longer protected, he (and me too) was expecting that in this situation the JobVM-2DD should have saved the VM anyway, by starting a new backup chain on the old repo on the DataDomain.
If you check the exclusions tab on the original job, the VMs that were under the DD tag should be present there, can you confirm?
I understand the situation and it can result in a blind spot due to a simple mistake like this. As a safety for the process, it might make sense to leave the newly added VM entries in the destination job and first re-tag the VMs, and then go back and remove the extra entries. This will NOT result in double-processing in the job (having both the VM added and the tag containing the VM), Veeam will only process the VM once.
I get the procedure, and think just switching the order of those steps saves a lot of headaches.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Google [Bot] and 7 guests