NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/aix/8984

Text File | 1992-08-21 | 5.3 KB | 124 lines

Newsgroups: comp.unix.aix
Path: sparky!uunet!paladin.american.edu!darwin.sura.net!uvaarpa!murdoch!holmes.acc.Virginia.EDU!op
From: [e-mail] (Olaf  Pors)
Subject: Restores of rootvg by inode
Message-ID: <[e-mail]>
Originator: [e-mail]
Keywords: inode, restore
Sender: [e-mail]
Organization: University of Virginia
Date: Fri, 21 Aug 1992 16:55:45 GMT
Lines: 111

  After our first RS6000's (AIX 3.1, level 3001) were
installed, it became apparent that AIX had no provision for
incremental backups of the root volume group.  IBM's
answer to my query was "use tar or cpio".

  For those readers who may be unfamiliar with different
backup methods (the rest of you can skip this paragraph):
the backup (by name), tar, or cpio commands may be fed a
list of names (usually produced via "find") to produce an
archive of directories, files, or filesystems.  On non-AIX
systems, tar cannot handle special device files, and
expands holes on extraction.  Cpio has trouble preserving
hard links and probably also expands holes.  While some or
perhaps all of these problems may now have been eliminated
under AIX, any simple "by name" approach inherently has a
problem having to do with the need for incremental backups
and the reappearance of removed files.  It is unreasonable
to perform complete backups daily, but it is necessary at
many sites to make sure that on any given day, filesystems
could be completely restored to their states as of the
previous day, if disaster should strike.  The solution is
to back up only incremental changes to filesystems on a
daily basis.  If disaster occurs, a restore can be done
from the most recent full backup, and any subsequent
incrementals.  For example, if the full backups are done
with

      find ...  | cpio ...

and incrementals are done using

      find -ctime ... | cpio ...

a later restore would bring back files that were removed
since the full backup was done.  One could try to program
around this problem by saving "find -ls" outputs along
with each incremental backup, and removing extra files after
each incremental restore, but this is a lot of effort,
and may not even work, if huge files fill up a filesystem
before they can be removed.  The best, and in my opinion,
the only reasonable solution is to do backups and restores
by inode, which takes care of all the above problems,
provides for multilevel incremental backups, and an
interactive restore capability.

  AIX supports the use of backup/restore by inode for
non-root volume groups.  A backup by inode of filesystems
in rootvg can be performed, but cannot be used to restore
a dead system, since a bootable tape/diskette created by
3.2 mksysb or bosboot expects a tar/pax archive
(backup-by-name archive prior to 3.2).  Therefore, anyone
who considers inode backups highly desirable must create
his own version of a bootable tape or diskette.  After a
considerable amount of experimentation and some help from
our local IBM SE, a bootable 8mm tape was constructed that
would allow a restore by inode of the filesystems in the
root volume group.  The creation of a customized bootable
tape was also suggested in a September 1991 FAQ entry.
The tape was used on a number of occasions to restore (by
inode) production machines and to perform other emergency
maintenance like restoring a corrupted /etc/passwd.

  I found an annoying problem with the bootable tape
operating system:  often the entire root volume group
would be restored via an interactive shell, then exiting
the shell in order to create a boot logical volume and
update the ODM on disk would result in an immediate

        INIT: SINGLE USER MODE

and all active shells had been killed.  The entire restore
would then have to be repeated.  After much
head-scratching, the problem was found to be due to using
control-C while in an interactive shell, and was fixed by
putting trap statements in a few scripts.  The problem has
been reported to IBM since it manifests itself if the
"limited function maintenance shell" is used from a
standard boot tape.  PMR 0x770.

  A new problem at 3.2.2: I've found that when a vanilla
IBM mksysb tape is booted, a maintenance shell is started,
and a copy of /bin/ed is brought on board via diskette,
/bin/ed doesn't work properly (reads only the first 18 or
19 lines of a file and says "?").  Therefore the bootable
system can't be trusted for simple maintenance work
via ed as implied by the "limited function maintenance
shell" menu option.  PMR 0x725.

  Other than the ed problem, the customized boot tape
serves our need well for restores of machines backed up by
inode.  If there is sufficient interest, I'll post the
files needed to create the tape.

  I was hoping to find that IBM would support restores of
rootvg by inode at 3.2, but was quite disappointed.  This
is such an essential capability at our site.  Does IBM
understand the need for incremental backups?  Why on earth
invent a backup-by-name, or use pax/tar, when Berkeley
Unix already has a superior tried-and-true backup-by-inode
method?  What are other sites doing?  Can we push for
restores by inode?  I'm afraid that in subsequent
releases, if somebody doesn't say something, IBM will
somehow make it impossible to customize a boot tape to
allow restores by inode.


Olaf Pors
Academic Computing Center
University of Virginia
[e-mail]
804-924-0633