Skip to main content
Solved

Is it worth deduplicating Transactional Logs?

  • 6 October 2021
  • 4 replies
  • 431 views

We think that there is no real benefit for the Commvault to deduplicate Transaction Log data. Maybe some compression benefit, but today we deduplicate practically everything. I started another topic (Difference between Incremental Storage Policy and Log Storage policy) to ask about the differences between Log Storage Policy and Incremental Storage Policy. The idea is to have a specific Storage Policy for Database Agents Transactional Logs with deduplication disabled. By examining some backups jobs, we noticed that Savings Percentage comes entirely from Compression. Due to its nature, It seems that there is no gain when deduplicating variable data like Transactional Logs. 

By disabling deduplication for those data, in theory, we can keep DDB smaller and reduce Q&I times. Am I right?  

 

 

It is good to know it. Can you point me to the documentation reference? Another question. According to the documentation, “If the non-deduplicated and deduplication data are written to the single library, it will skew the overall disk usage information and make space usage prediction difficult.” (Deduplication Building Block Guide)

Is it a good idea to have a separate Storage Policy just to store those PostgreSQL Logs? Oracle Database Agents have a particular option to associate Log Backups with a specific Storage Policy. 

Hey @Eduardo Braga , that quoted line is because we are adding data that has a dedupe ratio of 0%, so the overall calculations are all off.

As per your other thread, you could simply send those to another (non-deduped) Storage Policy.

I’ll look for the doc link stating this for your records.

@Eduardo Braga I spoke to our docs team who had me put an MR in to get this added.  I filled it out in your name so you’ll get the notificiations.

Reply


Terms & ConditionsCookie settings