Discussions related to using object storage as a backup target.
Post Reply
lolbebis
Enthusiast
Posts: 26
Liked: 5 times
Joined: Feb 26, 2020 9:33 am
Full Name: Mattias Jacobsson
Contact:

Immutability settings

Post by lolbebis »

If I want to protect my backups from ransomware I want to copy them to S3 storage directly after they are created, with immutability enabled.
If I copy my "backup copy job" to S3 with 2 restorepoints and 3 quarterly, what do I set the immutability time to in days?
If I set the immutability to 5 days? Then Veeam can't replace them? or would i choose 2 days for the immutabilty.

What would be the best setting to protect the latest backups with immutabilty?
wishr
Veteran
Posts: 3077
Liked: 453 times
Joined: Aug 07, 2018 3:11 pm
Full Name: Fedor Maslov
Contact:

Re: Immutability settings

Post by wishr »

Hi Mattias,

Could you please tell us what is your copy job configuration, e.g. mode, retention, etc.?

Thanks
lolbebis
Enthusiast
Posts: 26
Liked: 5 times
Joined: Feb 26, 2020 9:33 am
Full Name: Mattias Jacobsson
Contact:

Re: Immutability settings

Post by lolbebis »

Hi!
First image is the backup job, and second image is the backup copy job.

Image
Image

Thanks
wishr
Veteran
Posts: 3077
Liked: 453 times
Joined: Aug 07, 2018 3:11 pm
Full Name: Fedor Maslov
Contact:

Re: Immutability settings

Post by wishr »

Thank you. Could you please also let us know the backup copy job schedule? You can check it on the "Job" step of the job configuration wizard.
lolbebis
Enthusiast
Posts: 26
Liked: 5 times
Joined: Feb 26, 2020 9:33 am
Full Name: Mattias Jacobsson
Contact:

Re: Immutability settings

Post by lolbebis »

Yes of course.
Here:
Image
PetrM
Veeam Software
Posts: 3229
Liked: 519 times
Joined: Aug 28, 2013 8:23 am
Full Name: Petr Makarov
Location: Prague, Czech Republic
Contact:

Re: Immutability settings

Post by PetrM » 1 person likes this post

Hello Mattias,

In fact, I think it's up to you to decide for how many days do you want to prohibit deletion of data copied to an object storage.

Considering that removal of data by retention policy is one of the operations prevented by immutability,
I'd recommend to make data immutable for 2 days at least so that data offloaded to an object storage is protected for the same period of time as it's configured in job settings.

On the other hand, 2 days would be not enough if you decided to offload data produced by some other jobs as well and these jobs have different retention settings.

Thanks!
wishr
Veteran
Posts: 3077
Liked: 453 times
Joined: Aug 07, 2018 3:11 pm
Full Name: Fedor Maslov
Contact:

Re: Immutability settings

Post by wishr » 1 person likes this post

To add to what Petr said, I would recommend answering the following question at first: would you like the backup copy retention to clean up object storage from old restore points or not, and then decide whether extended immutability that is "longer" than your retention is needed or not. It's not something uncommon to have immutability set to, let's say, 20-30 days while keeping the retention at lower values.

Also, please don't forget to consider Block Generation when configuring immutability.

Thanks
lolbebis
Enthusiast
Posts: 26
Liked: 5 times
Joined: Feb 26, 2020 9:33 am
Full Name: Mattias Jacobsson
Contact:

Re: Immutability settings

Post by lolbebis »

Hi!
But if I set the immutabilty to 2 days and use my current job settings wich contains:

Retention File
Q3 full.vbk
Q2 full.vbk
Q1 full.vbk
2 full.vbk
1 incremental.vib

The last 2 backups is a full and an incremental would be replaced every day? And if I set immutable for 2 days that will not work I guess?
But even if I have the last 7 days, Veeam will always replace all the files in the chain everyday? unless I make reverse incremental?
Or am I thinking wrong? :)

Thanks
Gostev
Chief Product Officer
Posts: 31455
Liked: 6646 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Immutability settings

Post by Gostev » 1 person likes this post

In general, you want to have your immutability period set to at least 7 days, otherwise you're not leaving yourself sufficient time to react to an attack.

And you should not worry or think about backup chains or backup modes, because all of that is irrelevant to object storage (this only matters when backups are stored as files, which does not apply to object storage). With object storage, you basically need to forget everything you knew about Veeam backup modes :D
lolbebis
Enthusiast
Posts: 26
Liked: 5 times
Joined: Feb 26, 2020 9:33 am
Full Name: Mattias Jacobsson
Contact:

Re: Immutability settings

Post by lolbebis »

Our on-prem IBM Cloud Object Storage does not seem to support S3 Object Lock anyway. :roll: :(
sfirmes
Veeam Software
Posts: 223
Liked: 117 times
Joined: Jul 24, 2018 8:38 pm
Full Name: Stephen Firmes
Contact:

Re: Immutability settings

Post by sfirmes » 1 person likes this post

@lolbebis You are correct that IBM isn't currently on the list of object storage vendors that support immutability.
This forum thread is a great reference to check on object storage compatibility: object-storage-f52/unoffizial-compatibi ... 56956.html
Senior Solutions Architect, Product Management - Alliances @ Veeam Software
Gostev
Chief Product Officer
Posts: 31455
Liked: 6646 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Immutability settings

Post by Gostev » 3 people like this post

Specifically for ransomware protection, it's not immediately critical to use an object storage that support S3 Object Lock, simply because no current ransomware knows how to interact with object storage. In fact, we just had a customer recover from a few days old backups offloaded to Azure, following a ransomware attack that wiped the entire data center.

It will however become critical down the road, when ransomware becomes smarter. How soon this happens, we can't know.

The only immediately critical use case for immutable backups is protection against malicious insiders, which includes a hacker who penetrated your production environment and gathered critical credentials through keylogging or zero-day vulnerabilities. Unfortunately, we see this happen way more often than you might think.
Post Reply

Who is online

Users browsing this forum: ericlaiys78, Stupots and 13 guests