Skip to main content
commvault.com commvault.com
Solved

Read-only Snapshots vs ransomware attacks

  • August 24, 2021
  • 1 reply
  • 246 views
E
Byte
Forum|alt.badge.img+9

Is there anyone who would care to speak about (some pros and cons) using Snapshots to preserve Disk Library Mount Paths’s content? Our Storage System provide Snapshots that are read-only—they can’t be altered, overwritten, or deleted directly from Media Agent Servers. We are evaluating the possibility of creating a recovery point every 12 hours using Snapshots as an additional action beyond those described on the following pages. 

 

https://community.commvault.com/technical-blogs-and-articles-39/ransomware-prevention-tips-tricks-you-can-enable-today-700https://community.commvault.com/technical-blogs-and-articles-39/ransomware-faqs-764

Mount Paths are essentially File Systems exported via NFS from Storage Systems that don’t support WORM.

Best answer by Damian Andre

Hey @Eduardo Braga,

I’ve seen this done before by accident. Mostly on NetApp arrays where there is a default snapshot schedule that catches customers out sometimes. In those cases, Commvault pruning, which is very granular and runs constantly, can really hurt performance. On NetApp, we have seen maxed out CPU consumption because of it, causing all sorts of cascading issues. Some arrays do not have very good block sizes for changes - a 128k block deletion may result in a 4MB copy on write to the snap.

The other piece is that the CommServe database and deduplication is very closely tied to the data on disk - restoring a point in time copy of library will certainly throw that out of sync which could have unexpected consequences. For example, we may think we wrote a block at T2, but you restored back to T1 and now we’re deduplication against phantom data which will result in the inability to restore.

So, while it sounds like good protection from ransomware, I would definitely not recommend it.

View original
Did this answer your question?

1 reply

Damian Andre
Vaulter
Forum|alt.badge.img+23
  • Damian AndreVaulter
  • Vaulter
  • 1296 replies
  • Answer
  • August 24, 2021

Hey @Eduardo Braga,

I’ve seen this done before by accident. Mostly on NetApp arrays where there is a default snapshot schedule that catches customers out sometimes. In those cases, Commvault pruning, which is very granular and runs constantly, can really hurt performance. On NetApp, we have seen maxed out CPU consumption because of it, causing all sorts of cascading issues. Some arrays do not have very good block sizes for changes - a 128k block deletion may result in a 4MB copy on write to the snap.

The other piece is that the CommServe database and deduplication is very closely tied to the data on disk - restoring a point in time copy of library will certainly throw that out of sync which could have unexpected consequences. For example, we may think we wrote a block at T2, but you restored back to T1 and now we’re deduplication against phantom data which will result in the inability to restore.

So, while it sounds like good protection from ransomware, I would definitely not recommend it.

Mike Struening
MichaelCapon
E
3 people like this
  • Mike Struening
    Mike Struening
  • MichaelCapon
    MichaelCapon
  • E
    Eduardo Braga

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings