Understanding data retention with Exchange backup

RandomAdmin

Active Newcomer
Joined
Feb 20, 2015
Messages
19
Reaction score
0
Points
0
PREDATAR Control23

Hello all,

as per subject I am trying to figure out data retention within the scope of Exchange specific backups, simple scenario one Exchange server which is backed up (Full backup) daily on the TSM server, as data is growing this is causing space concerns.

I'll switch the configuration to a standard weekly full + daily incremental backup but there is something I'm having issues to understand/figure out as per subject data retention.

I think I've got the concepts (I've referred to this document) but I'm having difficulties to relate this to Exchange, if I issue a query copy <domain> <Policy Set> <Management Class> I get the following output:

Code:
Policy        Policy        Mgmt          Copy          Versions     Versions       Retain      Retain
Domain        Set Name      Class         Group             Data         Data        Extra        Only
Name                        Name          Name            Exists      Deleted     Versions     Version
---------     ---------     ---------     ---------     --------     --------     --------     -------
XXX           ACTIVE        EXCH1         STANDARD             5            1            4          30

What I don't get is how TSM determines, for example, "...the number of the versions to keep when the data no longer exists on the client machine...", this is pretty obvious when dealing with a UNIX FS or Windows Fileserver (just examples) but I can't correlate this to Exchange databases.

Anybody would be so kind to help a poor lost soul?

Thanks in advance!
 
PREDATAR Control23

Marclant,

thanks a lot for the link and the explanation, I'm going to read the docs today and try to make sense of all these new concepts.

Cheers.
 
PREDATAR Control23

Maybe this is going to save you some time, as some years ago I took some notes about how to configure management classes depending on each TDP based strictly on the redbooks as it was always a discussion among my TSM colleagues. I did this mainly because the versions/retentions concept it's not completely "translatable" to a Exchange, Oracle or MS SQL scenario as you noticed.

So, for Exchange, this example was extracted from the redbook sg247373 and it suggests you simply forget about the versions (using NOLIMIT) and create your mgmt based only on the retentions you want:

Code:
define copygroup REDBOOK REDBOOK_PO REDBOOK_LEGACY_EXCHANGE type=backup destination=EXCHTAPEPOOL verexists=nolimit verdeleted=nolimit retextra=31 retonly=31

This is only one valid strategy among others if you want to avoid the versions paradigm and you control in some other way the versions number (e.g.. running strictly one backup a day, checking continuously how many versions you have, etc.).
 
PREDATAR Control23

Daduranp,

thanks a lot for this, I still plan to go through the document but your approach seems exactly what I am looking for as, but this has to do with my inexperience with TSM, in the current situation I'm not even sure how far back in time I can go backup wise while with this approach I could have some more control over versioning.

As an interim measure to save some space I've reorganized Exchange schedules with a classic daily_incremental + weekly_full backup maybe not optimal but given the amount of data we're backing up and the lack of scratch tapes it is the best I could come up with at the moment.
 
Top