frecover - Preserving input user id

[Raynald Boucher]

Due to tape hardware incompatabilities, we are attempting the following (with errors naturally).

1- take tape backup on SystemA using fbackup
2- mount tape on SystemB
3- NFS mount filesystem of SystemC on SystemB
4- recover through NFS mounts using frecover on SystemB.

Unfortunately some userids are different (number) on each system, specifically on SystemB.
"frecover" restores the files on SystemC with the SystemB userids instead of the intended SystemA userids.

I have tried the -O option: no good because it recovered everything with the SystemB userid of the processing user.

Any suggestions on a clean / clear / efficient way of solving the problem?
Are there frecover options that will bypass the problem?
I could change the SystemB userids but then, how do I correct ownership and permissions for all existing files etc... ?

Magic would be nice too...

Take care!

[Sanjay_6]

Hi,

Unix does not store the user name with the file. It identifies the file owner with the user id and group id. So if the uid is different on the system the data is restored, it will be owned by the user who has that user id on the restored system. there is no workaround, except change the ownership manuallu once the data is restored.

Hope this helps.

Regds

[Paula J Frazer-Campbell]

Hi

I am afraid that unless the UID and GID on each machine is the same then this problem will happen.

The files you are recovering have UID and GID information and when they arrive on the server the OS will try to match the UID and GID with entries in the /etc/passwd and /etc/group file.



Paula

[S.K. Chan]

In the long run you may want to consider using NIS to manage your UIDs and GIDs. In a non-NIS environment it's going to be difficult to ensure you have a unique UID/GID unless you have some process in place to begin with that manages this when you create a user account. Unfortunately there's no magic for this, either you cleanup before or cleaunp afterwards.
just a thought ..

[James R. Ferguson]

Hi:

The name of a user is only an alias for the *number* or uid. If the uid in question doesn't exist on the receiving system, an 'ls' of the file will show the untranslated uid. If uid=100 is "joe" on the sending system but "sam" on the receiving one, then a file moved from sending to receiving system will belong to "sam".

You can use 'find' to isolate all files that have user ids (uid) that are not represented in the password database:

# find /home -nouser

Regards!

...JRF...

[Raynald Boucher]

Wow, fast response confirms my thoughts.

I plan on updating /etc/passwd and then
finf / -user -exec chmod {} \;

Any problems with the above?

Besides that, just trying to be tricky, is there any way to fool the frecover shell (and only that shell) into using an alternate /etc/passwd?

[Martin Johnson]

Because of this problem, we assign an unique UID to a user that is used to set up their account on any system in our environment. For example, UID 111 is assigned to joe. It can not be used on any machine unless it is used to set up an account for joe.

It is easy to keep this info in a spreadsheet.

HTH
Marty

[James R. Ferguson]

Hi Raynald:

You indicate that you plan on "updating /etc/passwd". If by that, you mean defining an account whose uid is the same as that of the files you copied in, then you're done! That is, you don't need to find/chown anything. Remember, the inode for a file or directory holds the *uid*. It's the password database (e.g. /etc/passwd) that provides the number-to-name translation.

Regards!

...JRF...

[Frank Slootweg]

*fbackup* stores user and group *names* on the tape, not the *IDs/numbers*.

So when restoring, the /etc/passwd and /etc/group (or equivalent) files on the system where frecover runs should have the proper name->ID mapping, because *UNIX*/HP-UX uses *IDs/numbers* for most of its functions.

So, assuming you want the user and group *names* to match between SystemA and SystemC:

SystemA's *names* should be present in SystemB's /etc/passwd and /etc/group files, but can use other *IDs/numbers* than SystemA

*and*

SystemC should use the same /etc/passwd and /etc/group entries as SystemB.

In short: C must match B, but B does not have to match A.

For your information: cpio(1), tar(1) et al, store the user and group *IDs/numbers* in the archive, so for those the solution is different.