Hi Charles,

That sounds like it may be an ideal solution. As I have no experience of
extracting data written in GNU tar format, do you have details on the
best way to achieve this or can you point me in the right direction?

The data on the tape isn't multiplexed and is one large 126 GB data file
taken from a Windows 2003 server.

Thanks in advance,

Steve.

-----Original Message-----
From: Charles Ballowe [mailto:cballowe AT gmail DOT com] 
Sent: 22 September 2005 15:17
To: Steven Jenner
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Restore of Netbackup image to Backup Exec
server???

If it's not a multiplexed backup and if you don't need to restore to a
server other than the one with the tape drive attached, you can do the
restore with gnu tar (send the binary out of a netbackup install --
since they're based on the GNU tar, it should be covered by the GPL.
There might be some tricks if it's not one large backup piece, but
otherwise, it works -- i've done it. Yay for using industry standards
for data on tape :)

-Charlie

On 9/22/05, Steven Jenner <Steven.Jenner AT psinet.telstra.co DOT uk> wrote:
>
>
>
> Hi All,
>
>
>
> I believe I already know the answer to this but thought I would ask
the
> knowledgeable people here to confirm.
>
>
>
> I have produced a backup image of a 120 GB file on a LTO 2 tape using
> Netbackup Enterprise 5.1, the intention was that this tape would be
sent to
> an offsite location and the file would be restored to a remote system.
It
> transpires that the system at the other end is not a Netbackup
Enterprise
> environment but rather a Veritas Backup Exec 9.0 and surprise surprise
the
> other engineer cannot restore the file.
>
>
>
> My understanding is that you can restore a Backup Exec image to
Netbackup
> Enterprise but not the other way round, is that correct?
>
>
>
> If anyone out there has any suggestions as to how to complete this
restore
> (short of installing Netbackup at the remote site) please forward them
on
> also.
>
>
>
> Thanks in advance,
>
>
>
> Steve.