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.
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:
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
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[email protected]
Internet e-mail: storman AT us.ibm DOT com
IBM Tivoli Storage Manager support web page:
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 AT VM.MARIST DOT EDU> wrote on 08/01/2006
> Hi all,
> I try do do an point-in-time-restore to the 19-Jul-2006 on a w2k-Server
> (TSM Client 126.96.36.199). 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
> 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.
Paul Zarnowski Ph: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu