Active GUI element

Static GUI element

Code

WPS object

File/Path

Command line

Entry-field content

[Key combination]

more

It has been said for many years that death and taxes are inevitable. The computer age has made it clear we must add hard disk failures (whether catastrophic or gradual) to that list. It's not a question of "if" a drive will fail, it's a question of "when." With this in mind the prudent computer user plans for this event and is prepared with suitable backups and a recovery plan.

This discussion describes a plan using DFSee and Info-ZIP's archival utilities running either under OS/2 or from bootable media (CD or diskette).

The advantages of two physical drives

While there are definite performance advantages to having your file systems split across more than one physical drive, the real advantages are in backup and recovery options.

1. OS/2 maintenance partition on the "other" drive

   The "other" drive is the drive that does not have the normal OS/2 boot partition; usually a secondary master or a slave.

   This means that you can always boot OS/2 from a hard disk and have whatever tools (besides DFSee, of course) you want in emergency situations. If the hard drive with the boot manager partition is the one that fails, a little work with LVM or DFSee will make the maintenance partition bootable.

2. Partition backup to the "other" drive.

   I have dedicated partitions on each drive for image [byte-for-byte copy] and ZIP backups of my working partitions. While this makes the ZIP operation faster, the real purpose is to ensure that a single drive failure won't lose any backup information that hasn't been archived to removable media (CD or DVD, USB attached hard drive, tape, etc.) and allows me to reduce the frequency of archiving to off-computer media. This will not protect against a failure such as a controller or power failure that wipes out both drives.

3. It allows fully unattended backups. My scheme is to start a cron job (I use cronrgf) in the middle of the night that first backs up the maintenance partition and some data partitions - each to space on the "other" drive. It also does DFSee backups, running both DFSDISK and DFSee 'GENPART' (Generate Partition) from a REXX script:

   'cmd /c "g:\os2progs\misc\dfsee\dfsos2 dfsdisk 1"'
   'cmd /c "g:\os2progs\misc\dfsee\dfsos2 dfsdisk 2"'
   'cmd /c "g:\os2progs\misc\dfsee\dfsos2 genpart 1 genpt -f-'
   'cmd /c "g:\os2progs\misc\dfsee\dfsos2 genpart 2 genpt -f-'
   

   I then use SETBOOT.EXE to reboot the machine to the maintenance partition which has a REXX cmd in the startup folder to look for a flag file indicating that this is an automatic boot for the backup system (there's a screen message and a pause to allow this to be interrupted if the boot was manual and the flag file hadn't been cleared for some reason). The backup program in the maintenance partition finishes the ZIPping - most importantly that of the primary OS/2 boot partition, so that it is not active while being ZIPped. Finally it uses SETBOOT.EXE again to reboot to the main OS/2 boot partition.

I don't have this luxury on my laptop with only one physical drive, and the backup partitions don't have enough room for a full backup, so the process is a little bit more manual, although I use variants of the same programs. I then ftp the files to my desktop machine where I can burn the laptop backup to a DVD.

Data backup methods

There are many ways to back up a partition, each with its own proponents. One critical requirement is that there be a restore procedure that works in the absence of an operating system on the machine. (This usually means booting from disk or CD, whether DOS, or DFSee, or an eCS install CD, or a Linux CD.) Needless to say, the restore procedure should be understood and tested to make sure it does the job when it becomes vital.

My own backup scheme currently uses DFSee image files with smart compression for a Win2k boot partition, and Info-ZIP [utilities] for everything else. I've successfully restored eCS boot partitions from a ZIP file (created from a maintenance partition so the boot partition isn't active) several times.

Advantage of DFSee images:

• save/restore any partition type on DOS/WIN/OS2 or Linux platform

• exact image, even for non-supported file systems

• May be the only safe way of restoring a Win2k/XP boot partition, an NTFS partition, or any Linux partition (other than with a platform-specific tool).

Advantage of using Info-ZIP ZIP files:

• automatic defragmenting of the file system on restore

• standard ZIP files - unzip is available for almost every platform

• ZIP files are dramatically smaller than images

• Can restore to a different file system type (for instance, a HPFS partition can be restored to a JFS partition)

• Can restore to a partition of a different size than the original

• Use of exclude files in the ZIP process can eliminate stuff not needed to be restored (such as TEMP, Browser caches, etc.)

A limitation of using ZIP files is that for file systems with long filenames, the platform used for doing both the zip and unzip must include file system support for the appropriate file system (JFS, FAT32, etc.) and, if appropriate, long file names. In particular, on an OS/2 platform, to backup and restore a FAT32 file system requires that FAT32.IFS is installed and operational.

