Hi,
Does Symantec have any documentation that specifies the requirements for restoring an image created on different hardware (sun4u to a sun4v server)?
not sure about sun4u to sun4v, but below artical may help you
https://www-secure.symantec.com/connect/articles/full-system-recovery-unixlinux-client-without-bmr
not sure about sun4u to sun4v, but below artical may help you
https://www-secure.symantec.com/connect/articles/full-system-recovery-unixlinux-client-without-bmr
This link shows the families:
https://community.oracle.com/thread/1905288
.
I would have thought that if your source and target machines are both Solaris 'SPARC' then you should be good to backup and restore between each other - assuming that neither element of the combination of "O/S version and patch level AND the NetBackup Client version and patch level" of the backup source is NOT higher than either element of the combinations of "O/S version and patch level AND the NetBackup Client version and patch level" of the restore target.
I assume that backup from Sun4u and restore to Sun4v - or - backup from Sun4v and restore to Sun4u - is okay as long as the 'endian-ness' of the instance of Solaris SPARC O/S on both platforms is the same.
A question to discover: Are both Sun4u and Sun4v 'big endian' ?
.
About "endian-ness"
https://en.wikipedia.org/wiki/Endianness
...and something more specific to Solaris (SPARC (big-endian) vs Intel (little-endian)) can be found by following this google search:
https://www.google.co.uk/?gws_rd=ssl#q=solaris+endian+sparc+versus+intel
.
So, maybe only Oracle can confirm whether 'files' from a big-endian client like Solaris SPARC can be restored to a little-endian client like Solaris Intel... because there may be something in the embedded file stream, like binary representations of ACLs, bit masks, etc... which is different between the two.
.
However, it may transpire that:
1) The NetBackup Client on a Solaris SPARC server (which was compiled to run on a 'big-endian'CPU) - AND - the NetBackup CLient on a Solaris Intel server (which was compiled to run on a 'little-endian' CPU) - that BOTH NetBackup Clients both 'munge' the O/S representation of ACLs and bit-masks in to a NetBackup representation of of the ACLs and bitmasks... i.e. NetBackup Client 'abstracts' the O/S 'endianness' and so, if this is true, then one might be able to assume that backups and restores are possible between Solaris SPARC and Solaris Intel servers.
...or...
2) The vendors of file systems for Solaris (SPARC or Intel) have already implemented their file systems such that they are 'endian agnostic', and so third party products like NetBackup do not need to concern themselves, and thus backups are restores are possible between Solaris SPARC and Solaris Intel.
Can anyone confirm these two points?
I wonder if it all boils down to policy type?
If any 'standard' backup from any O/S + file system combination is capable of being restored to any other O/S + file system which also supports 'standard' backups?
Thank you all for the answers. I will review all the links you have posted.
Marianne- I forgot to mention this is not BMR.
Mohmec - Personally, I can't remember the last time I had to restore from one platform type to another, let alone one file system type to another - normally one only ever has to restore to the same client - so it's such a rare thing to have to do - so I can't actually comment either way with any certainty. I think I went a bit overboard with the analysis - and I think revaroo is right, and you shouldn't have a problem - but as he suggested - to test is best.
Indeed - best advice as ever from our very own 'M'. :)
.
Mohmec - you might want to take a look at this too, a statement re no support for cross file-system type restores:
https://support.symantec.com/en_US/article.TECH31677.html
...which Nicolai dug out.
Marianne & sdo,
It is normal unix client backup of mixture of UFS filesystem & VXFS on SUN4v being restored to unix client running mixture of ZFS and VXFS. Sun4u system sunning SUNMCXall (entire distribution plus OEM). Root filesystem are ufs, all other filesystem are vxfs.
I was told by unix team 4years ago you just need to update the boot block but now they have to update the boot archive and thats where they are getting the problem. The sun4u bootblock is getting restored onto sun4v machine which is bad. The coomand to update the bootarchive is failing.
Note: Restore was done an alternate mount point. On Sun4v system another disk was mounted to root/a, then restored to the same directory.
