Thanks to all who responded. BUT I guess I need to be clear here:
If I make backups directly from the Sun Solaris box (NOT Solaris X86). I
would ordinarily NOT bother recovering the data from tape and ensuring
it matches the original. I mean, I wouldn't bother with the whole MD5
thing because there's no endian switch. *BUT*, I would clone the data
and thereby validate that I could read the original tape. Yes, we do
occasionally test/recover data, but for this, I just don't. I trust that
the backups/clones are doing their job correctly, and I obviously check
the ssflags, clflags, etc. to ensure there were no problems with the
tape(s) or the saveset(s) as reported in 'mminfo' command for either the
originals or the clone(s). HOWEVER, as I am a little nervous about this
little-endian versus big-endian deal, I was thinking that to prove that
copying the data to a Linux machine (Dell server) from the Solaris box
and then backing it up from there would still allow me to recover and it
wouldn't be changed in any way, I would do something like:
MD5->backup->recover_solaris->MD5 again scenario only as way to
determine if any endian difference was occurring and if so if it would
prevent a proper recovery of the data. Clearly, backing up the data is
not an issue. The issue is weather or not what your backing up was
changed in the process of copying it from the Solaris Sun machine to the
Dell server running Linux as a result of the endian difference. If the
test shows nothing amiss, is it reasonable to assume that I don't need
to do this each time in the future, provided, of course, that I'm still
cloning? I mean, I don't need to test the endian difference phenomena
again?
In general, what's the deal with recovering data from one platform to
another? We typically always recover the data to either the same host or
one with a similar OS.
Thanks.
George
thierry.faidherbe < at > hp.com wrote:
Yes, looks great. Having cksum or md5 same from both server looks ok.
Good luck,
TH
This is not possible due to certain security restrictions. However, I'm
thinking to simply copy them to the Linux box from the Solaris box, back
them up from the Linux box and then recover them to the original Solaris
box into a test area and then run MD5 checksums between the original
data and the recovered data. If all the same, should be okay?
George
thierry.faidherbe < at > hp.com wrote:
An alternative to your problem would be to backup to a file device on
your
linux system (disk space usage will remain the same) and then staging to
tape.
HTH,
Th
Hi,
We have some Oracle database dump files on a Solaris box (Solaris
2.7),
and I'd like to copy these to one of our Linux Red Hat boxes (AS 3)
and
then back them up from there. I was performing the backups on the Sun
box, but due to certain backup configuration restrictions we have in
place, I have to use a slower, older library to do this, so if I copy
them to the Linux Box, I can use a newer, faster library. I would, of
course, validate that the data on the Linux machine is the same using
MD5 checksums on both sides. We don't have everything in place yet to
do
hot backups via Oracle module.
I am concerned, however, about this business of little-endian versus
big-endian. I'd heard that before regarding the possibility of
problems
when transferring client indexes, wherein the checksums might match
just
dandy, *BUT* OS differences in how bits are read could cause still
mischief? Is this a concern here?
I should note that indexing is turned off for the pools we use to back
up these Oracle dump files, so we would use saveset recover to recover
these.
Thanks.
George
--
Note: To sign off this list, send a "signoff networker" command via
email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu
