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 <xpaice AT oss.co DOT nz> wrote:
> ----- "Andrew Meadows" <dna1110 AT GMAIL DOT COM> 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.
>
|