john@wa3wbu.UUCP (John Gayman) (02/02/88)
I had a problem this past weekend when restoring my system from tape.
Heres the scenerio:
I'm running Microport 2.3U and have an Everex external 60MB tape drive.
I wanted to re-do my file systems and change a few partition sizes around.
So I did a total system backup via cpio like so:
find . -depth -type f -print | cpio -ocv > /dev/mt/rmt0
It proceeds with the backup as per usual. After this, I boot from my
boot.floppy and re-run fdisk and divvy and re-create the file systems. I
then reload runtime.1 & runtime.2 which loads just enough to boot back from
the hard disk. I boot from the hard disk. At this point the system has
virtually nothing on it, just enough restored from release media to enable
the restore from tape (this ok?). So I restore the files with this:
cpio -icvdum < /dev/mt/rmt0
And away it goes. I have switches to cpio set to create directory if
needed, copy even if exsisting file is older, and preserve previous file
modification times. All appears well. Now the problems start!!
Upon rebooting the system after the restore I find News wont work,
LP spooler wont work and I cant even write files to my own home directory.
The problem is that during the restore, every directory that cpio needed
to create was created with a permissions of 755 and an owner ROOT, group
SYS (not the permissions, owner, group of the original directory). This
wreaked havok with News. Also, directories that were empty were omitted
entirely. This caused problems with LP where /lp/class and /lp/requests
are usually empty. And....... I notice CPIO does not backup special files
like the ones in /dev, etc.
Question: How can I get cpio to backup special files as well as
regular files ? What went wrong with the directory creation ? I read in the
docs that as long as super-user did the backup, the restored directories
should have the same permissions as when backed up. And... what needs to
be done to enable empty directories to be re-created with the proper
permissions. Is what happened to me a problem with Microport CPIO or
is there some procedure Im not following for backup/restore ? Im
basically interested in being able to restore a blank disk back to the
running configuration. Any help/suggestions are appreciated!
John
--
John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john
1869 Valley Rd. | ARPA: wa3wbu!john@uunet.UU.NET
Marysville, PA 17053 | Packet: WA3WBU @ AK3P wnp@killer.UUCP (Wolf Paul) (02/03/88)
In article <476@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > ... >find . -depth -type f -print | cpio -ocv > /dev/mt/rmt0 > ... >cpio -icvdum < /dev/mt/rmt0 > ... > Upon rebooting the system after the restore I find News wont work, >LP spooler wont work and I cant even write files to my own home directory. >The problem is that during the restore, every directory that cpio needed >to create was created with a permissions of 755 and an owner ROOT, group >SYS (not the permissions, owner, group of the original directory). This >wreaked havok with News. Also, directories that were empty were omitted >entirely. This caused problems with LP where /lp/class and /lp/requests >are usually empty. And....... I notice CPIO does not backup special files >like the ones in /dev, etc. > > Question: How can I get cpio to backup special files as well as >regular files ? What went wrong with the directory creation ? I read in the >docs that as long as super-user did the backup, the restored directories >should have the same permissions as when backed up. And... what needs to >be done to enable empty directories to be re-created with the proper >permissions. Is what happened to me a problem with Microport CPIO or >is there some procedure Im not following for backup/restore ? Im I can see a number of things which could have gone wrong. The first is that in your find command line you specifically told find to list only ordinary files (-type f), which excludes empty directories and special files. Thus, only ordinary files and directories containing them were backed up. Secondly, I think you need to first extract /etc/passwd so that there are entries in it for the user id's contained in your archive. Otherwise, they get reset to the id of the user doing the restore, i.e. root, since it would not make sense to have files owned by non-existent users. Finally, the permissions on the restored files depend on who does the RESTORE, not on who does the BACKUP. I have done numerous backups and restores with Microport CPIO, and I found that both ownership and permissions were maintained, so I don't think there is a bug in the program. The "installit" procedure uses cpio, so since it creates files owned by bin, uucp, etc, there is proof that it works ... Check the things I listed above, and let me know how it goes. Wolf Paul ihnp4!killer!wnp
wcs@ho95e.ATT.COM (Bill.Stewart) (02/14/88)
In article <476@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes:
:So I did a total system backup via cpio like so:
:find . -depth -type f -print | cpio -ocv > /dev/mt/rmt0
: [.....] So I restore the files with this:
:cpio -icvdum < /dev/mt/rmt0
: [...] The problem is that during the restore, every directory that cpio needed
:to create was created with a permissions of 755 and an owner ROOT, group
:SYS [ ... ] And....... I notice CPIO does not backup special files
The find option "-type f" means "only tell me about regular files".
So it did. So cpio was never told the names of directories or special
files, so it didn't output them to the tape. When you unpacked the
tape with cpio, the "-d" option allowed it to make any directories it
needed, and it made them with default permissions since there wasn't
anything on the tape telling it what you *really* wanted. Presumably
when you unpacked the tape, you were root, with umask 022?
As for "how do I repair the situation now?", I'm afraid you may be out
of luck; you didn't save that information on the tape, so you lost it
when you reorganized the disk. A recovery technique that sometimes
helps is to do
find . -type d >/tmp/junk
and edit /tmp/junk into a shell script that will fix things
g/fred/s/^/chown fred /
It won't do the special files for you , but it's better than nothing.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs