Veeam and EMC Data Domain Retention Lock

[foggy]

Hi Dirk, thanks for your feedback. This topic seems to show up more frequently these days, indeed. How do you imagine Veeam B&R support of this feature? Would you like to be able to configure Retention Lock on the job level (including the locking time period) or support on the repository level would be enough for you?

[SE-1]

Hello Foggy,

Thank you already for a swift answer.

I think this is best done in the backup job with a retention lock period.
Repositories are often used by multiple jobs, in that way you can be more flexible per job if needed.

[pschmidt]

Hey Everybody,

what might help you is the Automatic Retention Lock feature in DDOS 6.2.0.20 and later releases

For backup applications which don't natively support the DD retention lock feature, it's been always a problem for customers to leverage the feature, because it was backup administrators who, manually or through a script, had to set the retention lock on newly ingested files for an MTree, and the lock to be of a reasonable duration so that it expires shortly before the backup is to be expired (and deleted) by the backup administrator.

To help backup administrator lower the burden of keeping retention lock son backup files and bring the DDOS up on feature parity with other vendors, since DDOS 6.2.0.20 there is a feature that can be enabled from the CLI for each MTree with Retention Lock configured, to set a lock on every file ingested (for a given period of time), after some predetermined amount of time has passed since the file write to disk was completed. This way, administrators don't need to worry anymore about manually (or scripted) setting the retention lock , and this can occur automatically without the cooperation of the backup application.

I think that will help you all

Best Regards,

Patrick

[kaithost]

Hi Patrick,

I think if would be much preferrable if VBR would be aware what's locked and what's free to delete.

@foggy: retention locking should indeed be configured on a jobs basis. putting this on the repo would be a first step.
better than nothing, i'd say. But I guess the job specific retention locking requirement will arise soon after.

[foggy]

Understood, thanks.

[SE-1]

Hi All,

Most Veeam Customers are levering DDBOOST as a protocol as it gives many advatanges.
DD Boost is supported with both DD Retention Lock Governance and Compliance.
Automatic retention lock is how-ever not supported on DD Boost.
So it needs to be in manual mode, applied by the backup job once the VIB/VBK is written.
The VBM file is updated constantly and is located in the same repository, this file should not be locked.

[SE-1]

Hey Foggy

Has this been discussed internally at veeam? Is this something that has been put on the road map?

Thank you in advance

[Gostev]

Hi, Dirk. This feature is not coming in the immediate major release (v11), and unfortunately we cannot make comments on the roadmap publicly. Thanks!

[pschmidt]

Hey Kaithost,

I know that it would be much better when you can directly control RL via Veeam per Job-basis. But at least he other implementation lets you use it somehow in a doable way without much config work

BR

[wayne]

Most of our customers have moved to VEEAM with Data Domain. The last few will be that way soon as we continue to eliminate VDP. I've been watching this thread for a while with hopes to see it all come about at the job level. From a ransomware point of view. If you can't lock the metadata and they delete it. What does that do to our exposure? In other words, if a piece of malware was able to corrupt that file, would that render our backups useless or could we still recover from them if needed?

[foggy]

Hi Wayne, metadata is not required for restore, so provided backup files themselves are safe, you're good to go.

[SE-1]

Good morning all

This feature request is still alive and kicking. Hoping on some positive news
Is there any feed back if this has been put on the road map?

thx

[foggy]

Hi Dirk, no news since the Anton's post a few months ago, but your voice is counted. Thanks!

[sradhube]

DD retention lock controlled by veeam would really make sense.
Thx

[heinrichloewen]

Hello,

DD Retention Lock would bee nice directly from B&R. Please put my name on the list of people how would bee very happy if you implement this feature.

br
heinrichloewen

[heinrichloewen]

Hello,

are there any news about data domain and retention lock?
It is very important for us to be save agains ransomware and data domain has the features build in, but vbr has to trigger it from outside.

Or is it possible to put the immutable on the mtree to auto with a recommended configuration from veeam?

br
heinrichloewen

[veremin]

Currently, this is feature is not supported (even with custom modifications mentioned), and we cannot provide any ETA or roadmap for future features. Thanks!

[moquai2020]

Hello,
we would be happy to see a "retention lock checkbox" per job in VBR too.
Thanks and br
Thomas

[veremin]

Having the same box as simple and hardened repositories will reduce the overall security of the storage system, which will ruin the goal of hardened repository. So, there were no immediate plans to allow such type of scenario, which you seem to be after - job-level immutability setting would mean that there are both locked and unlocked backup files located on repository. Thanks!

[wayne]

So using different VEEAM repositories(mtrees) for jobs requiring retention lock isn't a reasonable solution? Use a different DD unit at a different locations or the cloud feature. We honestly haven't used any DD cloud features as of yet. We will be considering it as we replace DD units. Three of our ten or so units that don't have DDVE will age out in the next couple years.

[lightsout]

I'd be super interested in integration natively in Veeam also!

[viktu]

Is there any real plan? A lot of organizations are getting hit by intrusion attacks that will delete all the backups. If DD has de retention lock option, we, the Veeam users, need this integrated ASAP. Right now, backups are more useless if they cannot be protected from deletions made by administrators or hacker impersonating them...

[Gostev]

This feature is not in a short-term roadmap. For protecting backups against cyber threats, we recommend deploying V11 Hardened Repository as your primary backup repository. Thanks!

[magnusvr]

I also really need thios for my customers. Many of them cannot store backup in AWS and the DataDomain is a popular choice, we need a Retention Lock integration with Veeam.

[olivier31]

Hello, so DDBoost with retention lock is not scheduled on roadmap ?
V11 hardened Repository is only with NFS ...
i confirm that customers considers this as a lack of feature ...

[Andreas Neufert]

Hardened Repository is not available with NFS. Needs a block device.

DataDomain Retention Lock can be used with "Any" application by implementing "Independent Copies with Fast Copy" + Object Lock in Compliance mode.
See here. See the examples for Dell EMC software in there. Same method can be used for Veeam when "Independent Copies with Fast Copy" is used.

Important point is that you do not bind the admin interface to anything network bound, otherwise the hacker could monitor the keyboard and customer would loose the first time he used DataDomain console remotely.

[nvdwansem]

Hello,

I'd like to see this feature implemented as well, it's very important to us actually.

Thanks

[Andreas Neufert]

Please use the above linked method for now, which has the same result.

[jmely]

The use of Data Domain as a VTL with retention lock, may be an alternative. I have not tried this alternative but It may work.
An other solution may be to do a Backup Copy to the tree with Retention lock, with GFS, but only lock files older than the last vib file just to lock VBK for weekly, monthly and annually backup and have a Hardened Linux for the initial backup.

[Andreas Neufert]

Yes, the VTL approach would work as well, but would have to transport much more data and you can not do direct restores like Instant VM Recovery, File level Recovery and Application restores for VM Backups.

Your last described approach would not work. We monitor file integrity and if we can not delete a file that we want (automatic/manual triggered) we would place the whole area in repair mode as something is wrong for us. You would need to start then a completely new chain then and delete old backups manually when the files run out of Immutability. So the from Dell documented way with the Fast Copy is the best way in case of processing and usability.