Also, as it is command line driven, it is easy to incorporate into other scheduling utility scripts that automatically run at certain times of the day.

    dccsssss.ggg
             |||  = generation number
       |||||      = file number (roughly a hundred thousand source files)
     ||           = reserved for tracking "chunks" of large split files
    |             = drive letter of source

The esc  key may not function under Windows due to the way Windows handles the keyboard. Also, under Windows, use the Control+Break key instead of the Control+C key. If the compression or cipher user exits are being currently executed, Windows may not allow BackEmUp  to recognize the Control+Break sequence, so try repeatedly.

Special command line options

This is a short summary of some of the command line options. Entering BackEmUp  with no parameters will give you the compete list of valid command line options.

• /init

Used for first time initialization of the control file. This will cause the creation of the control file, but no files will be backed up. Thus, the operator can edit the control file to apply special Exclude commands, or tweak other options.

• /KEY string

This allows you to pass a dynamic seed cipher key to the cipher program. This seed key is manipulated resulting in a key phrase that will be substituted in the template(s) at the location specified by "$key".

• /BSNAME string

Allows a way to uniquely identify individual backup sets such that additional protection is provided from mixing diskettes. For example, you may identify the backup set name as "my_docs" for the backup set containing your documents vs a backup set name of "drive_d" for data from all of drive d:. By default, the backup set name is "BACKEMUP".

This string is placed in the ID file on each media and provides the name of part of the ID file: i.e. BACKEMUP.ID or MY_DOCS.ID and also provides the name portion of the CTL file: i.e. BACKEMUP.CTL or MY_DOCS.CTL etc. Naturally, it should be 8 characters or less for manageability.

The user may issue a "type a:backemup.id" command to see the volume number, backup set name, and applicable source directory for that particular backup media.

You could use this BSNAME option as a "belt and suspenders" method of managing multiple different backups. Its up to you. For many people, having all the control files names "BACKEMUP.CTL" is perfectly fine. Others may want to use different names to help them remember what is what.

• /orphans

By default, when a backup volume is mounted it is automatically checked for consistency. Any file in the backup files  subdirectory that follows the appropriate backup file name convention is verified to be referenced by the backemup.ctl  control file. If a file exists but is not referenced, it is considered to be orphaned. Orphaned files will be listed (and kept), and by default, BackEmUp  will wait for the user to acknowledge this situation. Optionally, this acknowledgement prompt can be skipped by specifying /orphans+  to instruct BackEmUp  to effectively ignore these files. /orphans-  instructs BackEmUp  to automatically erase any orphaned files it finds.

A situation where orphaned files appear should not be considered normal.

• /rest

Signals that a restore operation is to be performed.

• /redir path

Redirect the restore operation to a different location other than originally backed up from.

• /rgennn

Restore generation nn of the file(s).

This has three flavors. If the option is not specified, it operates as if 1 was specified:

Positive number greater than 0

This will operate on a absolute generation of a file. i.e., /rgen2 will restore the 2nd generation of a file or series of files. Give some thought to this and you can see that for a file that does not change very often, that file can be significantly older than other 2nd generation files of more actively files. This is highly useful in selective restore of individual files.

The default operation (/rgen1 if the option is unspecified) allows easy restoration of the currently backed up version of erased or changed files.

A value of 0

Only the current active generation of the file is selected. Files that were erased at the time of the last backup are NOT restored. This option is most useful if you want to do a complete restore to the image of the last backup without restoring "erased files" that have not yet been purged. Refer to the trickle purge option for related topical information.

Negative number less than 0

This will operate on relative backup invocations considering the entire backup set rather than absolutely on individual generations. Specifying /rgen-2 will mean the files as they were two backup invocations ago. In this case, some files that seldom change may not have needed to be rebacked up and thus the restore logic could rightly select the current generation for some files, the previous generation for others. Think of this as a "restore" to a certain backup date level instead of to an absolute generation number for a file. It can useful in system restores.

Combine this option with the /rpt  option to further explore the effects.

• /diro

Controls the restoration of only the subdirectory information or only the files.

Typically, one would not specify this option.

/diro+

Restore directory information only. No files

/diro-

Disregard directory information and restore files only into a single directory.

• File Replacement action

/replacemissing

Only restores files that don't already exist.

/replaceall

Restores and overwrites all files.

/replaceprompt

Asks you what to do for each file that exists.

/replacenewer

Will restore the file if the file doesn't already exist OR the selected backup generation is newer than the existing file. This would be used to "upgrade" the files. For example, you re-installed some files and now you want to apply special fixes.

/replaceolder

