Comprehensive data protection for all workloads
Post Reply
perjonsson1960
Veteran
Posts: 556
Liked: 65 times
Joined: Jun 06, 2018 5:41 am
Full Name: Per Jonsson
Location: Sweden
Contact:

Moving backup back

Post by perjonsson1960 »

Folks,

I moved one VM from one backup job to another, with the corresponding linked immutable backup copy, and both were moved correctly.
Then I changed my mind, and wanted to move it back to where it was, and then it says that the backup copy already exists in the target folder on the hardened repo.
So, it seems that the first move didn't clean up everything in the old place. Is this a known issue?

Later, perhaps tomorrow, I will try to make my way into the very zoned in Linux server, where the hardened repo resides, and see if I can gather what was left behind.

Kind regards,
PJ
Brad.Barker
Product Manager
Posts: 206
Liked: 42 times
Joined: Nov 05, 2012 5:32 pm
Full Name: Brad Barker
Contact:

Re: Moving backup back

Post by Brad.Barker »

Hello Per! To clarify, you're saying that the source of the copy job was and immutable repository, and you ran a move operation and the backup data was still present in the backup copy repository?

If that is the case, then this is expected behavior as the backups are immutable and can not be deleted. Please see the relevant documentation here: https://helpcenter.veeam.com/docs/vbr/u ... positories

Hope this answers the your question!
perjonsson1960
Veteran
Posts: 556
Liked: 65 times
Joined: Jun 06, 2018 5:41 am
Full Name: Per Jonsson
Location: Sweden
Contact:

Re: Moving backup back

Post by perjonsson1960 »

Hello!

I didn't read the documentation carefully enough... I see that the old immutable chain ended up in the Orphaned node.
I thought that perhaps B&R would remove the immutability flag, and simply move the chain to the new place, and then set the immutability flag again.
But that is not the case. That explains it. Thank you! :)

Kind regards,
PJ
Mildur
Product Manager
Posts: 11604
Liked: 3263 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Moving backup back

Post by Mildur » 2 people like this post

Hi PJ,

We would never have such an option that allows the backup server to remove immutability from immutable backup files. Every malicious actor would be really happy if the backup server had permission to “manage the immutability flag”.

Immutability is always enforced by the underlying storage system — for example Linux with the filesystem i flag, or object storage with Object Lock. The backup server only tells the storage system how long the data should be immutable. Shortening that period is not possible, but extending it works.

Best,
Fabian
Product Management Analyst @ Veeam Software
perjonsson1960
Veteran
Posts: 556
Liked: 65 times
Joined: Jun 06, 2018 5:41 am
Full Name: Per Jonsson
Location: Sweden
Contact:

Re: Moving backup back

Post by perjonsson1960 »

Okay. So it is not the backup server that removes the flag when the retension period has passed, it is the underlying storage system, in our case Linux?
Mildur
Product Manager
Posts: 11604
Liked: 3263 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Moving backup back

Post by Mildur »

Yes, you are right.
With a Hardened Repository, we use our own local service on the hardened repository to calculate when the Linux i flag must be removed.
But the backup server cannot reduce the immutable time or remove the i flag before the immutability period is over.

Best,
Fabian
Product Management Analyst @ Veeam Software
perjonsson1960
Veteran
Posts: 556
Liked: 65 times
Joined: Jun 06, 2018 5:41 am
Full Name: Per Jonsson
Location: Sweden
Contact:

Re: Moving backup back

Post by perjonsson1960 »

Thank you! :)
Post Reply

Who is online

Users browsing this forum: Amazon [Bot] and 144 guests