For somereason it would not let me specify the all 4 filesystems at install. It would only let me specify one then i had to extend to the others later... If i grow out of the first filesystem will it automatically start using the others or should i go ahead and backup and restore the database to be safe?
As for question 2 i was trying to think out of the box for an easy way to replicate the Db across sites... You are probably right though the restore would be a nightmare... thanks On Thu, Sep 1, 2011 at 2:38 PM, Xav Paice <[email protected]> wrote: > ----- "Andrew Meadows" <[email protected]> wrote: > > > > All, > > > > We recently started installing fresh tsm 6.2.1 instances in house. I > > was > > wondering if someone could help me with the following > > questions/issues. > > > > Question 1) > > > > We have a 500 GB Database allocated. I have that split up into 4 > > filesystems > > with 127 GB each. Currently Only the first filesystem is being used. > > I > > thought they should have been used evenly. is there a parameter i need > > to > > check to enable this? > > > > > > Location Total Space(MB) Used Space(MB) Free > > Space(MB) > > ------------------------------ --------------- --------------- > > --------------- > > /tsmdb001 128,000 37,389 > > 90,611 > > /tsmdb002 128,000 520 > > 127,480 > > /tsmdb003 128,000 520 > > 127,480 > > /tsmdb004 128,000 520 > > 127,480 > > > > Yes, this should be evenly spread. If you run 'q dbspace' you will see > what's going on. Extend dbspace will allow to you add more dirs if needed. > > > > > Question 2) > > > > With the way Dbbackups are now set up through the client API is is > > now > > possible to set up remote backups to another TSM Server? > > Could i compress or dedupe the backup over to another TSM Server > > remotely? > > Or does it end up using server to server communication to do that? > > > > Making a backup is a lot easier than making a recovery from that backup. I > think it's technically possible to do it but it might not be supported and > given the importance of the db backup I'd be keener to keep it simple (and > reliable). > > Maybe if you wanted to go down that route you'd be better to use a server > device class. >