Will restore the file if the file doesn't already exist OR selected backup generation is older than the existing file. This would be used to recover a file to a previous version.

• /prompt

During the restore process, prompts for desired action when a file does have an appropriate backup generation but does not exist. (The default action is to not prompt but to automatically restore.)

• /rename

Causes a restore operation to rename the existing previously restored file from its short name to its long name.
Note: This will only rename files. It will not copy files from the backup media.

Typically, this option is only used when restoring a Windows system from a complete disaster where the initial critical files were restored under a DOS boot diskette.

• /rpt and /detailedrpt and /list

These options generate various reports:

/list  reports on what would be backed up

/rpt  and /detailedrpt  report information about existing backups.

When optionally combined with the /rgen option, additional specific information about what has been backed up will be output. /detailedrpt  yields a more detailed report. The output is written to "stdout" and thus can be redirected to a file for printing or other purposes. You may also specify a file mask to report information about a particular file or set of files.

The backup summary report (/rpt) gives the backup run date and the number of files backed up at that time. If an "*" is displayed as the first character, it means that this backup invocation instance has had some files roll off due to the generations specification.

Specifying a file mask (even it is "*" for all files) will display detail information about when each file matching the mask was last backed up.

Specifying the /rpt option with a negative /rgen value will give detailed information about restoring to that particular date in time.

Examples:

/rpt

reports a summary of the number of files backed up during each backup invocation and when that incremental backup run was made.

autoexec.* /rpt

also reports when and where all the files matching the mask (in this case, those autoexec.* files) were last backed up.
For a complete list of when they all were backed up, use a mask of "*".
To see a report of only what was backed up on the last run, use "* /rpt /rgen-1".

autoexec.* /detailedrpt

in addition to the above, also reports on all generations of the matching files.

autoexec.* /rpt /rgen2

