Does anyone else out there think that this is a bad design? We have lots of users who fall into this trap, and I'm tiring of having to explain it to them. First, they use PIT-restore when they don't need to, because it's one of the first things they see in the restore GUI. Then, they don't see the files that they're expecting to see so they panic that their files weren't backed up. By the time we get involved, they are complaining about why TSM isn't backing up their files correctly and want to know why.
If your max versions is N, and you try to do a PIT-restore >N days ago, then TSM should just stop you and tell you that this might not work the way you want it to. Instead, it says nothing and you are left to figure out what's going on. And it's not at all obvious to the casual user what is going on. IMHO, this is how one might define a poorly designed user interface. At a minimum, I'd say there is room for improvement in this area. ..Paul At 09:04 AM 8/2/2006, Andrew Raibeck wrote:
It's not just a matter of the retention values, but also the number of versions. Assuming you run backup on a daily basis, if an object changes every day, then you will only be able to restore that object up to 10 days ago. Thus for the case of an object changing every day, the 184 day retention is meaningless; you will only be able to go back up to 10 days (or less if you back up the object more than once a day). In general, if you think of your restore requirement as, "I want to be able to restore up to 'n' days ago", then you should set your version and retention like this: VEREXISTS=NOLIMIT VERDELETED=NOLIMIT RETEXTRA=n RETONLY=n This way, no matter how many backup versions you make, you will be able to restore those versions up to 'n' days ago. Yes, these settings will probably cause your TSM database and storage utilization to increase. For directory objects, whether you want to keep all versions for 184 days is a decision you need to make, based on the importance of being able to use the GUI to do the restore and the importance of being able to restore the directory object; as opposed to using the CLI for the restore and having the directory structure built with default attributes if a backup version of the directory does not exist. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] IBM Tivoli Storage Manager support web page: http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 08/01/2006 10:48:50 PM: > Hi all, > > I try do do an point-in-time-restore to the 19-Jul-2006 on a w2k-Server > (TSM Client 5.3.4.0). I can go down in the gui just to the mountpoint > but I dont see that base-directory. Do I make a pit-recovery 20-Jul-2006 > it shows the base-directory as inactive. With a pit-restore from > 28-Jul-2006 it shows the base-directory as active. > If I look at the directory-attributes it looks as if the directory is > backed-up every day (changed-parameter is different for each > pit-restore). > I do use a default management class with following settings (and the gui > shows up this management-class for the directory) : > Vers Data Exist : 10 > Vers Data Del : 10 > Retain Extra : 184 > Retain Only : 184 > > I know about discussions with the directories not shown in gui in former > versions. But I thought, by defining a management class with a retain > period longer as the longest one for files, it would work. > But this looks for me as if the display doesnt sho up the directory > because of the versions of the directory. (I don't know, why this > directory was changed every day ???). > > Is this a bug of the version or normal behaviour ? > > Thanks for any help. > > Chris
-- Paul Zarnowski Ph: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED]