Video Screencast Help

DLM Limitations for disk-based backups

Created: 29 Apr 2014 | 1 comment
baccalan's picture
2 Agree
1 Disagree
+1 3 Votes
Login to vote

It has come to my attention, though chatting with Symantec Support along with my own investigations that, while retention settings are simpler when it comes to disk-based backups over tape-based backups, the simplicity of retention period settings for disk-based backups are left severely limited.

Here is an easy(ish) scenario:

A set of servers run full, tape-based, backups on a weekly basis. These backups are then duplicated to disk-based storage that is also controlled by Backup Exec.

The DLM retention period for these backups is set to 6 days, because this disk-based storage is an offsite NFS mount with limited storage in comparison to our nearside disk-based storage. 

On the 6th day, no matter what conditions currently exist within Backup Exec these backups are deleted, per Symantec support, this is "as designed".

The issue is that if something goes wrong with Backup Exec and the new duplicate jobs do not run, we are left with a gap between last week’s backup was deleted and this week’s backup (that fails in this scenario) attempts to run. Now we are left with the potential for loss of data if there is a catastrophic event at the nearside backup locations.

This, to me, is seen as a limitation. While tape-based backups enjoy very specific control over retention and overwrite periods disk-based backups seems be an afterthought to Symantec. 

I think it would be in Symantec's best interest to review and align the overwrite, retention, and media set settings that currently exists for tape-based backups with that of the limited disk-based retention settings. 

It would be a very good thing to have, for example, a disk-based storage device fill up 100% and then it starts to overwrite the oldest data available for overwrite operations, just like it is done with tapes. Instead of having to constantly tweak (manually for every single server I might add) our retention periods for these types of backups so that:

Retention period set to high: We don't run out of disk space where all newer (potentially higher priority) duplicate jobs will simply fail 

Retention period set to low:   Have data deleted from disk-based storage too soon and risk the potential of having no backups on this device for a time, if certain unfavorable conditions are met e.x. - Backup Failure, loss of connectivity, etc.

Comments 1 CommentJump to latest comment

pkh's picture

I believe your situation is because you do B2T2D.  If you do B2D2T which is what most people do, DLM, by default will keep the last recovery point for a server, regardless of whether the backup set has expired or not, so you are always assured of having the latest backup.

Login to vote