cancel
Showing results for 
Search instead for 
Did you mean: 

DLM issues - Duplicated backup sets

Mike85
Level 3

Hi all, I have a complex issue with regards to DLM and duplicated backup sets I am hoping you may be able to help with. My current setup is as follows:

  • We have two sites; Production and DR
  • At each site we have a DataDomain setup as OST storage
  • The production BE implementation is a CASO server and DR the slave.
  • Each night we backup the production servers to the Production OST device and then duplicate to the DR OST device.

The problem we are facing is that once a backup set has been duplicated to the DR OST device, both the production incrementals and DR incrementals become dependant on the last duplicated Full backup.

The Full backups at the Production site display no dependant backup sets even though incrementals have since been taken.

The issue with this is that when full backups expire on the Production OST they are removed regardless of there being any incremental backups still on the Production OST which would be dependant on the Full backup. Usualy DLM would recognise that there are dependent incrementals and expire but not delete. However as the dependent sets are being associated with the duplicated copy on the DR OST this does not happen.

This means that in the event of a restore, I would have to rely on the DR OST backup sets which are not local to site, meaning a slow restore.

I have a case raised with Veritas support who have replicated this issue in the lab and said this is "by design". I have asked them to tell me the logic behind this but whilst I wait, I was hoping I might get some insight here and also any particular workarounds (other then making my incrementals expire before my full set).

Thanks in advance!

2 ACCEPTED SOLUTIONS

Accepted Solutions

Riyaj_S
Moderator
Moderator
Employee Accredited Certified

Yes, this is by design. If there is a copy of a backup set (duplicate) with the farthest expiry date then DLM would delete the original backup set and link all the subsequent incrementals to the farthest expiry date backup set. This is also explained in following technote:

https://www.veritas.com/support/en_US/article.000108286

The purpose of this feature is to ensure that disk space is effectively reclaimed by not retaining multiple copies of same backup set. (This is only applicable to disk to disk duplicates, and not tape duplicates).

Thanks and Regards,

Riyaj

View solution in original post

Riyaj_S
Moderator
Moderator
Employee Accredited Certified

One way could be to set higher retention on primary copy than duplicate copy. So that the expiry date of the primary copy is farthest.

Thanks and Regards,

Riyaj

View solution in original post

3 REPLIES 3

Riyaj_S
Moderator
Moderator
Employee Accredited Certified

Yes, this is by design. If there is a copy of a backup set (duplicate) with the farthest expiry date then DLM would delete the original backup set and link all the subsequent incrementals to the farthest expiry date backup set. This is also explained in following technote:

https://www.veritas.com/support/en_US/article.000108286

The purpose of this feature is to ensure that disk space is effectively reclaimed by not retaining multiple copies of same backup set. (This is only applicable to disk to disk duplicates, and not tape duplicates).

Thanks and Regards,

Riyaj

Riyaj_S
Moderator
Moderator
Employee Accredited Certified

One way could be to set higher retention on primary copy than duplicate copy. So that the expiry date of the primary copy is farthest.

Thanks and Regards,

Riyaj

Hi Riyaj,

Thanks you for the explenation and possible workaround. This now makes sense to me!