Some guidelines for filesystem backup

[Devon Tuck]

In article <4 at icdi50.UUCP> Steve writes:
>
>Does anybody know of a utility that will back up an entire disk drive to
>streaming tape under SCO Xenix or Unix.
>
>The utility that I would like to have would allow the end user to backup 
>every block of the disk thereby allowing a complete disk restore from the
>tape. This would therefore include the operating system and all filesystems.

Steve,

I just went through GREAT pain to do this successfully.  I see a few different
possibilities here.

          SEVERAL ALTERNATIVES FOR BACKING UP AN ENTIRE FILE SYSTEM
          =========================================================

DISCLAIMER:  The following guidelines for backing up a filesystem have come
   from trial and error, several other sources (see REFERENCES), and much
   deliberation about the pluses and minuses of the following alternatives.
   It is my intention that this article save many of you the trouble and
   lost time, files that I experienced on my way to enlightenment.  Since
   this is a rather complex process, and there are many options to consider,
   and every system is unique, I hope that others will step in to correct,
   or add to what I have submitted. -- Devon Tuck

I)  If you want to backup the image of your drive, or partitions of it, and
	A) If your backup device has a friendly DOS oriented program with it
	   that you can boot from floppy, and
	B) You don't ever intend to move your filesystem to a different
	   type of hard drive (without first doing some other type of backup)
	
	Then, you might just want to boot up your dos program and grab the
	whole drive image.  Some of the advantages are,
		1) You can restore it without the complexity of... booting
		   a floppy unix filesystem, making sure the target hard drive
		   has it's boot image, it's file system is configured properly,
		   restoring to it, cleaning it, etc.
		2) I feel it is more reliable, and much faster than backup,
		   restore.

II)  If you want a backup of the entire file system, and
	A) You will not want to retrieve more than one or two specific
	   files from the backup.
	B) You have either the backup, or dump commands available, and
	   an installed tape driver.
	C) If you intend to restore ONLY to:
		1) An identically partitioned disk, or
		2) One that you have done an initial xenix installation on, or
		3) One that you have done a divvy / mkfs on and which has a
		   file system partition that is the SAME SIZE OR LARGER.
	D) You have made a "Bootable, root floppy" with "mkdev fd" after
	   your tape driver was installed in the kernel, then mounted that
	   floppy and copied all useful commands such as (restore, restor,
	   more, ls, mount?, umount, mkfs, any necessary tape programs) onto the
	   drive so that you can boot from this floppy to divvy your disk and
	   restore your filesystem. (NEVER TRY TO RESTORE TO THE SAME FILESYSTEM
	   FROM WHICH YOU BOOTED) and (Always do an "fsck -s /dev/hd0root" after
	   this restore)
	E) You don't mind that backup is a little ssllooww with some of the
	   older, less dense tape formats (It took 1.25 hours to restore
	   a 110 meg drive using Maynard 60 meg QIC-02 tapes.)

	Then to backup the /dev/rroot partition you can use

		"backup -fu0k /dev/(name of tape driver) (size of tape in k)"

	To verify that there were no tape errors you can do:

		"restore Cf /dev/(name of tape driver) /dev/rroot"

	To restore use

		"restore rf /dev/(name of tape driver) /dev/hd0root",

	but do it from another file system (such as a boot/root floppy, and
	only to a file system that is the same size or larger.

	IMPORTANT:  It is a good idea (in other words I didn't do this so
	it caused me great inconvenience) to do a "/etc/divvy -b 1 -c 1"
	on your disk, and do a
		"restore tf /dev/(name of tape driver) /dev/rroot"
	and redirect this information into a file and print it, or write it down
	and leave it with the tape.  It is important that you know, when you
	pick the tape up later, the period that the backup covers, the size of
	the filesystem partitions from which it came, perhaps the files on the
	tape (you can get this with the T option) and any other pertinent info.

III)  If you want to backgp the files of an entire filesystem (or a subset), and
	A) You want faster performance,
	B) You would like to perhaps retrieve subdirectories, or sets of files,
	C) You want to restore the information to any unix system running a
	   compliant cpio and unix version, (yes I am being vague, the point is
	   the backup will be much more portable) 
	D) You can do this as root.

	Then, you can do:
		"cd /"
		"find . -depth -print | cpio -ocvm > /dev/(name of tape driver)"
	to restore, you may be able to do
		"cpio -icdv < /dev/(name of tape driver)"
	from your active partition, but it is always safer to boot another file
	system (such a s a bootable root floppy, mount the filesystem, cd into
	the mount directory, and do the cpio command.

IV)  The dd command is also useful for doing filesystem backups, although I have
     no concept of how portable it is, or what you can get away with on a
     restore.  For example, "dd if=/ of=/dev/(tape device) bs=(block size)"

V)   I feel inclined to mention that tar will often (always?) not copy
     device special files, or empty directories, can only handle 17 levels of
     subdirectories, is very intolerant of tape errors, some versions do not
     split across multiple volumes unless you give the k and b options.  It is
     usually best to use tar on user files, rather than system files, and
     certainly not an entire file system.  It can be hard to get subdirectories
     off of a tar backup correctly, so cpio is much more versatille.  With it's
     faults, tar still is probably the most popular format for source code
     distribution.

NOTE:  With all of these commands, it is VERY IMPORTANT that you read all of
	the information supplied by your tape manufacturer, and if you are
	using one of the above commands, read carefully through ALL the options
	to make sure you understand what you are doing, and that there is
	nothing you are leaving out.


REFERENCES:
	The SCO XENIX 2.3 CRASH RECOVERY KIT, A six page fax I received.
	Numerous SCO Engineers, primarily Paul Hurford.
	Greg Swallow from Maynard Electronics.
	The SCO Xenix System V (2.3) Operating System User's Reference, and
		the SCO Xenix System V (2.3) Runtime environment, for
		cpio, restore, divvy, mkfs, mount, fsck, backup, etc.

SUBMITTED BY:	Devon Tuck
		tuck at iris.ucdavis.edu
		US Army Corps of Engineers, Hydrologic Engineering Center
		609 2nd Street, Ste. D
		Davis, CA.   95616
		(916) 756-1104