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 DOT 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 DOT 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 DOT edu or visit the list's Web site at
> >> > http://listserv.temple.edu/archives/networker.html where you can
> >> > also view and post messages to the list. Questions regarding this list
> >> > should be sent to stan AT temple DOT edu
> >> > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
> >> >
> >
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
