Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 855
  • Last Modified:

TSM DRM behaviour with incremental backups

Hi guys

We have a 'forever incremental' backup policy implemented and I have been testing putting in place a DRM process.

It hadn't occurred to me that I might see some odd behaviour with the copy of the primary tape storage pool to the offsite storage pool as part of the DRM process.

My expectation was that as part of this command,

backup stgpool primpool offsitepool wait=yes

ALL data would be copied across from primpool to offsitepool each time it was run.

I have reuse delay set to 7 days and dbb expiry set to 7 days.

On monitoring this, the 1st time it was run I saw ALL data was copied across.  However on the 2nd week, only a fraction of the data copied across.

Is this because of the incremental only policy?

Are there any risks doing incremental only when it comes to TSM DRM?

Am I convincing myself that changing the incremental only policy to weekly full + daily incrementals is the answer?

Hope this is clear.

Cheers

J
0
John Pope
Asked:
John Pope
  • 2
  • 2
2 Solutions
 
SelfGovernCommented:
Incremental forever schemes work very well.  They greatly reduce the amount of data you need to back up (or replicate).  You just need to ensure that part of your backup administration includes periodically creating a synthetic full -- preferably to tape, so you can store it for archival or legal purposes.
0
 
John PopeIT ConsultantAuthor Commented:
Hi SelfGovern

Thanks for your response. Yes the incremental forever is used to do just that, minimise the amount we and time taken to backup.

From what I know of a synthetic full, you need to have taken a full backup and then a synthetic full is created from the last full plus the incrementals required.  That being the case I am not sure I can even do a synthetic full as we have never ran an actual full (apart from the 1st backup run several years ago).

Cheers

J
0
 
SelfGovernCommented:
Here's the deal: If you can't create a synthetic full, it means that you can't guarantee you can do a restore!    As long as you've still got that initial full and all of the incrementals since then, you should be able to do a restore... and create that synthetic full.  If you don't have all that, you need to run a full backup, because you are not protected.

If you don't create a synthetic full periodically,  corruption in, or loss of, one of the incrementals will mean that you likely can't do a restore.
0
 
max_the_kingCommented:
Hi,
tsm is able to manage incremental forever policy and this means that you do not really need to run full backups; its very first backup, even if you run an incremental, will always be a full backup, because it hasn't got previous backups. From that moment on, it will always go incremental, by using the "incremental" feature.
You as well have the chance to run a "selective" backup, which is really a "full" backup if you wish, but normally you do not need it. The only case you may want to do a selective, is to avoid fragmentation on the tapes (if you do not use collocation) so to make restore faster, but you normally do not need to.

As per the copypool incremental backup, well, you surely do not want to do selective backups of your storage pools because there would really be no use at all, and it is not even possible.

hope this helps
max
0
 
John PopeIT ConsultantAuthor Commented:
Thanks for both comments guys. I'm happy we have all incrementals backups as I have successfully restored to bare metal.

Cheers

J
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now