As Steve suggested, test out your scenario using a common nodename.
However, you will need to be careful because both servers will have
common databases (like master and msdb)... and you do not want
those backups for different servers to get mixed in with each other.
You could have a separate line in the backup script on both machines
that backs up the "mirrored" database on both servers
(and point to a similar DSM.OPT file)
knowing that the backup on the Mirror machine will fail.
You can also look into "Proxy Node". It allows one node to
store data on behalf of another node if the correct permissions
are granted from the TSM Server side.
There are probably a number of other ways to get your desired result.

Thanks,

Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 11/14/2007
04:49:03 AM:

> Hi Del!
> Let's say ServerA is the Principal and ServerB is the Mirror.
> Normally you would schedule a DP backup on ServerA. The
> (mirror-)database on ServerB is running in a state which doesn't allow
> backing up (restore mode?)
> Now there is a take-over and ServerB becomes the new Principal. Now you
> will have to start backing up the database on ServerB.
> And if everything is switched back to normal, you will be stuck with
> backups on the ServerB DP node which never expire, since the backup is
> running on ServerA again.
> I hope I made myself a little bit more clear?
> Again, thank you very much for your reply!!!
> Kindest regards,
> Eric van Loon
> KLM Royal Dutch Airlines