Recovering data from Central Point Backup?
Michael Thompson
I recently had hard drive crash. Having done a backup with Central
Point Backup from DOS 6.3, I figured I was okay. However, the last
disk in the series was aparently corrupted, and when I tried to use
the Rebuild option, it only read the first 2 disks and then said it
was done. Trying to start the recover from the next disks did not
help, it gave me an error about the file stream being null. Does
anyone know of a solution to this problem? Failing that, does anybody
know the compression scheme that CPbackup uses, and a program to
decompress the files? Thanks in advance, this backup represents a good
few years of data.
Frank Slootweg
[comp.binaries.ibm.pc.wanted is not really appropriate, but since it is
about the only correct group name, I will leave it in.
Deleted incorrect groups comp.ibm.pc and comp.sys.ibm.pc.software.
Added comp.os.msdos.apps.]
You did not give many details - i.e. which version of CPBackup you
used, which commands, options, etc. you used, what the exact messages
were, etc. - but perhaps the attached (very old and very long) article
is of some use to you.
Good luck with your recovery attempts.
----------------------------------- cut here ----------------------------------
From: fra...@hpuamsa.neth.hp.com (Frank Slootweg CRC)
Date: Tue, 7 Jul 1992 06:45:03 GMT
Date-Received: Tue, 7 Jul 1992 06:45:03 GMT
Subject: PC Tools 6.0 PCBACKUP Restore tips.
Message-ID: <2721...@hpuamsa.neth.hp.com>
Organization: HP-Sales Office-The Netherlands
Path: hpuamsa!franks
Newsgroups: comp.os.msdos.apps
PC Tools 6.0 PCBACKUP Restore problems and solutions/workarounds.
=================================================================
Note: I originally wrote this article as an e-mail message to someone.
In order not to have to rewrite it, I just deleted the recipients'
name and other personal or irrelevant information.
Hello [deleted],
I did some restore experiments with PCBACKUP from PC Tools 6.0.
Bottom line: I have not been able to completely reproduce your
scenario ("Try restoring with diskette 1 and it claims foul. Try
restoring with diskette 2 (with the "log") and it complains that it
can't find diskette 1."). I have, I think, been able to reproduce the
first part of this scenario. Details follow later.
HOWEVER I have, intermittently, had files which were TOTALLY CORRUPTED
(wrong size and totally wrong contents) after a restore which gave NO
ERRORS whatsoever. This scenario is at least as bad, or even worse, as
yours.
I say "intermittently" because sometimes the restore is OK and
sometimes it is not. I have not been able to accurately pinpoint under
which circumstances the restore fails, but I have been able to find a
scenario which "never" fails (worked OK at least 10 times).
Since I wanted to go as far "to the bottom of it" as I could, I
documented my experiments in rather much detail. If there is sufficient
interest in some comp.os.msdos.* or comp.ibm.pc.* group, then I will
post this information or a summary of it.
If you do not want to read it all, then you might still be interested
in my main conclusions :
- Your "Try restoring with diskette 1 and it claims foul." scenario was
perhaps caused by a combination of operator error and the illogical
and (probably) inconsequent user interface of PCBACKUP.
- Under as yet unclear circumstances the content of files restored by
PCBACKUP can be corrupt without any error or warning.
The corruption occured several times when the Super PC-Kwik disk cache
was enabled. It did not occur when the cache was disabled.
However later tests with cache enabled gave no corruptions, so it is
unclear if the disk cache, PCBACKUP or something else was causing the
corruption.
Another ([deleted]) user also had corrupt restored files. He will try if
he can reproduce his failure scenario. If so, he will inform me and I
will inform you.
[deleted]
Before I describe the details of my tests : I think I was able to
reproduce the first part of your scenario ("Try restoring with diskette
1 and it claims foul.").
Details of attempts to reproduce the first part of your problem
===============================================================
1. If, when PCBACKUP wants to read the directory information ("log"),
you insert the wrong disk, i.e. any disk other than the last one,
then PCBACKUP gives a dialog box '!ERROR! Backup Directory Not Found.
Choose "Retry" if wrong disk inserted. Choose "Rebuild" to regenerate
directory from backup set.'.
At this moment one should insert the last disk and, with the "Retry"
button highlighted, press the "Return" key (which "presses" the
highlighted button).
Note: In medium or high speed mode, but not in low speed mode, this
is different than for the "Insert last disk in drive B:" dialog box
described in point 4 below :
- For the "Insert ..." dialog box PCBACKUP will automatically
continue when a disk is inserted (provided the diskette drive has
volume-change detection hardware, which all somewhat modern drives
do have). Once the disk is inserted the "Tab" key (to switch
between the buttons) and the "Return" key (to "press" the
highlighted button) have no effect.
- For the "!ERROR! ..." dialog box one *must* press the "Return" key
in order to "press" the highlighted "Retry" button. If one does not
press "Return" then the following very strange scenario can occur :
- After, in my case, 1.45 minutes the access light of the diskette
drive goes off.
- Smart user remembers that (s)he should press "Return".
- After "Return" is pressed the "Insert last disk in drive B:"
dialog box appears, but, while the correct diskette is in the
drive the light remains off.
- Smart user again presses "Return" for the highlighted "OK"
button, but the access light remains off.
- Smart user is patient and waits. After, in my case, ~24 seconds
the access light goes on and after another ~27 seconds the
"Reading Directory Information Please wait." information box is
shortly shown and all is well again.
So to summarize this point(all for medium or high speed mode): For
the "Insert ..." dialog box one *can not* (as in: has no effect)
press the "Return" key to press the highlighted "OK" button. For the
"!ERROR! ..." dialog box one *must* press the "Return" key to press
the highlighted "Retry" button.
See also recommendation 7 below for another scenario which may make
you think that your backup set is bad while it actually is perfectly
OK.
Details of my own problems
==========================
2. I do not think that my problems had anything to do with the "log"
files. When requested PCBACKUP makes an ASCII DYYMMDDA.RPT file and a
binary DYYMMDDA.DIR file on the harddisk (D=drive, YY=year, MM=month,
DD=day_of_the_month). Only the .DIR file is used during the restore,
i.e. if it is available then the directory information is read from
it, else you have to select the "Insert" button of the "cHoose
directories" sub-menu "to read the directory from an inserted Disk".
3. Just to really emulate a restore to a clean/empty disk, I copied my
*.SET, *.RPT, *.DIR, PCBACKUP.HST and PCBACKUP.CFG files to a
diskette and then removed them from my harddisk.
4. One point which is very confusing and which probably creates problems
for a lot of users is the following (again for medium and high speed
mode) :
When selecting the "Insert" button from the "cHoose directories"
sub-menu to read the directory from the last disk of the backup set,
one shortly - a few seconds - gets a information box saying "Reading
Directory Information Please wait." and then a dialog box "Insert
last disk in drive B:" with "OK" and "Cancel" buttons. The drive
access light goes on and the drive is ready to accept the diskette.
So far, so good.
Now you insert the last diskette. For my 3.5 inch B drive you just
hear some clicking, i.e. the latch of the diskette is opened, and
then nothing *seems* to happen for about 1.5 minutes (I had a set of
9 diskettes). Even the "Insert last disk in drive B:" dialog box is
still there and its "OK" button is still highlighted. *IF* you are
smart enough not to touch anything and just patiently wait, then
*AFTER* the 1.5 minute period you shortly - a few seconds - get an
information box saying "Reading Directory Information Please wait."
(and, even shorter, another information box saying "Reprocessing
selection list. Please wait.").
After that, as expected, the directory structure from the backup set
is shown (two boxes, directories on the left, files on the right).
This way of operation is very confusing. Because nothing seems to
happen, users are probably going to press keys, remove and re-insert
diskettes, etc. Of course the "Insert ..." dialog box should
disappear as soon as the diskette is inserted and the "Reading ..."
information box should be shown during the 1.5 minute wait.
Note: If the last diskette is put in the drive *before* PCBACKUP says
"Insert last disk in drive B:", then PCBACKUP directly reads the
directory information, i.e. no 1.5 minute wait.
5. I think my problem (PCBACKUP gives no error messages, but restored
file is totally corrupt) is caused by PCBACKUP reading the file
content from the wrong diskette.
I restored only one directory with two files. One of the files was
also on the harddisk and I did not let PCBACKUP overwrite this file.
The directory ("log") was on the 9th diskette and the files to be
restored were on the 1st diskette.
I did the following tests, most of them multiple times :
- Insert last diskette when PCBACKUP instructs you to do so, select
directory to restore, *leave* last diskette in drive, select "Start
restore" and insert diskette 1 when PCBACKUP instructs you to do
so.
Result: Restored file sometimes OK, sometimes corrupt.
- Insert last diskette when PCBACKUP instructs you to do so, select
directory to restore, *remove* last diskette from drive, select
"Start restore" and insert diskette 1 when PCBACKUP instructs you
to do so.
Result: Restored file *always* OK.
- Disabled cache. I use DR DOS 6.0 and its bundled Super PC-Kwik
cache. Super PC-Kwik can also cach diskette reads and I have
enabled this feature. For people "in the know" : I also use the /V+
switch ("Use volume change hardware.) and the volume change
hardware tests as described in the DR DOS 6.0 manual work correctly
on my system. Rest as first scenario :
Insert last diskette when PCBACKUP instructs you to do so, select
directory to restore, *leave* last diskette in drive, select "Start
restore" and insert diskette 1 when PCBACKUP instructs you to do
so.
Result: Restored file *always* (10 times in a row) OK.
- Happened only once:
Disabled cache.
Insert last diskette when PCBACKUP instructs you to do so, select
directory to restore, *leave* last diskette in drive, select "Start
restore". PCBACKUP did *not* ask to insert diskette 1, read from
the last diskette, said "Restore Completed!", but the restored file
was (of course) totally corrupt.
So I think that, unless the right diskette is in the drive when
PCBACKUP starts reading the file contents, PCBACKUP sometimes reads
the wrong file contents. How it can read the wrong contents when it
does ask for the right diskette, the right diskette is inserted and
PCBACKUP seems (since the drive access light is on before the
diskette is inserted, and my 3.5 inch drive is very quiet, it is hard
to tell if the drive is actually reading) to read the right diskette,
is beyond me. Perhaps it is caused by the cache and is the "Happened
only once:" problem caused by the drive thinking that a new diskette
was inserted (i.e. failing volume-change detection hardware in the
drive).
Another observation: If the restore from the requested diskette is
fast - a few seconds for this one 1565 byte file - then the restored
file is OK. If the restore is slow, some 15 seconds, then the
restored file is corrupted.
The bad news :
After the above experiments I retried the first scenario (which
earlier sometimes gave a corrupted file). However this time I never
got a corrupted file, even not after over 20 tries! So I could not
reproduce the problem scenario again and therefore can not determine
what caused or may have caused the corruption.
Based on the above and other experience, I have the following
recommendations :
1. Do not use a disk-cache when restoring a PCBACKUP backup. It is
probably also wise to not use a disk-cache when making the backup,
but if you specify "Verify Always" (only checks if the backup can be
*read*, does *not* do a *compare*, see manual) before the backup and
do a compare ("start Compare") after the backup, then, if the compare
is successful, your backup should be OK.
2. For medium or high speed mode :
If you know that you have inserted the *right* diskette after
PCBACKUP instructed you to do so, and nothing *seems* to happen, i.e.
the previous dialog box is still shown and the selected button is
still highlighted, then please be patient, do not press any keys, do
not use your mouse (if available and installed), do not remove the
diskette and wait at least a few minutes to see if PCBACKUP actually
*did* do something and continues (i.e. screen content changes).
During the wait time the disk access light should be on. If it is off
then press the "Return" key while the desired button is highlighted.
If the desired button is not highlighted, then try if you can
highlight it by pressing the "Tab" key. After each action wait at
least again a few minutes before giving up. See also 6.
3. Remove the last diskette directly after the directory information has
been read ("Reading Directory Information Please wait"). Do *not*
wait untill PCBACKUP instructs you to insert another disk.
4. Remove a diskette directly after PCBACKUP stops reading it. Do *not*
wait untill PCBACKUP instructs you to insert another disk. I.e.
similar recommendation as for the last diskette, but now for any
diskette (including the last).
5. Do not insert a diskette untill PCBACKUP instructs you to do so.
Exception: Insert the last diskette before PCBACKUP instructs you to
do so, i.e. for "Insert" button of "cHoose directories" sub-menu or
for "Start restore" sub-menu when doing a full restore (i.e. "cHoose
directories" was not used earlier).
6. When PCBACKUP instructs you to insert a disk then do not insert
another disk than the one which PCBACKUP requests.
If you have not yet labelled your disks with the right numbers, or
have incorrectly labelled them, then do a DIR for each of the disks.
The DIR output will show PCBACKUP.001 for disk 1, PCBACKUP.002 for
disk 2 and so on.
The PCBDIR program will give similar, and more, information.
If you, by accident, insert a wrong disk then remember the
following :
- For the "Insert ..." dialog box PCBACKUP will automatically
continue when a disk is inserted (provided that PCBACKUP is
configured for medium or high speed mode and the diskette drive has
volume-change detection hardware, which all somewhat modern drives
do have).
- For the "!ERROR! ..." dialog box you *must* press the "Return" key
in order to "press" the highlighted button (in most cases the
"Retry" button).
- If you get "hung" for more than a few minutes while the "Insert
..." or "!ERROR! ..." dialog box is displayed, then it is probably
best to start over (i.e. try to stop PCBACKUP and if that fails
reboot with Ctrl-Alt-Delete). Do *not* conclude that your backup is
bad if you get "hung" while the "!ERROR! ..." dialog box is
displayed. Most likely your backup and the PCBACKUP program are OK
and just your multiple errors caused a (real or apparent) hang
condition.
7. A backup set made in low speed mode must be restored in low speed
mode. A backup set made in medium or high speed mode can be restored
in medium or high speed mode. If you have configured the wrong speed,
then PCBACKUP will give the "!ERROR! ..." dialog box, even if your
backup set is OK and you have inserted the correct (last) diskette.
The /X option of PCBDIR will tell with which speed a particular
backup set was made. It will say "high" for both a medium and high
speed backup set.
The purpose of recommendations 3, 4 and 5 is to make sure that the
right diskette is inserted at the moment when PCBACKUP needs it and a
diskette is removed as soon as PCBACKUP is finished with it. This
hopefully prevents PCBACKUP from (trying to) read(ing) the wrong
diskette.
I hope (at least some of) this is of use to you.
Best regards,
Frank Slootweg, UNIX support person and PC owner.
----------------------------------- THE END ----------------------------------