Video Screencast Help

Restore BE 6 tapes

Created: 27 May 2009 • Updated: 25 May 2010 | 6 comments


I have some 12 year old tapes that were created as it seems with Backup Exec for Windows NT Version 6.0 Rev. 108, from around 1997 (which I found out only by installing Cygwin and using dd).

Unfortunately I don't have this software anymore, but still have that old PC with Windows NT 4 Server running (since 1998/99, before NT 3.1/5)
Is there any chance, that I could get from somewhere a copy of BE 6 to restore those tapes?
Or is there some compatible Backup/Restore software out there, which could restore such tapes?
The format is almost the same as tapes created with NTBackup of NT3.1/3.5/4, only that software compression was used, which NTBackup doesn't understand.

Harald Henkel

Comments 6 CommentsJump to latest comment

Ken Putnam's picture

You should be able to restore those tapes with any subsequent version of BackupExec, assuming of course that you still have a compatible tape drive |8^)

If not and you need data on those tapes, you could download v7.3 and install in demo (60 day trial) mode

If this response answers your concern, please mark it as a "solution"

gadeiros's picture

Thanks for that link.

I downloaded and installed the BE7.3 on my NT4 PC.

It could restore one of three tapes.
For the other two tapes I receive a timeout error (message id 9) in the NT Eventlog while catalogueing.

That same thing happend with tapes written by NT backup.
But NTBackup will let me restore (the first backup set on) the tapes anyway, without catalogueing.
Backup Exec won't let me do this!

I have a Tandberg 3660 QIC connected internally and a HP DAT connected externally to an Adaptec 1542C ISA-SCSI controler.
In this configuration I was able to restore 11 QIC and 5 DAT tapes written by NTBackup (using NTBackup) and one QIC tape with Backup Exec.

So there is probably no hardware problem...

What else could be causing this error?

Symboy's picture

You can verify if there was any Software compression used on the tape while backing up . As BE might not be able to decompress the data , which is compressed using a different Backup S/W 

As in this case

Note: If this post provides you with a solution don't forget to mark the discussion as solved.

Ken Putnam's picture

If one of the BackupExec tapes will catalog/Restore, then all I can think of is that the tapes themselves have gone bad |8^( 

(after all, they are more than 10 years old, right?)

If this response answers your concern, please mark it as a "solution"

gadeiros's picture

I found an option which turns off the reading of an on-tape catalogue and instead read all the tape scanning all the files for catalogueing and with that the first of the two missing tapes could be catalogued (this takes as long as restoring, but who cares) and restored. It even found two backup sets.
The second tape I will try this evening and then I will check if some of my NTBackup tapes contain more than one backup set, which NT Backup found.

gadeiros's picture

Hello again.

I restored 2 tapes of the three backuped with BackupExec6.

The last (third) tape will catalogue up to about 80 MB and then stop with an CRC.
After that, if I want to restore the tape, it tells me, there are no catalog data for it.
If it can read those 80 MB, why can't it restore them as well, up until the CRC?

Is there any chance to get past the CRC?
I put in my cleaning tape, but of course this too is over ten years old (including the liquid).

Three of the 11 tapes written By NTBackup cannot be catalogued, although NTBackup restored them fine - at least the first backup set.
The strange thing is, that when trying to restore one of these later, I get the tree of my (other) catalugued tapes displayed.
And if I check one of the backupsets found on those, then automat(g)ically some other set(s) are checked as well (even from other tapes).

While restoring single record sets from starting from one of the tapes where catalogueing succeeded, works fine.

Any opinion?
I know. This software is long abandoned...

Thanks for any hint.

With kind regards,
Harald Henkel