Note that there are reports that a Windows boot partition cannot dependably be recreated from a ZIP image; this may be due to the use of hard-coded sector addresses by that operating system.

Disk structure backup/restore

In addition to restoring contents of the file system(s) on a drive, you probably want to restore the layout of the partitions on the disk. If the replacement disk drive is larger than the one that failed, you may wish to make some of the partitions larger. This is where DFSee can help.

The easiest (and most error prone) way is to run DFSee and write down (or print) the partition overview - before the drive fails! Then you can, using DFSee or LVM, recreate the structure of the disk before restoring any of the data.

The process can be automated. Running GENPART from a script or from inside DFSee (Mode FDISK > Generate part. scripts) for the drive(s) creates a DFS script file that can later be run from inside DFSee to recreate the partition structure complete with LVM information. The script can be edited to change partition sizes up to the maximum partition size that the file system on that partition can support.

Here's the help for DFSee GENPART:

Generate DFSee SCRIPT to create partitions for specified disk(s)

 Usage: GENPART  disknr | . | *  filename  [descr] [-s] [-f-]

   disknr    = disk-number, '.' for current or '*' for all disks

   filename  = base filename for the script to be created, the actual
               disknumber is appended to this, and a default file
               extension of '.dfs' is added.

   descr     : Optional description string that is added to the
               confirmation message when the script is RUN later.

   -s        : Use SECTOR based size and location values (exact copy)
               instead of regular cylinder and megabyte values.

   -f-       : Do NOT include freespace areas; allows automatic
               placement of the new partitions by DFSee (no location)

   -!        : Force interactive dialog to specify/confirm options

so: dfsos2 genpart 1 T:\gpt -f-

creates t:\gpt1.dfs for disk 1; the meat of this is:

cr pri 1b  2204 -a:0,c    -S:3 -L:"-v:'win2k-vol' -p:'pripart-w2k' -l:'I' -m"
cr pri 0a     7 -a:281,c  -S:0 -L:"-v:'' -p:'[ BOOT MANAGER ]'" -F
cr pri 07  2502 -a:282,c  -S:2 -L:"-v:'ecs-sata' -p:'ecs-sata' -l:'F' -m"
cr log 07  1804 -a:601,c  -S:0 -L:"-v:'V04 - FAT16' -p:'P04 -  1804.1 MiB' -l:'E'"
cr log 35 39793 -a:831,c  -S:0 -L:"-v:'kvol' -p:'kpart' -l:'K'"
cr log 0c 10001 -a:5904,c -S:0 -L:"-v:'d-vol-f32' -p:'d-part-f32' -l:'D'"
cr log 35 20002 -a:7179,c -S:0 -L:"-v:'h-vol' -p:'h-part' -l:'H'"

The (partial) syntax of the DFSee cr command is:

cr[eate]  parameters   : pri|log  [type  [size  [loc  [pos  [BMGR-name]]]]]]

pri|log:  partition is PRIMARY or LOGICAL
type:     partition type code
size:     partition size
          nnnn = megabytes (normally you would use this)
          nnnn,s = sectors
          nnnn,c = cylinders
loc:      -S:  Preferred partition table slot (0=default)
pos:      (not used here)
lvm info  -L:"lvm string" - see LVM cmd doc
-F        bootable flag

You could edit this as follows:

cr pri 1b   2204 -a:0,c    -S:3 -L:"-v:'win2k-vol' -p:'pripart-w2k' -l:'I' -m"
  (FAT32 W2k boot - leave alone; will be restored from a same-size image)
