Skip to main content
  • EN

Another post about my favorite feature in v11: Hardened Repository. This time it is about the ability to change the expiration date of already immutable restore points. Veeam made this possible by using PowerShell. The corresponding command is: Set-VBRImmutabilityLockExpirationDate. This post is about how to use it.

Select the restore point you want to change immutability expiration date. To show all restore points of a specific VM in a job you can run for example:
Get-VBRRestorePoint -Backup immu_job_01 -Name VM02

Here backup job name is Immu_Job_01 and VM is called VM02. I will change the date for the first - the oldest - restore point in the list. To work with it I save it in $RestorePoint:

$RestorePoint = (Get-VBRRestorePoint -Backup immu_job_01 -Name VM02))0]

Show the current expiration date by running this command: $RestorePoint.getstorage().ImmutableTillUtc  
 

We see, current ImmutableTilldate is 1st October 2021. In my example I change the date to the end of 2030:

$ExpDate = Get-Date -Year 2030 -Month 12 -Day 31

Set-VBRImmutabilityLockExpirationDate -RestorePoint $RestorePoint -ExpirationDate $ExpDate  
 

 

Really simple, isn't it? When you are happy with it you can stop reading. If you now ask yourself whether this does destroy the entire immutability, read on.

What happens when the bad guy runs this command. For example:

Set-VBRImmutabilityLockExpirationDate -RestorePoint $RestorePoint -ExpirationDate $(Get-Date)

Good news: the guy will see this:

Okay, does not work! One reason for this: in v11 it is not possible to shorten the immutability period of a restore point. But: this is possible in v11a! It is still not possible to set any date before the current set. But you can reset to original date:

Set-VBRImmutabilityLockExpirationDate -RestorePoint $RestorePoint -ToOriginal  

(Note: I changed restore point t1] after the update to v11a)

If original date already passed, it will be reset to current date + immutable period of repository. So, to shorten the period changed before, go to original date and change to new desired date.

Currently it is not possible to reset the date to the original if it has been extended prior to v11a!

See my blog post for more details! It includes some details of description file on Linux.

 

This is such a cool feature, it definitely carries some risk if people are careless with their original configurations, but I just think it’s awesome that you could do temporary “legal holds” with this if necessary.

Great post.  I love this feature and we are starting to use it more and more.

Great function.

My first thought was, what if you select a date prior of the set expiration date…. Glad that this is not a security hole 😎

Great post.  I love this feature and we are starting to use it more and more.

Thanks! This feature is not only my favorite, it also is very popular with customers :smiley:

Great post @vNote42 !

Great function.

My first thought was, what if you select a date prior of the set expiration date…. Glad that this is not a security hole 😎

Yes, Security in Hardened Repo is absolutely consistent!

Awesome! Thank you for sharing @vNote42 

Great post @vNote42 !

Thanks @marcofabbri !

Nice post @vNote42! It is good to see the updates of v11a getting on work!

Added important information to the end of the post:

[update] Important: Currently it is not possible to reset the date to the original if it has been extended prior to v11a!

And a link to my current post about this topic with more detailed information.

When I try to Login Linux Repository as root and try to delete by executing #rm -rf backup, it says

operation not permitted , in fact tried from the account which was used to connect VEEAM backup. but the result is same.

 

from the root account when i format the /backup ( Linux Repo), then all the data’s got deleted. though i knows this is expected behavior.

after disabled root account as from SSH , disabled iDRAC  and etc, still is there any possible way for the attacker to gain the access and format the disk of Linux Repository ?

also what is preventing from shorten the date . i would like to know what mechanism use to prevent from the bad guy to not shorten the expire date. appreciate your support. 

@karthikkumar.thirukonda In order to delete immutable files with the root user, you would first have to remove the immutable flag with 'chattr -i'. But as you noted, nothing prevents you from formatting the whole volume.

Without root access via SSH or iDrac, nothing can happen to immutable backup files; except someone physically accesses the repository. Reducing the protection isn't possible from within Veeam. You can only extend the protection internal.

As noted by Regnor without SSH or iDrac access the repo server cannot be accessed.  In order to help further with the backup server you can enable MFA for the console and auto logoff as well to help.  Keeping the infrastructure off the domain or on a separate backup domain.

@Chris.Childerhose Thanks for the confirmation.

one more query, VBR backup and Linux Server if the bad guy change the date, date gets changes. but backed up files not getting expired / deleted which is immutable expected behavior. 

 

Technically, I want to know what service prevents and avoids data from expiring after date get changes. If there are no dependencies on a Linux repository server or backup server, Veeam backed up files from the location where the time and date stamps are counted.

If someone gets in and can change the date, then you have a bigger problem at that point.  The best thing would be if you have immutable backups onsite is to also have a copy going offsite to something like Wasabi.  This way you can also ensure that you can recover.

From what I remember I don’t believe changing the date affects Immutable backups but will be sure to search on this to give a fully accurate answer/confirmation.

If you check this link - Hardened Repository - User Guide for VMware vSphere (veeam.com)

Look at the first bullet that is in bold about Immutability.  Veeam indicates that it cannot be changed or deleted.  The only way to affect files would be to run the chattr -i command to remove the immutable flag but if they cannot get to your repo as noted data should remain safe.

Comment


Terms & Conditions