On Nov 9, 2005, at 2:29 PM, George Sinclair wrote:
Hi,
I know this has been discussed before, and I checked the archive,
and I read a lot of the posts -- some were mine! -- but I want to
be clear on this issue, and I don't think I am. It's been a while,
and I know more people have migrated to Linux, so I wanted to clear
this up.
We're considering moving from Solaris (NetWorker 6.1.1) to Red Hat
Linux (NetWorker 7.2.1). Clearly, Solaris is Big Endian (okay,
memory wise), and Linux is Intel X86 and thus Little Endian. Here
are my questions:
1. The general consensus seems to be that the client indexes (6.x
or later) are endian neutral (they're stored in some format wherein
NetWorker will not care about byte ordering) and will, therefore,
not be affected by this, *BUT* the media database is binary and
could be affected, true?
True.
2. EMC Legato does not officially support moving from one OS to a
different OS (even same endian), but people have done it
successfully, true?
True.
I guess I thought they had a published migration path, since it has
been done by many people for many years. Oh, well.
3. This should work as long as the transfer of the media database
is done in a manner wherein the data stream is endian neutral. For
example, following the steps in the disaster recovery guide to back
up the indexes and media database to tape (e.g. 'savegroup -o group
-l full' on the Solaris box and then 'mmrecov' on Linux end) and
then recover to Linux end, (especially the media database). OR
using 'uasm' to save the entire /nsr directory to a file on the
Solaris end, transfer to Linux end and then use 'uasm' again to
extract from file, yes?
4. Is the media database in fact endian specific? I never could get
an answer from Legato on this. Does anyone actually know what
exactly in NetWorker is endian affected? Is it just the media
database? Maybe nothing?
Pre-6.x it was everything. Post 6.x, the way client indexes are
stored changed from the old WISS database to an XDR encoded data
structure, which is endian independent.
5. How can we best test that the migration has worked and that
there are no endian affected problems?
Of course, even if you get the bits to transfer correctly, you will
have other problems. Machine ID, IP addresses, host names, drive
names, etc., that are stored in the database. I don't have answers
for these, but I'm sure other people do.
Byron
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
