Farren,
>From our experience, this is the problem: "Configure a new server and copy
the data across
> in such a way that it doesn't look like it's changed."
Our main file servers have been on five different physical machines in the
eight years I've been here. Our attempts to "copy" data from one file
server to another have always caused TSM to grab a new copy of the entire
server. One issue is that Microsoft's tools - xcopy, ncopy, and pcopy -
all "copy" permissions but not inheritance. So a folder on the source
that inherits certain permissions from its parent will have the same
permissions APPLIED on the copy. From Windows' perspective that is an ACL
change, so TSM grabs a new copy. Worse, it means that any changes you
intend to apply at the top of the directory tree dead-end at that level.
You must then force the inheritance down the tree, which means ANOTHER ACL
change and another copy of the file server pulled into TSM.
If you're going to pull in a copy of the entire server anyway, I would
recommend that you get your permissions, inheritance, auditing, etc. as
close to perfect as possible BEFORE launching the first post-migration
backup. And do as much with groups as possible. Adding just one user ID
to the top of a directory tree will provoke a very large backup session.
Good luck.
Tab Trepagnier
TSM Administrator
Laitram, L.L.C.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 05/12/2005
03:08:20 AM:
> Morning all TSMers
>
> Running TSM 5.1.6.2 on a Solaris server. Attached to 1*3494 library with
> two*3590H1A drives.
>
> I have a possible problem here. One of the sys admins for the Windows
2000
> servers has informed me that they are going to need to replace an entire
> Windows 2000 server due to severe hardware issues that they have been
> experiencing. No amount of support has fixed the problem and hence the
> drastic move. The server has got some 820,000 files on it amounting to
> approximately 450GB.
>
> Here is what we want to do. Configure a new server and copy the data
across
> in such a way that it doesn't look like it's changed. The new server
will
> have the exact same Node name, file system layout etc. I don't really
want
> to be faced with backing up the entire server all over again as we are
> getting low on both tape space in the library and database space. This
was
> not something I had foreseen.
>
> From what I have been told, early tests have not been promising and TSM
> still thinks files have changed even if the last change date/time etc
has
> not altered. Does anyone have any experience with this or any advice
they
> can give that may help us avoid a long backup that will hog system
> resources?
>
> Many thanks in advance
>
> Farren Minns
> Solaris System Admin / Oracle DBA
> IT - Hosting Services
> John Wiley & Sons, Ltd
>
>
> ######################################################################
> The information contained in this e-mail and any subsequent
> correspondence is private and confidential and intended solely
> for the named recipient(s). If you are not a named recipient,
> you must not copy, distribute, or disseminate the information,
> open any attachment, or take any action in reliance on it. If you
> have received the e-mail in error, please notify the sender and delete
> the e-mail.
>
> Any views or opinions expressed in this e-mail are those of the
> individual sender, unless otherwise stated. Although this e-mail has
> been scanned for viruses you should rely on your own virus check, as
> the sender accepts no liability for any damage arising out of any bug
> or virus infection.
> ######################################################################
|