reports when the previous generation (#2) of files matching autoexec.* were backed up.
Likewise, /rgen3 reports when the grandfather generation was made, etc.

autoexec.* /rpt /rgen-2

reports which files (matching the mask) were backed up on a specific backup instance.
Note, this expands upon the summary report by showing the files status. For example, the summary might indicate that on "Backup run -2 as of Sun xxx xx xxx xx:xx:xx" there were 15 files backed up. This option with a file mask of "*" would display which 15 files those were.

autoexec.* /detailedrpt /rgen-2

This expands upon the above report by also including sections detailing which files had not changed from the previous backup (and when that was) and which files were not yet in existance as of that backup instance date.
This report would be useful to determine what activity would be needed to roll back the system to that date.

/list will scan for changes that should be backed up, but will not perform the backup itself. The output is a list of files which is written to "stdout" and thus can be redirected to a file for printing or other purposes. It will not verify the contents of the backup media for missing files.

/dtllist is similiar to /list plus listing the details of each file, including the selection reason for backup.

• /drop

  This is used only to override normal operational activity. Its purpose is to discard specific backups of specific files. For example, you just made a backup and realized that changes to a specific file were inappropriate. So after you restore that specific file to a previous version (perhaps using /replaceprompt and /rgen2 options to skip past the "bad" generation), then you might want to "forget" (remove from the backup media) the current generation of that file that has the inappropriate changes. Alternatively, if you just re-ran the backup, the recently restored file would get backed up again rippling the inappropriately changed file backup generations and thus possibly discarding a "good" generational backup.

  A file mask may be specified in conjunction with the /rgen option.

  To discard all backup generations for a file, specify /rgen0.

  When used with a file mask and the specific generation does not exist for a candidate file, no action is taking on that candidate file. For example, if /rgen-2 was specified and no backup generation was created on that specific backup date, no drop action will happen for that specific file candidate.

  The drop can be limitted to an individual volume by specifying the /volnn parameter, where nn is the volume number.

  The options for file mask, generation, and volume are all cumulative.

Control file special commands

By default, the control file is "backemup.ctl" and it exists on the backup media. A copy also exists on the hard file in the logical root of the backup source. This is a copy for reference only. The program uses the copy from the backup media for all operations, thus there can be multiple backup sets from the same source specifying different options. Therefore, if you make any manual changes to the control file, edit the one from the backup media, and save it as a plain text file!

The control file consists of one line records. Each record is identified by a type  as the first character. The following are record types:

• ! - BackEmUp control directives
• * - Informational comment
• @ - Include/Exclude specification
• V - Identifies volume numbers and freespace on the volume
• D - Directory information
• F - File information

• File and Directory record layout

This layout is subject to change. The fields in order are:

char

Identifier = "F" or "D"

date

time_t format of when the entity first qualified to be backed up

long name

Quoted string of the original full path/name

short name

Shortened file name. May not be present for all cases.

Generation record

Repeating structure delimited by ( ) containing:

volume number

volume containing the backed up data
If the source was split into multiple chunks due to size, each chunk will have its corresponding backup volume number listed.

backup file name

name of the file containing the backed up data

attributes

file attributes (proprietary encoding, subject to change)

file date

date and time of the original file

file size

size of the original file (in bytes)

EA size

size of buffer needed extended attributes

EA verification

polynomial to verify the extended attributes

backup date

date and time when this file was backed up

• Exclude or Include
Sample:
@ Include "*"
@ Exclude "C:\WINDOWS\*"

These are processed sequentially in the order listed in the control file. This can be used to exclude most of the files from a large application, but include the user customized files. For example:

@ Exclude "C:\NETSCAPE\*"
@ Include "C:\NETSCAPE\USERS\*"

This instructs the program to exclude all below Netcape except for the Users subdirectory and all below that.

If the Include/Exclude path does not specify a path (for example, "*.cfg"), the it will apply to any and all subdirectories.

! DIRECTORY_LEVELS

The number of subdirectory levels to include. Default is 32767 which effectively means all subdirectories.

! ARCHIVE_FLAG_MANAGEMENT

TRUE will cause the program to manage the "A - archive" attribute. Setting this option on will cause files that have the "A" attribute on to be backed up and the "A" attribute reset on the file. If this option is off, the program uses the file's timestamp and/or size to determine if the file should be backed up.

! GENERATIONS

The number of versions (generations) of a file maintained on the backup set. Thus you can keep the most recent version and previous version(s) for restoration. By default, generations = 2. You may use the /gen command line option to override this default. For example, /gen3 will specify 3 generations.

Operationally, the program will insure it has successfully created a new generation on the backup set before allowing eligible previous generations to be discarded.

! MINIMUM_GENERATIONS

This can be used to ensure there a adequate generations of a file on the backup media. Normally, a file is only copied to the backup media when it has been changed. This can override that by ensuring that there are nn copies of the file on the backup media even if it hasn't changed. The default value is 1. This can be changed with the /mingen command line option. For example, /mingen2 will cause 2 generations to be kept regardless of change activity. Used with the distinct volumes  option, you can be safeguarded against losing the only backup copy of a file if a backup volume becomes bad. For example, application program files may never change whereas the data files typically do. This option could be used to keep an extra generation (copy) of the program files on the backup media. Typically, you wouldn't need to do that as you would simply re-install your application from its installation media, however, this option provides just a little more flexibility. Obviously, this option must equal or be greater than the generations option.

! KEEP_EXCLUDED

This affects what happens to files that are excluded ( @ Exclude directive ) and not what happens to files that are normally erased from your source. (See ! TRICKLE_PURGE to control how normally erased files are treated. This flag has no effect on that operation. What this KEEP_EXCLUDED flag controls is if your exclude mask specifies that this file isn't going to participate in the backup process any more, it will be kept anyway.

If you Exclude a file (or bunch of files), enabling this option will prevent those files from being discarded from the backup set. If the option is disabled, then generations for those files will start to be discarded. Why would you want to do something like this? For example, you might want to back up some of last years data and then erase it from your hard file, but you want to be able to retrieve it later from your backup set. This option allows you to do just that by excluding those files explicitly and setting this option. Remember, if you don't exclude them they will start to be discard from the backup set. Also remember if you decide at some point to disable this option, then the purging will resume for all files that aren't existing anymore.

! PURGE_DELETED_FILES_FROM_INACTIVE_VOLUMES

This option modifies the behavior when a candidate file no longer exists but does have a generation on an inactive volume. The default option is FALSE which will indefinitely maintain the record of the deleted file in the BackEmUp.ctl  control file. Thus, if you do a restore operation, these deleted files will reappear as they are restored from the inactive volume. If the purge  option is enabled (set to TRUE), then although the file will NOT be erased from the inactive volume, BackEmUp  will discard the record of the oldest generation, thus it will be eventually purged from your backup set as described above for the Keep Excluded option. When you created your Read Only inactive volume, you should have copied the current BackEmUp.ctl  control file to that media, thus for historical purposes, the file could easily be restored. By enabling this option, you will not get previously deleted files restored unexpectedly.

This option has no effect on the number of extra generations tracked on the inactive volume(s), thus if the generations option is set to 2, you could have 4 or more generations of an active file tracked: 2 generations on active volumes, and possibly 2 or more on various inactive volume(s). The thought process behind this is that if the file exists, then all generations on inactive volumes will be tracked to facilitate the greatest flexibility in restoring. If the file no longer exists, then records of its previous generations will be purged or kept depending on this Purge  option setting.

! TRICKLE_PURGE

By default, if a file was backed up and is now erased from your source, it is not immediately erased from the backup set. Instead, a counter is initialized to the "nn generations to keep" option when /trickle+ is enabled by default. (Optionally, you can specify an exact value for the nn delay as a value independent of the # of generations. For example, /trickle5) Each subsequent invocation of BackEmUp  will decrement that counter and remove that generation from the backup set. Thus, after nn+1 invocations, the file will be completely purged from your backup set. (It isn't done all at once just in case you erased something that really didn't want erase, in which case if you had multiple generations backed up, you might have several chances to restore it from the backup set before it is completely purged.) With generations=2, you have until the 3rd backup (2 + 1) to recover the file.

If you desire to immediately purge the active volume(s) of all generations of normally deleted files, specify /trickle-. This will cause immediate erasure of all generations from the active backup media when the file is detected as being deleted. Please note that this happens only for those volumes that are mounted for backing up other file candidates.

Specifying /trickle! sets the trickle state to Never  and thus the files will remain on the active on-line backup media forever.

! REMOVEABLE_MEDIA

This signals whether or not new media can be mounted in the backup device to extend the backup set to multiple media. This would be set to FALSE ("RM-") when backing up to a lan drive or another hard drive subdirectory. Another variation when backing up to a lan drive (or similiar) is to set "RMA" such that when the "maxvolsize" limit is reached, the set is automatically subdivided to create an off-line readonly volume, and the backup will continue. See the related sections for more information.

! DISTINCT_VOLUMES

This prevents multiple generations of a file from residing on a single backup media. Thus, for the "belt and suspenders" type of person, this will ensure that if an individual backup media becomes destroyed, that another generation may exist on another disk. Obviously, this is only applicable to removeable media, and if requested generations to keep are greater than 1.

! MAX_VOL_SIZE

This option applies to non removeable media, and is intended to limit the backup volume size on large drives such that the backup could be mastered onto a CD or DVD. It defaults to approximately 695 meg to allow room for other files and support programs to mastered onto the CD along with the backup volume information.

To get the most usable space from a typical 700 MB 80 Min CD, you should create the CD in Single Session mode. Variations in CD Mastering programs may cause a variation in the number of files (bytes) that may be written to a CD. BackEmUp's  estimation may not exactly correspond to the calculations of your CD Mastering program. Also, due to the high number of files located in the FILES subdirectory, successful CD creation may require creating an ISO image first, then burning the ISO image to the CD.

This size can be edited in the control file, or by a command line switch, for example /MAXVOL713031680 would allow approximately 680 meg of backup files in the FILES  subdirectory. Remember, each megabyte is actually 1048576 bytes and not a million! When specifying this option, do not use commas for readibility.

Setting this option to 0 will disable this check, thus the size will only be limited by the physical size of the media.

This option supports very large backup media sizes, including typical DVD sizes that can range greater than 8 gig per volume. Enter the limit as the number of bytes. Abbreviations such as "G", "M", or "K" may be used as a short hand for standardly accepted values. i.e. 600M would be (600 * 1024 * 1024) bytes.

! MAX_CHUNK_SIZE

By default, BackEmUp  will automatically break very large files to smaller more manageable pieces. For compatibility with standard utilities, each "chunk" of a file should be the smaller of 2 Gig or the size of the backup media. In certain situations where temporary space is limitted, BackEmUp  may automatically use a smaller chunk size as needed.

To override the defaults and suggest a different chunk size, use the /MAXCHUNKnnnnnn command line option.

! TARGET_MEDIA_ALLOC_UNIT

This option works in conjunction with MAX_VOL_SIZE and is intended to allow the specification of a different minimum allocation unit size than what is actually used on the current backup media. For example, this would be appropriate to set when the intention is to create a CD for an inactive volume that will be made from a subdirectory on a hardfile. Whereas the hard file might use a different and perhaps much larger minimum allocation unit size than a CD, thus the volume might not be completely filled. For example, a lot of small files might consume a great deal of extra hard disk space on a hard disk that allocates in blocks of 32768 bytes whereas the actual target of the inactive volume might allocate in blocks of 2048 bytes.

COMPRESS and CIPHER

These enable or disable the user exits to appropriate user supplied program.

Control file user exit templates

• $file
• $archive
• $key

Compression

Encryption

These specify the system commands an options for these user exits. BackEmUp  will substitute strings for $archive, $file, $dir  during operation as appropriate. BackEmUp  has provisions for working around long name restrictions with a compression program. i.e. For the restore operation, BackEmUp  will use temporary files such that all intermediary operations use short file names and then put the final result into where it belongs with the appropriate long file name (if the operating system supports it). See the section on Disaster Recovery  for more information.

If the corresponding option is enabled, edit these templates to match your specific user supplied program parameters.

Explanation of the sample templates provided

• zip
  -q
  quiet operation
  -S
  include system and hidden files
  -D
  do not add directory entries

  unzip

  -qq

  super quiet operation

  -u

  create files

  -j

  do not make directories

Operating System differences

There are native versions of BackEmUp  for OS/2, Windows, and DOS. The only significant difference between them is in long file name processing and Extended attributes. As hardly anybody uses DOS anymore, and DOS has severe memory and resource limitations, BackEmUp  for DOS has been optimized for use during the Windows disaster recovery steps. Its control file read operation has been pruned to only consider files in the root and certain Operating system directories, such as you need to restore a minimal Windows system from the Windows Emergency Startup diskette. If for some reason you desire full support, use the /FULLDOS  option.

OS/2 can handle long file names even when booted from its disaster recovery floppy disks. Therefore, its compress/uncompress templates include quotes around the portions of the file names that could contain embedded blanks. This would only be a consideration if you are restoring compressed files to a different operating system, and it is simply managed by putting the correct compress/uncompress command templates into the control file.

OS/2 uses extended attributes whereas DOS and Windows do not have the concept. They will be lost if you backup on OS/2 and restore to Windows.

Disaster Recovery

Hopefully, you will never need these steps. This sections covers how to recover from a complete system failure. Typically, you would boot from floppy with your Windows emergency Startup boot diskette, access your backup media, and restore the system files using the /rest option of BackEmUp.

Alternatively, you may choose to use another backup program for your initial backup of your operating system, and only use BackEmUp  to manage select multiple generation backup of your data files. The multiple steps listed below to fully restore a completely destroyed Windows system may seem overly complex; but that is only because of the long file names of Windows vs the short file naming convention of the Windows Emergency Startup disk.

These steps listed below assume your operating system boot drive has been totally destroyed. Obviously, if it was another drive or just a subdirectory that has been destroyed, you can simply restore those files in one step as your operating system is still fully functional. Again, these steps below are shown assuming a total system failure.

Windows

Step 1: Windows 95/98 Startup disk

Make sure you have created a bootable Windows startup disk. (Use the control panel, install/remove software, and select the tab to create the startup disk.)

Note, when booted using the Windows Startup disk, you are essentially running DOS. This limits the programs that you can run until you get the rest of your system functioning. It would be a good idea to boot from the startup disk before a disaster to insure you have access to the devices you need, and if not, create the diskettes necessary to access those devices.

Step 2: Disaster recovery diskette

Insure that you have drivers installed (or available) to access your backup media. For example, if you are backing up to an Iomega Zip  drive, you may need to copy the guest software from the Iomega tools subdirectory: i.e. Copy the "guest.*", "*.sys", "*.ilm", and "*.mpd" files from the Iomega tools subdirectory on your hard disk to your disaster recovery floppy disk. This will allow you to access your Zip drive if your entire hard file has crashed and you have had to boot from floppy using your Windows 95 Emergency Startup disk.

If you are using compression or enciphering extensions, make sure those programs are also copied to the disaster recovery diskette along with the BackEmUp and BackInfo programs for DOS (as the Windows 95 emergency startup disk is not a fully functioning Windows 95 system) as well as the Windows version of the BackEmUp  and BackInfo programs.

If you have the capability, you could considering creating an inactive volume on CD-R (or CD-RW) for the files needed to restore the operating system, and put all the tools on the CD. The Windows 98 Startup diskette has built in CD Rom support whereas under Windows 95, you would have to add those CD drivers manually.

Step 3: Restore the critical operating system files

Step 3.1

You will boot from floppy using your Windows Startup Diskette.

Check the hard disk for errors and correct them before proceeding any further.
Depending on the type of disaster you experienced, you may have to reformat (i.e. format c: /b  ) or repartition your hard drive, or issue the sys c:  command. You should not attempt to change drive characteristics. If you do reformat the boot partition, remember that Windows 95/98 is a DOS extension and DOS requires certain files to be in the root directory in a specific order. The format c: /b  command will reserve space for the special files allowing BackEmUp  to restore them to the proper location. Alternatively, the format c: /s  command will put DOS files in the correct order, but when you restore the windows components, be sure to specify the /replaceall  option so these files will be corrected for a windows boot. This can the initial problem if you find that (1), you can't boot the drive at all, or (2) when it boots, it only starts to a DOS command line and not the graphica Windows GUI.

Step 3.2

Next, using the DOS version of BackEmUp , you would restore (using the /rest option) the boot/hidden/system files in the root of C:\ as well as the "Windows" subdirectory.
i.e. BackEmUp    C:*    x:    /rest /replaceall

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

The DOS version has been tweaked to only consider the appropriate files for restoring a minimally booting Windows system.

The reason behind this DOS step at this point is we want to restore the system and bootable files in the root along with the Windows system files, but we don't want to restore the rest of the system as there could be a naming problem switching from short names to long names once we get a bootable Windows system restored. And as we've had to boot using the emergency Startup Diskette, long file name support is not available. So at this point, we are just going to restore the bare minimum to get the system to boot from the hard file to a minimally operating Windows GUI.

Note: Files in the C:\ root directory and in C:\WINDOWS are never compressed to facilitate this reload step. However, you may need those decompression program files to do a full system restore after you reboot for step 4, so make sure you have them handy.

Step 3.3

Note, at the end of this step, there should NOT be a "Start Menu" subdirectory: i.e., the "C:\WINDOWS\STARTM~1". If so, delete it and everything below it. Why is this necessary? It appears the Windows will automatically create this long name when it boots in the next step. If it does create one, it will have a short name of "STARTM~2" which will mess up the remainder of the restore operation.

By default, the tweaked DOS version of BackEmUp  should not have restored it. If it does indeed exist, you can easily do this deletion by changing to "C:\WINDOWS\COMMAND" subdirectory that you have just restored and issuing "deltree C:\WINDOWS\STARTM~1" 

When the system boots from the hard drive the first time, Windows will create a dummy empty one with the correct short and long names. Then when the next step runs under full windows, it will put the correct items back under the "Start Menu" subdirectory.

Step 4: Restoring the rest of the system and long file names

After rebooting the minimally restored system, windows may struggle up the first time or two, so if Windows fails to boot, try booting again. You may have to do this a couple of times as Windows struggles to come up with this minimal file set. If you have a network card, you might want to temporarily remove it. Eventually, Windows will come up to a very minimal desktop that may appear to have missing and/or wrong images for icons. This is normal as we've only partially restored the system so far.

You will need to get to a command prompt. This can be done even though the system is only partially restored. Simply select "run" from the Start Menu and browse up to "My Computer" then the "C:" drive and select "command.com" as the program to run.

Step 4.1

Booted up from the minimally restored operating system files on the hard disk, run the Windows version of BackEmUp  to rename the files we just restored using short names, to the full long name version of the file.
i.e.: BackEmUp C:*    x:    /rest /rename to rename (for long file names).

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

If during this process you get a message about "invalid command interpretter", you should issue:
BackEmUp C:\command.com    x:    /rest     /replaceall
to restore the command interpretter again and reboot.

It is normal to receive many "file not found messages" at this step as you have only restored part of the system!

Examine the system for any incorrect long name/short name aliases and correct before going any further.

Step 4.2

Reboot Windows again to make sure it is "clean".

Finally run the Windows version one more time to restore the remainder of the system using the long file names.
BackEmUp C:*    x:    /rest

This will correct the icons on your desktop as well as fill in the programs in the Start Menu.

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

Miscellaneous notes

Depending on what you have done to your system, a long file name at this point might have a different short name that it originally had due to pecularities of Windows. i.e. "A Long File Name" may have originally been equivalent to "ALONGF~2" depending on many factors, but this restore step may create the equivalence as "ALONGF~1". However, the system should function correctly.

Your desktop may appear different and many of your menus may be empty during some of these intermediate steps, but don't worry as you've only restored part of your system in the early steps.

During the boot process, you may experience error messages from the system trying to find application installed drivers that you haven't restored yet. If these are preventing you from booting to a functional MS-DOS prompt from within Windows, then repeat step 3 but restore the specific files Windows is complaining about. If the errors are non fatal, ignore them for now as you attempt to restore the rest of your application files.

Step 5: Reboot your system

Your operation system and files on the boot drive should now be fully restored. Your desktop icons should appear as what you've been used to seeing before your disaster. It may require that you actually double click on the icon for it to change correctly, but that would be a one time act.

Check the system for any errors.

Step 6: Restore any other drives that may have been damaged

For this step, you don't have to do anything complex; for example, just run
BackEmUp d:\path x: /rest  where d:\path is the drive and path of the files that were backed up, and x: is the drive of the backup media.

OS/2

OS/2 is much easier to restore as the emergency startup disks already know how to handle long file names of the HPFS file system. However, here are a few minor things to consider:

Step 1, OS/2 Utility Boot Disks

The standard utility disk set does not include some utilities that could be very useful during disaster recovery.

• You might consider putting FORMAT.COM and UHPFS.DLL onto Disk 2 should you need to reformat the drive as HPFS before restoring.
• Consider moving TEDIT.* from Disk 3 to Disk 2 to make more room available on Disk 3.
• Add EAUTIL.EXE and ATTRIB.EXE as Utility Disk 3. Not only are they handy, EAUTIL is used by BackEmUp  to manage the Extended Attributes.
• Disk 3 should also include BackEmUp.exe, BackInfo.exe as well as your decompression and decryption programs as necessary.
• Some system DLLS are needed for the above: NLS.DLL and VIOCALLS.DLL (perhaps KBDCALLS.DLL). They should already be on Disk 3, but if not, you'll need to put them there.
• If restoring Warp Server, remember it depends on LVM to have created the logical volumes. This error may show itself on the first boot when OS/2 Warp Server complains that it can't operate your disk or diskette drive. LVM is on Disk 3.

If you are using a ZIP drive, you'll need to include those drivers during floppy boot up sequence. As OS/2 boot from floppies includes CD Rom support, a good alternative, is to create an inactive volume on a CD R/W that not only contains the backup files, but also various utilities and backup programs mentioned.

Step 2

Boot from the Utility disks. As necessary: create partitions, Boot Manager, logical volumes, format the drive, etc.

Step 3

Copy the files from Utility Disk 3 to a temporary directory on the hard file and change to that temporary directory. This improves performance greatly as BackEmUp  may invoke these programs several times during the course of the restore.

Make sure the TMP  environment variable is set to a R/W subdirectory that has reasonable free space.

Restore the files.
i.e. BackEmUp    C:*    x:    /rest

where x: specifies the drive (and optional path) to the control file.

Note the "*" is important as a selection mask is needed for restoration. Naturally, if you want only a paritial restore, enter in an appropriate file mask. See the partial restore topic for more information.

Step 4, Final step

Remove any floppies and reboot from the hard disk.

Partial Restore

Restoring a pattern

Let's say you made some change to a bunch of files. You can restore only those files, but if they don't fit one mask definition (for example: xyz*.txt) you will have to do multiple restore commands. If however they all fit a pattern, you can restore them all at once. For example, lets say you made some programming change to a bunch of cpp files but decided that was a bad choice and you want to back those changes out. Perhaps an example will help:

Assuming the following directory structure:
d:\other
d:\project
d:\project\support

You have backed up the D: drive (i.e. backemup d:\ a: )

You have many cpp files, some in project, some in support, and some in other, but the ones you are interested in are in project only.

issue backemup d:\project\*.cpp a: /rest  

This is an explanation of what that does: Although you backed up the entire d:\ drive, you only want to consider the *.cpp files in the project  and lower subdirectories.

Suppose you issued instead backemup d:\*.cpp a: /S1 /rest  
The /S1  option is what restricts the restore operation to only the *.cpp files in the 1st level subdirectories. You will not restore anything to the support subdirectory however you will restore files to the other subdirectory as well as project.

The /replaceprompt option can give you additional flexibility. Be sure to refresh your memory on all the /replace.... options to see what will serve your purpose the best.

The options may cause you to have to think about it just a little, but you can always use the /redir path  option to redirect the files to another temporary location to test out what you are really asking for. If you do specify a redirection path, it must already exist. i.e you asked for /redir C:\TEST  then you should create "C:\TEST" before you start to run BackEmUp . It will create all the subdirectories under C:\TEST relative to that new logical root.

Active vs  Inactive volumes

What are they and Why use them

An inactive volume maintains backup files that are tracked by BackEmUp  but are never automatically dropped as they age. (Note, refer to the /purge  option to alter this behavior.) Thus, a CD-R is a perfect media as once they are written, they are remembered forever. However, writing a CD-R often requires special software or hardware that may not be physically on the machine you wish to backup.

Inactive volumes can also be used to consolidate multiple R/W media (such as multiple ZIP or Floppy disks) onto one larger media such as a CD-R. This can be useful if the majority of your files rarely change, but changes do happen over many directories of the disk you are backing up. For example, the boot drive of an operating system. Once installed, many of the operating system and application program files will rarely, if ever, change; but there may be INI or configuration files that change frequently. Using the inactive volume concept, one can burn a CD containing the baseline of the system and remove those backup files from the normal backup media. This can also be used where you are backing up to another drive, such as a lan alias, and wish to reclaim the space used by these seldom changing files.

In cases where you have no efficient removeable R/W media, you can initially back the system up to another spot on the hardfile, burn a CD-R with those files, then move backemup.ctl  file to another media such as a floppy, and continue making incremental backups to floppy disk.

The mechanics of inactive volumes

The backemup.ctl  file maintains a list of volumes and the amount of free space. Each volume is logically identified by the contents of the backemup.id  file that exists on each volume. That identifier is the first field of the single line that exists in the backemup.id  file for that volume. So it would follow that as long as we keep each logical volume in its own subdirectory on a combined larger media, we can maintain the backup management philosophy as tradition "disk labels" are not used for identification.

In the backemup.ctl  file, an inactive  volume will have a -1  for the amount of free space available. Thus, this volume will never be asked for during a normal backup proceedure as it has no free space. The -1 also tells BackEmUp  that there will never be obsolete files  on this volume. During restore, this -1  free space signals BackEmUp  to ask for an alternate path to mount this media. Thus if you had backed up to floppies as A: but have created a consolidated inactive backup media on CD-R, you can tell BackEmUp  to look at your CD Rom drive to read the files. Obviously, if you were backing up to floppies, you would not want to create a CD-R for each and every floppy! As the logical volume is identified by the contents of the backemup.id  file, you would consolidate many floppies into individual directories on the CD-R and point to the appropriate subdirectory when asked.

Proceedure to set up to use inactive volumes

• Create an active backup. If you are backing up to a non-removeable media such as a lan drive, make sure you interrupt the initial backups such that the logical contents of the volume will fit onto one inactive backup media device. i.e., if your initial backup could be a gig in size, but you want to use a CD-R device of around 600 meg, interrupt the initial backup before it completely finishes so you can work with volumes approaching the size of your CD-R drive. (i.e. You might have to repeat these steps in increments depending on the size of you initial backup.)
• Copy the files onto the inactive volume media. It is important that you maintain the subdirectory file structure. For example, if you are consolidating multiple ZIP or Floppy disks onto 1 CD-R, you would probably want to create a subdirectory structure where volume 1 goes into subdirectory VOL1, volume 2 goes into subdirectory VOL2, etc. Inside VOL1, the backemup.id  file and the FILES/  subdirectory will exist. Similarily for VOL2, etc. Hint:  you might also want to copy the backemup.ctl  file as well as the BackEmUp  and BackInfo  and supporting compress or cipher programs for completeness.
• Edit the backemup.ctl  file on the original backup media (the active volume) and set the free space of each of the volumes you have copied to the inactive media to -1 . These lines will be identified by the "V" identifier record type.
• Edit the backemup.id  file on the backup media containing the backemup.ctl  file and change the imbedded volume number to the next unassigned volume.
• Verify the creation of the CD-R and your editing from above. For example, you could to a redirected restore of a file to two to make sure you got it right.
• Erase all the files in the FILES/  subdirectory. If you forget to erase them, they will be detected as orphaned files.
• For volumes other than the volume containing the backemup.ctl  file, you may simply erase everything: i.e. the backemup.id  file and the files in the FILES/ subdirectory. Make sure these secondary volumes do not accidently get remounted with the old backemup.id  file as that will cause utter confusion as to where this volume's files really exist!

If at this point you are switching from backing up to a non removeable media to a ZIP or floppy drive, copy the backemup.id  file and backemup.ctl  file to the new backup media. Besure to edit the "! REMOVEABLE_MEDIA" line in the control file (or remember to use the appropriate /rm- option next time).

The BackSig  program

BackSig  is a simple utility to verify the integrity of a list of files. It computes various check values (signatures) that can be manually recorded and compared. For example, if you just moved the "FILES" subdirectory onto a CD-R and want to verify the contents were written successfully, one could create a list of the files you moved (for example, use the standard DIR command with the appropriate /f or /b   option and redirect the output to a file) and manually verify the check values between the 2 physical media. If the computed check values are different between the two media, then the copy was NOT created successfully.

Hint: The /a:-d /o:n /s options of the standard operating system DIR command are also handy when generating file lists.

The program takes one parameter that is the name of the file containing the list of files. For example, create a file FILELIST.TXT and in it, list
C0000001.001
C0000002.001

Run BackSig FILELIST.TXT  and you could see output resembling:

Selecting files from list: filelist.txt

Files: 2 Total Bytes: 974

Begin file contents examination phase...

Check 1, 22 7432 5914
Check 2, 26 7177 2008
Check 3, 5 6203 6552
Aux key: 9Q6V XJ4

Hint: Use standard file output redirection to save BackSig  output to a file, and then use any one of a number of standard file comparison programs.