Best backup software for NetWare?

I second the motion on Backup Express.  If you don't have a really large setup, I believe they have a smaller, less-expensive deal for more of a midsize company.

If you can't justify the cost for some reason, the direct competitor to BE in that niche level that still provides platform support for NetWare and eDirectory, leveraging SMS/TSA's, and also with full support for Linux, is CA BrightStor ARCserve.  That's what I use at the moment.  Its backup disk-to-disk-to-tape isn't too bad, either.

I back up NetWare/eDirectory, SLES9 (32-bit) and Windows 2003/AD.  The latest version also supports 64-bit SLES.

You're correct. It was a few years ago we figured that one out. Put it in the job Netware scheduler and forgot about it. CachingMode would speed up your full backup because you're enabling read-ahead, hence when the backup software needs stuff it's already been read into memory. With an incremental that's precisely what you DON'T want, hence the NoCachingMode.

Can't comment as regards using Windows as a media server I'm afraid, we use an enterprise-class OS for that :)

I am using Computer Associates BrightStor ARCserve for NetWare v11.1 SP3 and for Linux v11.5 - my experience is mainly with the NetWare side of things.

It does a fast disk to disk (assuming the disk is on the same server as the ARCserve engine - if not, then you should have an ARCserve Client Agent running on your target server to increase speeds).

I like it better than Backup EXEC (which I have also used for NetWare).  Especially the user interface and the NetWare NSS support options.

However, the Backup EXEC product has a better database scheme than ARCserve - which keeps everything in a single BTrieve database instead of breaking it out by job like Backup EXEC. Which means if ARCserve gets a corrupt database, it takes all the previous backup job info with it - unlike Backup EXEC.

Just my 2 cents.

One more thought regarding your speed question.  Many NetWare servers default their volumes to enable compression on files that have not been accessed in some time.  A TSA-based backup direct to tape will read the data in this native compressed format and push the data directly to the tape, whereas when you copy files to a Windows server, the Windows server would never understand the NetWare compression format, so the files must be decompressed on the NetWare box FIRST, then moved across the wire in their larger (original) format.  The extra workload will drag down server performance during the copy job.

You can confirm this by enabling SET COMPRESS SCREEN = ON and watching during your backup window..

Ahh -- now we have more info.  I was assuming, from your original post, that the tape drive was on the NetWare box, not on the Windows box.  That is why I wasn't worried about the speed difference.  However, if you're extracting data from the NetWare server to the tape on the Windows box, then this indeed is a different issue.

The next question this begs is this:  Are you using a backup agent on the NetWare server?  Most backup agents provide server-side compression BEFORE the data goes across the network.  Assuming an average of a 2:1 compression ratio (with many files being higher than this, of course), you would certainly see better throughput in this environment.  

I am guessing (though this is only a guess) that the backup agent compresses when it knows that it is backing up to tape, since the compressed data can be directly written to the tape in its compressed format.  (This is all a function of the backup software, of course.)  

I am further guessing that the backup agent decides, when it has to do a disk-to-disk copy, to skip the overhead of compression on the source and subsequent decompression on the target, since it would simply be wasted CPU overhead.  

Can you confirm this theory?  Certainly!  Run WireShark (www.wireshark.org) on the Windows box and capture the network trace of a 1MB file being backed up to tape.  Then, run it again and capture the network trace of the same file backed up to disk. Check out the data stream in both cases, and I bet you'll find that they are vastly different.

Of course, CPU's nowadays are so fast, perhaps it WOULD be helpful to still compress the data before sending it, and decompress it when receiving it.  My knowledge of BackupExec is somewhat limited (I'm been an ARCserve bigot using this software since ARCserve 4.0 for NetWare back in the early 90's), so I'm not sure if there are configuration options to enable compression for disk-to-disk copies, but I suspect that there are -- either real switches in the software or perhaps a hidden registry or config setting somewhere.

I'd have to bow to the BackupExec experts out here to take it much further...