cr pri 0a      7 -a:281,c  -S:0 -L:"-v:'' -p:'[ BOOT MANAGER ]'" -F
  (don't change this)
cr pri 07   3502 -a:282,c  -S:2 -L:"-v:'ecs-sata' -p:'ecs-sata' -l:'F' -m"
  (make this and any of the next larger if you want)
cr log 07 1804 -a:601,c  -S:0 -L:"-v:'V04-FAT16' -p:'P04 -  1804.1 MiB' -l:'E'"
  (this is fat16; don't make larger than 2 gig!)
cr log 35   9793 -a:831,c  -S:0 -L:"-v:'kvol' -p:'kpart' -l:'K'"
  (JFS single volume partition)
cr log 0c   0001 -a:5904,c -S:0 -L:"-v:'d-vol-f32' -p:'d-part-f32' -l:'D'"
  (FAT32)
...

DFSDISK output can be used instead of GENPART, but this doesn't make it as easy to modify the partition sizes and set up as the script created by GENPART. DFSDISK creates 5 files per disk which are complementary to the GENPART output. They include a good ASCII representation of what the disk looked liked, and also a binary file that can be used to do a direct PRESTORE to the same or a different disk. In that case, all partitions are 'recreated' exactly as they where at the moment the DFSDISK was run.

Restoration

1. After booting DFSee from CD or diskette, or an eCS install CD, or a maintenance partition, start DFSee and enter in the command line:

   RUN gpt1.dfs
   

   gpt1.dfs is the edited script that had been created by genpart

   When using a (GENPART created) script, DFSee takes the default image for the bootmanager that is available in DFSIBMGR.IMG and applies that as a part of the CR(eate) of the 0x0a type partition.

   If you do not want BootManager installed, you must use the -I- option on the DFSee CReate command, and install BM manually later.

   If you want to install BM using the standard tools (LVM), you must remove the CReate command for its partition (leaving it as freespace), or delete the partition before invoking LVM.

2. RESTORE from IMAGE files

   For those partitions that were saved as DFSee images, you can use from a DFSee menu:

   Actions > Restore/compare image files > to a partition

   Then select the source of the image and the target partition and the options (default should work for most situations) - be sure that Restore, write to object is selected.

3. FORMATTING

   This starts to get more complicated. Filesystems that are not restored from images need to be formatted by an operating system that understands the filesystem type. At present, DFSee has no formatting capabilities, although this may change in future releases.

   See the following table:

   Table 1: filesystem types, and the operating systems that are capable of formatting that type

   File system	Operating system
   FAT16	OS/2, DOS, Windows
   FAT32	Windows (W2k or XP; W98SE)
   HPFS	OS/2
   JFS	OS/2, Linux (with JFS installed) Interoperability between OS/2 JFS and Linux JFS is not a sure thing. Proceed with caution.
   NTFS	Windows (NT, W2k, XP)
   Reiser	Linux
   ext2, ext3	Linux

   If you are restoring a Windows boot partition from an image, you can then boot to it and use Disk Management to format the FAT32 partitions. Be careful to get the correct partition - drive letters will initially be assigned sequentially and not as set by LVM. Windows' Disk Manager can assign any available drive letter to any partition.

   Do not change the boot-partition drive letter (most likely C:)!

   Similarly, an eCS install CD can be used to format FAT16 and HPFS partitions. Again, be careful about getting the right partition - depending on what has been booted, the drive letters may or may not match the LVM information that was restored from the script.

   The OS/2 format command:

   format  x:  /FS:yyy  [/L]
          x: drive letter
        yyy: HPFS or FAT (fat16) or JFS
         /L: format with Long (and slow) media check
   

4. RESTORING from ZIP files

   Like the creation of the ZIP backup file, this must be done from an operating system that understands the file system format being restored.

   From the root of the partition to be restored, issue:

   unzip x:zipfile
   

   where x: is the drive where zipfile is located.

   Note that the zipfile from a HPFS partition can be restored to a JFS partition.

   Usually it should be sufficient to restore an OS/2 boot partition while booted from CD, and then boot from the hard drive to do the rest of the zipfile restores.

5. CHECK WHAT'S BEEN DONE

   From an eCS install disk boot maintenance console (or a maintenance partition) run LVM from the command line and recheck the LVM information and partition sizes.

   Also from a command line, use the DIR command on the partitions that have been restored and verify that what's there is what's expected.

Notes for Windows or Linux users

The preceding was written from an OS/2 viewpoint, but much of what is discussed is applicable to the Windows (95/98/ME/NT/2000/XP) environment, or most flavors of Linux. Info-ZIP's zip.exe and unzip.exe are available for Windows as command line tools, and there are other ZIP programs that you may prefer. Linux users will probably want to use tar and gzip.

Without using a form of REXX (either from IBM or a REXX clone like REGINA), scripting in Windows may be more difficult, but much of it can be done with simple .CMD files.

Linux shell scripts (along with cron) automate the process for that environment.

It is suggested that you make the boot partition image backup while booted to DFSee from CD or diskette. It may be useful to have one or more FAT16 partitions (not larger than 2GiB each) on a hard drive so that the DFSee operating environment can write the image files, or modify the DFSee media to include network or USB drivers to write directly to an external device or other machine.

The discussion about Boot Manager is probably irrelevant, although if you do use either the IBM Boot Manager or a 3rd party product, you can restore it from an image if it occupies a partition. If it resides in the MBR, you probably have to reinstall it.

Acknowledgement

I acknowledge the assistance, critique and help provided by Jan van Wijk, the author of DFSee.