Successful System Cloning using Ignite-UX

• If you have uid or gid values larger than 2097152 consider writing a script that will save

information about file names and the name of the owner and group of the file so you can run

another script after a recovery to change the ownership on files that did not have their user or

group information correctly recovered.

• Backup files that are owned by large uid or gid values using a backup utility such as fbackup,

these files can be restored after a recovery to preserve the ownership information. If there are not

too many of these files you can run this backup to a file that will be included into the recovery

archive so it can be restored immediately after the recovery (this assumes that you do not need to

recover more up to date files from your regular system backups).

Files Belonging to nobody/nogroup

Normally files created by root on NFS mounts are created with the owner and group of nobody

and nogroup (unless you specifically allow remote root access to the exported file system).

The uid and gid values for nobody and nogroup is -2. This presents a problem when those files

are included into a recovery archive (or a golden image). The chown(2) family of system calls do

not allow you to change the uid or gid associated with a file or directory to -2. This means that

the ownership information for files owned by nobody or nogroup will not be recovered.

During a recovery attempt this means that pax will print many errors if there are entries in the

archive owned by nobody or nogroup, such as:

pax_iux: opt/apache2/lib/htdocs/processlist/index.htm : An error

occurred attempting to preserve the owner and group ids.

If you encounter this issue you should consider:

• Ensuring that no files owned by nobody and nogroup will be included into a recovery archive

(run a job to find these files and change their ownership), or

• If changing the ownership of files owned by obody and nogroup is not possible in your

environment after all of the warnings are printed on the console when you see the following

question:

ERROR: Cannot load OS Archive ( Recovery Archive ) The

configuration process has incurred an error, would you like to push a

shell for debugging purpose? ( y/[n] )

Answer y, then when you have a shell prompt enter the following command:

# exit 2

This causes Ignite-UX to ignore the errors about not being able to change the ownership of the files.

Please review all of the messages displayed by pax as there may be other errors apart from the

ownership messages.

Additional cloning and recovery issues to consider

The following issues are analogous to the main issues previously presented although they provide a

different perspective intended to further assist you: