
-----------------------------------------------------------------
NOV-BAK4.DOC -- 19980310 -- Email thread on NetWare Backup issues
-----------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Sun, 23 Feb 1997 20:38:08 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: Doug Becker <debecker@concentric.net>, netw4-l@ecnet.net
Subject: Re: Auto Logout

>Our situation is this.  We have users who are not logging out every
>night and it is affecting our backups.  How do we ensure that they
>are automatically logged out at a certain time if they don't
>manually do it?  I have tried the Login Time Restriction in NWAdmin
>but this does not appear to log them out, only restrict the times
>they can log in.

This is a common abd recurring problem.  There are a number of
answers.

The simplest, and least effective, is threats of death.  Perhaps if
you carry through, or talk about how unreasonable your previous
employer was when they found the dead bodies it would help.

Overall though, a social solution will not work, a technical solution
is needed.

There are two approaches here.  One is to kick off the users, the
other is to set things up so you can back up the open files.

The first method has a number of ways to accomplish it.  Simply
setting the allowable times for most user to exclude the backup
window would help.  That would let NetWare kick off the users at
the backup time, and let them back on at the time you want them back
on.  However, this can be a problem as they could lose what they are
working on at the time.

Similarly, Arcserve is said to let you kick off users.  But the same
problems occur.

Some people like Citadel's NetOFF, but my experiences with it were
less than satisfactory.  In theory, it should shut down the users
applications.

Infinte Technologies is supposed to have a similar, but working,
product in their GuardIt product.  However, I haven't tried it.
Check with http://www.ihub.com for more information.

The other answer, allowing the backup package to back up everything,
even open files, is another matter.

One way is to use St. Bernard's Open File Manager.  I've heard very
good things about it.  It's supposed to even be able to allow you to
backup and restore Oracle files.  Best of all, it works with just
about anybody's backup software.

Another way is to use Stac's Replica or Columbia's SnapBack.  They
are very similar products, and both have their own ways of dealing
with open files.  I've heard, and said, good and bad things about
both of them.  I should get a fresh copy of SnapBack to look at again
real soon now.

Another way is to use Vinca's Standby Server.  There is a module that
comes with it called SnapShot Server that lets you mount the mirrored
volumes in a frozen state and then back them up with your favorite
backup software.  I didn't have a chance to play with it, but it does
isolate the backup from the productional server quite effectively.

And finally, there used to be a product called Vortex something.  It
kept a live snapshot of your system on a sector by sector basis.  All
changes went from your server to the Vortex server.  You could create
and mount an image of your server as of any date and time stamp.  It
could tell you that X files are open at that time, but that Y minutes
earlier or later all files were closed.  It would let you back up the
mounted image.  Interestingly enough, it offers a way to roll back
from a server virus infection.  Just set the image to before the
attack and copy files back to your main server.

---------

Date: Sun, 23 Feb 1997 22:16:26 -0600
From: "Kevin McIntosh" <powertek@hia.net>
To: <netw4-l@ecnet.net>
Subject: Re: Auto Logout

The Vinca SnapShot server product mounts the mirrored volumes, on the
standby server, as SYS_SSO, etc...  It then takes a SnapShot of the open
files.  When you backup the SnapShot (standby server) volume, you get the
snapshot files on tape.  Vinca and Novell recommend you run the backup
software (i.e. ARCserve) on the Vinca Campus Standby/SnapShot server's SYS
volume.

Both of the backup solutions from Cheyenne and Seagate offer an add-on or
agent to backup open files.  What surprises me is that no one has hit on
the serious issue of security.  Management should be made aware of the open
invitation their users are sending by not logging out.

I once had a user delete an important database file 4 times in 3 weeks.
I had to talk the manager out of firing her.  We instructed her to never
leave her PC unattended, while logged in.  The problem stopped.  We never
did find out who was really deleting the database file.  It could have had
something to do with the owner divorcing his wife and marrying the user, 3
weeks after his divorce was final.

------------------------------

Date: Thu, 27 Feb 1997 02:42:18 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Deleting Partitions From Netware 4.1 NDS

>>	I presume you do have thorough backups of "everything" (NDS
>>included) before touching the system. If it makes you feel better I
>>am running emergency backups at this moment to rescue a INW 4.11
>>machine which is losing its hard disk (bearings are going fast
>>today); Arcada BackupExec, backs up "everything".
>>	Joe D.
>
>Just wanted to say I'm really glad to have noted Joe's previous
>recommendation of that fine program.  They have a *fabulous* support
>dept, excellent documentation, and the product is much easier to
>work with all around than the evil Arcserve. (although I admit I
>haven't tried 6.0)  But I look at Cheyenne as an evil company at this
>point, even more so since they were purchased by the even more
>despised (by me at least) Comp. Assoc.
>
>So far I have been pleasantly surprised by the job Seagate has done
>with their Conner/Arcada/Palindrome acquisitions. (with the
>exception of the elimination of toll-free support from Conner.. but
>that seems to be the way of the world nowadays, sigh)
>
>Phil Koenig
--------
	And, now at 02:35 the next day (Thursday), the server I mentioned
is back on the air and apparently happy. NDS works, print queues work,
no lost users nor passwords nor files, trustee rights are correct, all that
jazz. The server gets five more hours to collect its mind then back to the
grinding stone. Ditto for tender of same.
	Joe D.

------------------------------

Date: Thu, 27 Feb 1997 08:55:19 -0500
From: Robert MacDonald <RMACDONALD@perrigo.com>
To: netw4-l@ecnet.net, powertek@hia.net
Subject: Re: Stac REPLICA

Replica can be used directly attached to a server or over the wire. Replica
just wants to know where the tape drive is.

Replica is an 'object' based system. By this, I mean it will back up
Partition data(Netware and non-Netware), NDS and Netware partitions (yes
it backs up open files). This product does NOT fall into the same class
as an Arcserve or Seagate style of traditional backup & restore(file by
file), rather it is for use as a way to recover from lost/trashed or
crashed disks. Basically the server will come back to life exactly the
way it looked when it was backed up(including the private key.)

When you perform a full recovery, the product will bring back from tape,
the partition table, all non-Netware partitions(no matter what they are
(DOS, NT, Compaq system partitions, UNIX's, etc.)) It does this from the
disaster recovery diskettes that it makes, prior to backing up your system.
These diskettes hold the server.exe, startup.ncf, autoexec.ncf (the
autoexec.ncf is chainable...if there are 3 DR diskettes, disk 1 will hold
autoexec.ncf, disk 2 will hold autoexec.2 and so on), all disk drivers in
use on your system, all network NLM's and supporting modules. These
diskettes are bootable and will load Netware as the server in which you
created them from.

Please test this feature in a 'destroyable' environment first, before using
it on your production servers. I have had some difficulty with the product
in mirrored environments(must un-mirror first. They are working on a fix
for this) and also moving from one type of hardware to another (Compaq
Proliant 1500 to a Compaq Proliant 2500, RAID 5), by modifying the DR
diskettes. The partition table needs messaging after the restore.

BTW, I do not have any stock in Stac, I am not a reseller and right now
have put using Replica on hold until they fix a few bugs. In the interim,
we will be using Arcserve and pray our servers don't crash.

------------------------------

Date: Sun, 2 Mar 1997 23:52:38 +0000
From: John Wells <jwells@PACIFICCOAST.NET>
Subject: Re: Tape Backup units

>Does anyone have any recommendations for tape backup units for a Novell
>3.12 network.

It depends on the number of servers you have to backup, the quantity of
data, and the required speed. If you're looking at server-based backup of
a few GB at a time, read on.

I inherited a LAN with three NW servers (two are 3.12, one is 4.10). We
backup about 2GB each night, using a Conner CTMS 3200 SCSI drive (QIC 3080W
format, 2 GB native) in one of the servers, and running Seagate/Arcada
Backup Exec (BE). A key lesson we have learned about this type of
server-based backup (much of it from following the Netware list
NOVELL@LISTSERV.SYR.EDU), is that server-based backup software (Backup
Exec, ArcServe, etc.), in its quest for fast backup speed, is *very*
resource intensive. Your backup server should have
  a) lots of RAM (BE wants 65% free cache buffers)
  b) bus mastering NIC(s)
  c) a dedicated bus mastering SCSI adapter for the tape drive
Until we had the dedicated SCSI adapter the system was so unreliable as to
be unusable. Since then it has been operative, but fragile. I recently
increased the RAM in all servers, and will soon replace the 3C579 NICs with
3C590s.

With the fragility we are fortunate in being able to dedicate one of the
three servers to backup and other support tasks, so that when it abends or
when it must be restarted it doesn't affect our file and print services.
This doesn't solve all problems, however, as the backup client software
that runs on the other servers is also both resource intensive and fragile.
Blame NetWare's cooperative multitasking, but I would not run backup
software on a server providing important file/print services.

We get 20 to 23 MB/min backup speed from the 3.12 servers. When I upgraded
the third server from 3.12 to 4.10 the speed dropped to 3 MB/min, and it
took much interaction with Seagate/Arcada to get it back to 10 MB/min,
where it is today. The feedback from the Netware list is that 10 MB/min is
normal performance -- I haven't yet heard a good explanation as to why my
remote 3.12 server can backup twice as fast as a similar remote server
running 4.1.

I should make clear that, again from my following the Netware list, our
backup problems are not likely due to our particular software choice. Many
folks are very happy with BE, and others are unhappy with competing
products.  I think the key is to provide the software with the resources it
requires.

Finally, when it's my turn to spec out a system like this I'll go with a
DAT drive. The QIC-3080 works, but notwithstanding its claim of 4GB
compressed capacity it doesn't support compression under BE (apparently
because the drive doesn't do the compression in hardware). Also, I seem to
get a lot of minor errors with the tapes, and many die after only 20 or 30
uses (I've only been able to get Sony tapes in the 3080 W(ide) format).

------------------------------

Date: Mon, 3 Mar 1997 14:00:45 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: Re: Tape Backup

>>Does anyone have any recommendations for tape backup units for a Novell
>>3.12 network.  We have just received approval for funding to purchase
>>one this fiscal year.
>
>It depends on the number of servers you have to backup, the quantity of
>data, and the required speed. If you're looking at server-based backup of a
>few GB at a time, read on.
>
>I inherited a LAN with three NW servers (two are 3.12, one is 4.10). We
>backup about 2GB each night, using a Conner CTMS 3200 SCSI drive (QIC 3080W
>format, 2 GB native) in one of the servers, and running Seagate/Arcada
>Backup Exec (BE). A key lesson we have learned about this type of
>server-based backup (much of it from following the Netware list
>NOVELL@LISTSERV.SYR.EDU), is that server-based backup software (Backup
>Exec, ArcServe, etc.), in its quest for fast backup speed, is *very*
>resource intensive.
>
>John Wells

	The reason for the heavy resource usage is the software LZW
compression: Shut it off and your server should be a lot more robust. If
you insist on compression, upgrade the CPU to the fastest that will fit in
the socket on the logic board... Check the documentation that came with it.

>Your backup server should have
>  a) lots of RAM (BE wants 65% free cache buffers)
>  b) bus mastering NIC(s)
>  c) a dedicated bus mastering SCSI adapter for the tape drive
>Until we had the dedicated SCSI adapter the system was so unreliable as to
>be unusable. Since then it has been operative, but fragile. I recently
>increased the RAM in all servers, and will soon replace the 3C579 NICs with
>3C590s.
>
>	[snip]
>
>Finally, when it's my turn to spec out a system like this I'll go with a
>DAT drive. The QIC-3080 works, but notwithstanding its claim of 4GB
>compressed capacity it doesn't support compression under BE (apparently
>because the drive doesn't do the compression in hardware). Also, I seem to
>get a lot of minor errors with the tapes, and many die after only 20 or 30
>uses (I've only been able to get Sony tapes in the 3080 W(ide) format).

	Bad choice: All helical scan tape drives suffer from the same
maladies... In fact, DAT can be worse. And, small errors can cascade out of
control if compression is turned on.

	A much better choice is a DLT (Digital Linear Tape) drive [Formerly
built by DEC, now by Quantum]. Capacity varies by the tape and drive
chosen, but can go as high as 40 gigabytes hardware compressed... Per tape!
But, the main reason why DLT is a better choice is that the tape transport
does NOT stretch the tape and does not use a helical scan head. Instead,
the 1/2" tape is 128 tracks wide, with two tracks being recorded
simultaneously by the indexing head. In addition, DLT tape is good for
about 7,000 backups due to the improved transport.

	The folks at Compaq have written an excellent White Paper about the
various tape drives as used for backing up and archiving: You can read it
directly if you have the Acrobat plug-in, or download a copy from a link on
my Web site at:
	http://www.snip.net/users/dan/backup.html

	Since you only have 4 gigs, why not take a closer look at the
IOmega Jaz drive? With sustained transfer speeds of up to 3 MB/second a 4
gig drive would only take about 20 minutes to do a full backup (across 4
carts). Another alternative is a 4.6 gig magneto-optical drive... Although
they are MUCH slower, they would work fine for overnight runs. A side
benefit to writing to a single removeable disk is that you could toss aside
the backup software completely and just perform a straight file copy,
performing a full backup each evening.

------------------------------

Date: Sat, 8 Mar 1997 12:17:54 +1300
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: Bindery Q&A

>Since the Trustee Assignments are not stored in the bindery, but in the
>DET, how come the DET loses the assignments if the volume is mounted,
>and a bindery doesn't exist?  Do all permissions 'roll over' to Supervisor?

The DET does not lose the trustee assignments if the bindery disappears.
The entries in the DET consist of object ID/rights pairs, and if the bindery
is lost there are no objects corresponding to the object IDs in the DET.
When restoration of volumes is done before restoration of the bindery,
restoration of trustee assignments will fail as Netware does not allow
creation of trustee assignments using an object ID which does not (yet)
exist in the bindery.

------------------------------

Date: Fri, 7 Mar 1997 22:54:47 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@ecnet.net
Subject: Re: Restore workstations.

>In my organization, a highschool, we administrators often have
>problem with messed up workstations (sounds familiar?). I'm now
>looking for a utility that can compare a workstation with a copy - a
>mirror - that is placed on the server, delete those files that
>shouldn't be there and add those that should.

That's the hard and time consuming way.

I'd suggest looking at Ghost.  It takes a snapshot of a system and
lets you restore it.

I evaluate software, and sometimes the software I evaluate leaves my
PC dead or dying.  Since I made a Ghost image of my system the way I
want it, I just reload it.  It takes about 10 to 15 minutes for a 1.2
gig drive.  I reinstall Windows 95, Office 95, a number of Internet
applications, and a stable full of applications I use.  When the
Ghost program is done, I reboot, and I'm back where I was.

If the PC's are somewhat different, the normal Windows 95 system
inventory will take care of the differences, and you'll have to
reboot to have the system be where it should be.  In some cases, such
as Compaq's with diagnostic partitions, you may have to have separate
images for different machines.

I also use it to restore Windows NT servers, NetWare servers, Windows
3.1 and Windows for Workgroups 3.11 machines, as well as my FreeBSD
machine that is my link to the internet.

You can get an evaluation copy of the program from:

	http://www.ghostsoft.com

along with information about where it can be purchased.  The program
is $250.00 for a 10 PC license.

------------------------------

Date: Mon, 10 Mar 1997 07:00:00 GMT
From: "Forrest H. Swick" <fswick@MAIL.UNIVNORTHCO.EDU>
Subject: Re: ArcServe 6 and Netware 3.11

>Okay, I've gone to Cheyenne multiple times and basically gotten the
>"it's Novell's problem" answer to my problem, which is:
>
>I have a Netware 4.10 server set up as a backup server with ArcServe
>6.0 as the only thing running on it.  I am trying to back up a
>Netware 3.11 server (patch level G).  The problem is that ArcServe
>will establish a connection to the 3.11 server, but can't seem to do
>anything else.  I watched the console as ArcServe connected, but the
>only activity that could be seen was something labeled "Requests",
>which was constantly increasing.  Nothing was being read, nothing
>was being written.
>
>Cheyenne says that the most stable version of 3.11 they have seen is
>ptd (which seems strange to me, since we are up to ptg now).  I have
>tried ptd, and I found it to be *less* stable than ptg.
>
>Does anyone have any suggestions that might enable me to get this
>thing working?  (Aside from upgrading the 3.11 to 4.11 - that's in
>the works, but won't happen this week)

How ironic. We just got through with an email "discussion" with
Cheyenne's Arcserve Technical support with v5.01g with the exact same
problems happening on one of our NW3.11 servers. They told us that
the problem is resolved by us upgrading to version 6.0 for a
fee. (Which after the hapless support that we just got with v5.01g
I'm UPGRADING to a different company's backup solution.) Now that
I've found out Arcserve doesn't like NW3.11 it's more then a good
business move to upgrade to Seagate Backup Exec for NetWare!

My understanding is that Cheyenne writes the Arcserve software in a
way that it's not 100% compatible with future versions of CLIB.

You are not alone in your problems.

------------------------------

Date: Tue, 18 Mar 1997 10:43:08 -0500
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Restoring compressed files

>If you use ARCserve 6 you can have the backup decompress the files to tape.
>That way the files are stored on tape in an uncompressed format.  Then you
>can restore them when-/where- ever you wish.

The Intel StorageExpress currently uses a custom-built Arcserve 5.01d
engine.  Yikes!

>Otherwise, you can use an application to open every compressed file (twice
>or more depending on the compression settings) and back it up in pieces for
>restore.  A virus scanning program might be good for accessing all files in
>a given directory when properly configured.

... but it's 12GB of stuff on an 8GB volume, so they wouldn't decompress.

>Lastly, you could enable compression on the new drive, restore, decompress
>the files, backup the newly created, fully uncompressed volume with data,
>recreate the volume on the new drive without compression, restore (whew!).

Double yikes!  I hadn't thought of that - it just might have to do.  Well
worth it to get rid of compression.  Besides, as I said before, I bill hourly.
One way or another, compression costs ya'.

>Of course, NDS and trustee assignment considerations need to be carefully
>planned as well.

If careful planning were a factor in this, I wouldn't be having the problem!

Maybe I shouldn't be so hard - it was Novell's decision to turn it on by
default.  Inexperienced LAN managers are inclined to take the defaults when
installing - I shouldn't blame them.  But it's fun.

------------------------------

Date: Wed, 19 Mar 97 07:59:25 -0800
From: Randy Grein <rgrein@halcyon.com>
To: <netw4-l@ecnet.net>
Subject: Re: 100 Mbit/s

>In my company we have 2 novell netware servers one 3.11 and one 4.1, my
>backup runs on the 3.11 server and it takes backup of the 4.1 server, my
>problem is the speed. My thought is to put in a 100 Mbit/s net card in
>both servers, my problem is can I do this without buing a 100 Mbit/s
>HUB.

Just a side note: Make sure that you update the networking components of
BOTH servers. Most backup software uses SPX for reliability. You MAY be
aware that SPX I is limited to 512 byte packets, it also requires an ACK
for every packet. With the updates and pburst.nlm on the 3.11 server
you'll get much better throughput on standard and fast ethernet. I've
managed 50% utilization on standard ethernet between two servers during
backup using Palindrome, which isn't too bad.

------------------------------

Date: Thu, 3 Apr 1997 11:41:48 -0600
From: "Alan L. Welsh" <snapback@IX.NETCOM.COM>
Subject: Time exclusion on 4.x & Intanetware

>I have a little problem with the loging Time exclusion in nwadmin.
>
>Configuration :
>
>3 nw410 server with latest DS.NLM
>1 nw411 with latest service pack and libupc.
>
>The nwadmin is this shipped with intranetware (nw411).
>
>If I exlude people from 2 to 4 AM (backup time) they could'nt loging
>from 8 to 10 AM.
>
>all servers are time synchronised and time setting are correct.
>
>This problem is apparent since we have used the Intranetware nwadmin
>(win31) to modify this time exclusion.

I am assuming that you must log out your users so that you can do the
backup and all the open files actually get backed up.  If this is so,
another alternative is to use an Open File Manager that doesn't care which
files are open or in use on the fileserver.  Open File Managers (OFM)
present a static image of your server at a particular point in time to the
backup software.  They also can prevent your backup from skipping files
that are open or in use.  Without it, your accounting system could be
corrupted on the backup tape, and you'd never know it, until you (attempt)
a restore.

Why?  For example, lets take an accounting package, and say they were
paying you in the middle of the backup without OFM.  First, the record
showing if you had been paid in the "payroll payables" file is marked
"paid" and then that file is backed up.  Next, the backup package backs up
the "cash disbursements" file showing that the check had NOT been written.
THEN the payroll "cash disbursements" file is updated showing it is paid,
(checks to be run the next day).  That night, the server crashes and you do
a full restore in time to run payroll.  5:00 comes and everyone is happy,
except you didn't get paid, and accounting swears that you did by their
records (in the "payroll payables" file).  --OK, this story could be
improved, but you get the idea; any complete software system must be backed
up as a complete entity, at one point of time, and that includes
Intranetware, email, accounting, even many of today's desktop apps, and
especially the NDS.

There are basically three type of OFMs or OTMs.  Database-based OFM,
file-based OFM, and block-based OTM.

Database based OFM--Cheyenne has had specific Oracle (and other) agents
that communicate directly to these agents for years.  If you have Oracle,
this would be the best, as it is "tuned" to these environments.  The
downside is that you must buy one for each database, otherwise, you are not
protected.

File based OFM--St Bernard has been selling a general purpose, file-based
product for quite some time that doesn't care which files are open, it will
present the complete server's files to the backup as one complete file
image.  Cheyenne acquired IQI, who developed a file based OTM last summer
and should have that available as well.  Vinca also has one called Snapshot
that can be obtained if you have their Standby Server.

Block-based OTM--This works at the lowest possible level of your server and
has no direct knowledge of your files, and is the one I am most familiar
with.  Since it is transaction based at the sector drive level, we call it
Open Transaction Manager (OTM). It makes sure that every block on the hard
drive is backed up as it was, at a particular instant in time.  This way,
it not only captures all open files, but also any open transactions (think
NDS) that might be occurring on the file server, hidden to everyone
including the OS.  While the backup is taking place, users can write to the
drive in real time without degrading performance.  At this time, it is
closely coupled to our backup software, Snapback.  In fact, without this
OTM, Snapback would have either had to unacceptably freeze the volume, as
some other packages do, or, the image of the hard drive that we take as our
backup would have been corrupt.

Whichever method you use, use something for OTM, as most of us are all are
moving to 24x7 environments whether we like it or not.  And, if you don't
have OTM, your backup will generally be missing the MOST critical files,
capturing only the ones that don't change as much.

------------------------------

Date: Thu, 3 Apr 1997 13:19:42 EST
From: Sam Martin <Sam_Martin@G1.COM>
Subject: Re: Time exclusion on 4.x & Intanetware

>I am assuming that you must log out your users so that you can do the
>backup and all the open files actually get backed up.  If this is so,
>another alternative is to use an Open File Manager that doesn't care
>which files are open or in use on the fileserver.  Open File Managers
>(OFM) present a static image of your server at a particular point in
>time to the backup software.

<Big snip>

... OFM will attempt to provide such an image of a file, not a
server,unless you group all the files on that server. The window
during which no activity may take place on the target, be it a single
file or a group of files, is selectable from 1 sec. minimum, as I
recall, to minutes. If OFM cannot find such a window during any of
several retries, whatever options you have selected in the backup
program will be in effect. The target may be skipped, or copied as is,
with a wing and a prayer.
Obviously,for all practical purposes, a user will get a valid copy. A
1 second window w/o a write, even if several files are taken as a
group, at the times most backup programs are run is probably not too
hard to find. Not a minor point,tho', and one I missed the first time
thru with OFM.

------------------------------

Date: Thu, 24 Apr 1997 00:01:57 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Bring back a full backup on a NW4.11 server

>I want to know if anybody have a procedure on how to reinstall a
>NW4.11 server that the hard disk had crash?
>
>When I will reinstall the server I don't want to lost all the rights to
>the files by the time I add the server in the tree and I bring back the
>backup of the files.

Assuming that you:
1. do not have mirrored drives nor duplexed ones nor a RAID system
2. did not use DSMAINT recently
3. don't have backup replica's on other servers
4. have a full SMS compliant backup with a backup of the DS also

Then:
What you basicly need to do is:
1. install a new harddisk
2. install Netware on it
3. patch everything as much as possible (eg DS.NLM)
4. make sure that all the TSA NLM's are in AUTOEXEC.NCF
5. install and patch up your backup programm
6. restore your NDS only
7. reboot
8. restore your data
9. reboot
10. run DSREPAIR
11. find out what data was losed

The website of your favoured backup programm should be able to tell you
details. If not try http://support.novell.com and search the knowledge base.

------------------------------

Date: Thu, 24 Apr 1997 13:59:19 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Backup Exec degradation on NW 4.10 server

>Here's the problem as it stands:
>Backup Exec seems to be functioning properly (the files get backed
>up), but since going from 3.12 to 4.1, our throughput has pretty much
>died.
>
>We are using:
>	Backup Exec ver 7.11 rev 5.110 - Enterprise Edition
>	NW 4.10 server (with *ALL* the latest patches applied)
>	Adaptec AHA 1542C SCSI adapter
>	  - driver is AHA 1540 dated 10/25/95
>	Server is an EPS Pentium 100 with 32M of RAM
>	Reserved buffers below 16M = 200
>	HP Surestore Tape 5000
>	Archive Python
>
>Only system NLM's are running on the backup server - if it doesn't
>relate to the backup, it isn't there.  Before Backup Exec starts, we
>have 70% cache buffers.   One of the tape drives is internal, the
>other is external (though, that doesn't make any difference...).
>
>Prior to going to 4.1 (in January), throughput was 13-14M per minute
>internal backup, and 12-13M per minute across the wire backup..
>We re-worked some of the hardware and then installed 4.1 on the
>servers instead of migrating from 3.12 to 4.1 (we did that due to
>hard drive space).
>
>After installing 4.1 on all servers (including the backup server),
>throughput dropped to 9M per minute internal, and 2-3M per minute
>across the wire.  We tried disabling Backup Exec's Agent Accelerator,
>and over the wire throughput increased to 4.5-5M per minute.  Changing
>Backup Exec's internal buffers did not affect performance whatsoever.
>Lan card statistics show no collisions, no lack of ECB buffers and no
>lost interrupts.
>
>Utilization sits at 100% while the backup is running.  The Processor
>Utilization screen shows *STREAMS Q-Runner task consistently staying
>at 92-96% when doing over the wire backup.
>
>We have verified that there is no compression going on on the servers
>at the time of backups.  Setting the tape drives to hardware
>compression or to no compression makes no difference.
>
>The backup server itself has changed in a few ways.  We've changed
>systems and SCSI controllers.  We have also reinstalled Backup Exec
>from scratch.
---------------
	Have another look at that venerable (really ought to upgrade it)
1542 SCSI controller. Its DMA rate may be set too high, sync negotiation
may be turned off, and so on. Further, look at the drivers because Novell
has both .DSK and .HAM varieties, and BackupExec warns don't use the more
recent .HAM flavor with BE at this time.
	If a so-so SCSI disk is on the same controller as the tape drive
then be prepared for trouble. Some disks are better than others. Use
separate controllers if that is your problem. A 1542 is OLD, not very
fast, and still eats a lot of cpu cycles doing its work. Upgrade to a PCI
based SCSI controller (say an Adaptec 2940).
	Look at your lan material. Try turning off Packet Burst because
under sustained load it can go unstable. This will cut your peak throughput
compared to good conditions and double it compared to bad conditions,
according to observations here. Look again at the Ethernet boards, which
we hope are decent server units rather than cute DOS/Windows thingys. If
they have early transmit/receive abilities then turn off those abilities.
The same applies to the other end of the wire.
	Look at the motherboard configuration and pay attention to having
tweaked wait states and similar items.
	Look at packets on the wire. There is a "test" version of spxs.nlm
floating around and one of those tested here speaks only tiny-packets,
thus reducing throughput to zilch and saturating the wire. Both ends of the
connection participate so check both machines.
	Joe D.

------------------------------

Date: Mon, 5 May 1997 15:10:38 +0200
From: "JOURNEL P. TRANSTEC/DRES Admin" <pierre.journel@MERCURE.CISI.FR>
Subject: How to upgrade your server : Disaster Recovery !

A couple of days ago I asked for the best way to change a Netware 4.x
server from an old 486 to a brand new Pentium.

I did it with the Disaster Recovery option of ARCserve 6.x. It took me
4 hours to backup the old machine and to restore to the new one. The new
machine is running perfectly, no problemo (no NDS problems, no print
server crash, etc...)

The DR option allows to create 3 disks on which you boot your new
machine, it loads Netware and ARCserve and then restores all the
partitions (Netware AND non-Netware). You just have to pay attention to
the disk driver you load if the hardware change completely which was the
case for me.

------------------------------

Date: Mon, 5 May 1997 19:25:59 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Full Restore from Backup - No users

>I had a hard drive that was my SYS volume die on me today (3.11
>server).  I replaced the drive and did a full restore from backup
>using SBACKUP v3.12.  However, when I go into syscon, there are no
>users listed.
---------
	What's missing is the bindery from the original server. See if
there are three files sys:net$xxx.old on tape or new server. If so the
use bindrest to reactivate them as the bindery. Recall, restore the
bindery files first, and only afterward restore other files (so ownerships
etc are retained).
	Joe D.

------------------------------

Date: Mon, 5 May 1997 19:42:59 -0700
From: John Wells <jwells@PACIFICCOAST.NET>
Subject: Re: Backup Exec degradation on NW 4.10 server

>Here's the problem as it stands:
>Backup Exec seems to be functioning properly (the files get backed
>up), but since going from 3.12 to 4.1, our throughput is way down!
>
>We are using:
>Backup Exec ver 7.11 rev 5.110 - Enterprise Edition
>Novell 4.10 server (with *ALL* the latest patches applied)
>Adaptec AHA 1542C SCSI adapter
> - driver is AHA 1540 dated 10/25/95
>Server is an EPS Pentium 100 with 32M of RAM
>Reserved buffers below 16M = 200
>HP Surestore Tape 5000
>Archive Python

Last year I ran into a similar, although not identical problem. Perhaps
there's something helpful in it for you. (Apologies for the delayed reply
-- I'm playing catch-up.)

1. Started with three patched 3.12 servers (IBM 300, various RAM), using
BE 5.01B Enterprise. One server with Conner QIC 3080 drive on dedicated
1540CP controller. Was getting 20-24 MB/min on both local and remote
backups.

Many have commented on the importance of putting a tape drive on a
separate SCSI controller from hard disks. Our backup system was nearly
useless until we did so. I'm surprised you were getting only 12-13 MB/min
with BE and the HP DAT drive. Do the drives have their own SCSI adapter?
What happens if you run with only 1 drive?

2. Upgraded one remote (across-the-wire backups) server to 4.1. Backup
speed from that server immediately dropped to about 3 MB/min.

3. Much time on phone to Seagate/Arcada (plus posts to this list). Tried
BE 7.01, turned compression on/off, enabled/disabled agent support, turned
sync negotiation off/on, set DMA at 5/10 MBps (Arcada and Conner
conflicted on their recommendation here), went back to earlier NW patches,
increased buffers, plus other stabs in the dark suggested by Seagate. All
with essentially no effect.

Eventually upgraded to BE 7.11, and the updated TSA support which came
with it (newer than Novell's released patches at the time) brought backup
speed up to about 10 MB/min. (I know it was the TSA NLMs, because using
those with BE 5.01E also gave 10 MB/min.)

10 MB/min was much better than 3 MB/min, but still only half what it had
been, and half what we continued to get on and between the 3.12 servers.
However, the comments from the list were that 10-20 MB/min was in the
"normal" range, and Seagate stopped returning my emails, so we left it at
that.

4. Last month we replaced the 3C579 NICs (EISA) in the 3.12 servers with
3C900s (PCI, prior to reading Joe D.'s comments on 3C90X). Although this
involved absolutely no change to the remote 4.1 server, remote backups
from it immediately returned to the 20-24 MB/min range. (And it has
nothing to do with bus mastering, as we discovered our particular IBM
servers don't support bus mastering PCI!)

(Thus my followup question: Can someone please explain this to me? The
3.12 backup server only has a problem with remote servers running 4.1 --
not 3.12;  and the problem disappears when the NIC+driver in the 3.12
server is changed.)

So, if you already have the tape drives on a dedicated SCSI card, then you
might try different NICs.

------------------------------

Date: Fri, 6 Jun 1997 18:42:25 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: What Gets Backup?

>If I do a complete backup on NW4.1 (including the NDS per Arcadia Backup
>Exec),  I realize the DOS partition isn't backed up.  Questions are:

	Version 7.11 of BE, I hope. Also read your BE docs to discover
its C: to SYS: copy program. I use it only as an emergency device because
copying C: is far easier with both disk drives mounted at DOS level.

>1.  Is all of NW4.1 NOS backed up?

	See above. If BE 7.11 then yes, or less if you wish.

>2.  Assuming the backup is good, can I use it to migrate to a new, more
>powerful file server using NW4.1?

	That's not a migration per se but a fresh build followed by a
restoration. Please see Novell's docs on hardware replacment (the hard
disk in this case). Don't just restore NDS stuff from tape without careful
planning.

>3.  Or, is it better to use ncopy to copy all the files from the old
>server to the new server?

	Here you should know the answer (CNE). No. Rights and ownership
and namespaces etc do not move by COPY nor NCOPY. Use the tape drive.
	Joe D.

------------------------------

Date: Fri, 20 Jun 1997 00:41:46 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Netlab<n>, outages, explained

>	Sunday the valley where I live lost all power for 9 hours from
>a damaged power substation.
>	Today SprintLink lost our DS3 line from Salt Lake City to the
>world. It's back in operation.
>	This afternoon the substation went out again, and because it
>is still out I am on battery listening to beep-beep-beeps (ACP stuff).
>It has been off for 45 minutes so far and expectations are for many
>hours. (Hint #2, use *BIG* UPS').
>	While the last amps drain away I thought I'd explain.
>	Joe D.

Instead of a *BIG* UPS you may want to install a fuel driven generator
big enough to power the entire site (or at least its most important
functions) in case of a long power outage.

The advantage of a generator is that it will hold out for months if
need be as long as you keep the fuel tank filled.

You still need a (small) UPS though. Generators need time to start. And
you need a little box that cleans up the power that is coming from the
generator (it fluctuates). Unless your UPS does that also *and* all
major functions are connected to that same UPS.

---------

Date: Thu, 19 Jun 1997 17:32:09 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Netlab<n>, outages, explained

	Somehow or other I suspect the authorities will take a dim view
of moving a hefty diesel m/g set into my lab. We have lots of them for
emergency power to buildings, but emergencies do not yet include lack of
personal network connectivity (routers yes, people no). Hence no such
feature in my office or lab. And a big UPS is needed to carry over the
startup interval.
	Just as a curiosity item, I'm accustomed to very big (train engine
size and down) generators in the field. Once such field area is Antarctica
where a minimum of three is needed for survival: running, warm backup,
cool rotating backup). If no generator then bye bye, endif.
	The prize suggestion made by a couple of people is forget the
network and computers. Instead plug the coffee machine into the UPS for
survival. Astute advice, that.
	Joe D.

---------

Date: Thu, 19 Jun 1997 19:52:07 -0400
From: Larry Hansford <hansford@ERINET.COM>
Subject: Re: Netlab<n>, outages, explained

>Instead of a *BIG* UPS you may want to install a fuel driven generator
<snip>
>* Arthur B.

You didn't mention that Joe will need a heaters to keep the diesel warm
during the winter months in Utah so it will start when needed.  A few years
ago we installed a Cray supercomputer in Michigan with "significant UPS"
systems and a large diesel generator to provide power to the UPSes when
there was a power outage greater than 30 minutes.  As all things networks
go, they found flaws with the system on the first outage -- it was the middle
of January with temperatures in the -25 degree range and the diesel
refused to start.  More importantly, only the Cray and its  peripherals had
been connected to the UPS -- none of the Cisco routers or comm closets
had been so protected.  So, for the hour or so that the Cray continued
operating, there was no communications with it.  Was the Cray gracefully
brought down?  Of course not, the generator will start pretty soon now...

Had the system ever been tested before the outage?  Of course not, it was
in production and they couldn't risk the down time.  But then, as Joe always
says, always test your disaster recovery procedures...

---------

Date: Thu, 19 Jun 1997 19:39:06 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Netlab<n>, outages, explained

>You didn't mention that Joe will need a heaters to keep the diesel warm
>during the winter months in Utah so it will start when needed.  A few years

	Now that's an engineer talking. Very good advice. That's why diesel
m/g sets are often housed within new buildings, in a concrete vault, rather
than outside. Outside fuel also requires cold weather treatment.
	<omissions>
>Had the system ever been tested before the outage?  Of course not, it was
>in production and they couldn't risk the down time.  But then, as Joe always
>says, always test your disaster recovery procedures...
----------
	Indeed. On the first outage I discovered my mainhub wasn't on the
UPS beneath my desk. Bulky power cube, too much trouble to rearrange wires,
and other lame excuses. Fixed.
	Another example: NW 3.12 server with NE-2000 clone boards. The
server restarted ok and halted for user input when  Load ne2000 ... was
looking for a shared memory address (none such, server!). This does not
happen upon normal startups, but only when the return to life is pretty
rough (must be contest between twisted pair garbage traffic and the board
initializing). No rconsole at that point, so it's sneaker net time again.
These "user input" things are infuriating: keyboard missing, press any key
to continue.
	Another classical design goof, discovered here recently. A low
cost nifty 10MHz Etherswitch box. Looks cute. But upon power failure or
other upsets the reset button needs to be pressed. Oh? In which closet
on which floor of which building?  Why would any hub/similar/box have a
reset button or even need it? Unplugging the power is the normal way.
	And we all know about the "smart boxes" that discover IPX network
numbers and frame kinds by snooping on the net when they start. Real bright
idea, yup. There are worse stories (Apple's gear stealing "free" IP addresses
is a good one).
	Oh, and one last true story from yesterday here. After the last
power outage I was called over to a lab where they said some machines
could make TCP/IP connections but neighbors could not, all on the same
cascaded hub set. IPX worked fine, server was happy. Could/could not were
often on the same hub, for gosh sakes. The power glitches scrambled hub CMOS
memory enough that the snmp telnet part must have been nibbling on IP-only
traffic, and only on some ports. Reloaded the firmware and all was well again.
	Joe D.

------------------------------

Date: Wed, 20 Aug 1997 16:08:11 +0100
From: Richard Letts <r.j.letts@SALFORD.AC.UK>
Subject: Re: Exabyte Tape Life?

>>I am running an Exabyte 8mm tape drive for about 4 months with Exatape
>>160mXL tapes. The tape drive backs up a Novell 4.1 server with ArcServe
>>6.1. This week I have gotten media write errors on two separate tapes,
>>one missed a single directory but the second missed several volumes. :-(
>>Is there a suggested rotation period for the Monday-Thursday tape group
>>or should I wait for media failures to replace? Many thanks

THE MTBF of all the exabyte drives here was less than a week until we
stopped using them.

We have our known-to-be-working firmware tape to 'fix' drives just back
from repairers.

In the end we've stopped using the drives, arcserve and have gone back to
using SBACKUP and DLT's.

>My experience is that you should better dispose of the 160m tapes and
>use 112m tapes instead. I've seen many media errors with 160m tapes
>(and I did clean the tapedrive regularly), which almost all
>disappeared when I switched to 112m tapes. I'm afraid this is one
>development which they'd better left to rest. :-(

I'm currently more interested in DDS3 or DLT.
DLT tape dirves are nice because they are:
 - fast
 - reliable (1 failure in 2 years(6 drives) vs 1 fail per week(22 drives))
 - large capacity 20/40GB per drive.

---------

Date: Wed, 20 Aug 1997 09:35:15 MST7MDT
From: "John L. Stevens" <stevens@KIMBERLY.ARS.PN.USBR.GOV>
Subject: Re: Exabyte Tape Life?

The 8mm Exabyte that I WAS running always had error rates of about 1
to 5% but the data was available.  It is now on a HPUX box doing an
occassional backup. The longer tapes are thinner material and
therefore can be less reliable.  I used Sony tape for a month but
they were terrible.

Don't skimp on backup.  Backup is the next very important piece of
equipment next to the server.  I now use a DLT autoloader that works
great and seldom needs cleaning.  The tapes have been in service for
two years and still no errors.  Rather amazing - I suspect I will
need to retire a several before the end of the year.  Most of my
people keep their data on the network because they know (I tell them)
that their data is secure.

---------

Date: Wed, 20 Aug 1997 13:08:57 -0700
From: "Rappaport, Shawn" <shawn.rappaport@SPECASTRO.COM>
Subject: Re: Exabyte Tape Life?

>I'm currently more interested in DDS3 or DLT.
>DLT tape dirves are nice because they are:
>- fast
>- reliable (1 failure in 2 years(6 drives) vs 1 fail per week(22 drives))
>- large capacity 20/40GB per drive.

Our new DLT7000 drive's tapes hold 70GB compressed! I finally don't need
to come in on the weekends to swap out tapes for our full backups. :)

------------------------------

Date: Fri, 5 Sep 1997 19:50:17 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: win95 workstations advertising as a server

>>>I am operating in a novell 4.1 environment and we have a few win95
>>>workstations.
>>
>>Please look again at the Networking panel. Turn off
>>file/print sharing over IPX.
>>	Joe D.
>
>Another thought - do you use BackupExec? I believe that any
>workstations that have been set up as agents (i.e., set up to be
>backed up over the network) will show up as servers.
>
>Anybody know if ArcServe works this way?
>
>Michael Leone
----------
	BE and AS client agents use their own IPX SAPs, not Type 4 for
NW server. They don't appear in SLIST/NLIST SERVER /B. Win95 uses Type 4
for sharing files/printers over IPX, and hence the major problems from
them. We have plenty of both tape backup programs in use here.
	To see who advertises what over IPX SAPs go to the server console
and Load IPXCON. Select Services. Open up interesting selections to reveal
the MAC address of the station doing the advertising and how many hops
away it is.
	Joe D.

------------------------------

Date: Thu, 11 Sep 1997 16:59:25 -0700
From: "Steven W. Smith" <SYSSWS@GC.MARICOPA.EDU>
Subject: Potential gotcha with BackupExec ($$$)

  I think a heads-up is in order for those who use Seagate BackupExec
(and/or Seagate/BE Intelligent Disaster Recovery For NetWare).  We're using
BackupExec v7.11 Enterprise Edition and overall are happy with it.

  When you do a full backup of the server on which BE is loaded, it
silently ignores all files in SYS:BKUPEXEC which end in .RES (in our case,
17 files)  The problem is that SYS:BKUPEXEC/BESRVR.RES holds the serial
number information, without which BE becomes a demo installation which
expires in 60 days.

  For example: you use the Intelligent Disaster Recovery product to
recreate a server (after upgrading the disk farm in my case) you'll need to
re-enter your 16-digit serial number to get BE working properly.  This
isn't a big deal, except that this information doesn't appear in the docs,
and there's no way to get Seagate to give you either "your" serial number
(from the software registration card you sent in) or a working replacement
if you misplace all records of the number.

  I lost our serial number, I restored the server from a "full" backup, I
had a demo version set to drop dead at midnight on Halloween.  The first
tech support guy (this morning) suggested that I "restore it from a full
backup".  After I discovered that there's no such thing as a "full backup" I
called again.  After a lengthy, pleasant discussion with another techy, I
was forwarded to the Sales folks in hopes that they'd have the number.  The
final suggestion was that I cough up "about $400.00" and upgrade from
version 7.11 to version 7.5.  Fortunately, I had the same copy of BackExec
loaded on another server awhile back and was able to copy over the
BESRVR.RES, which worked (and I've written down the number).

  The moral: hang onto that serial number and you may want to manually ncopy
sys:bkupexec\*.res somewhere for safekeeping.

---------

Date: Thu, 11 Sep 1997 19:08:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Potential gotcha with BackupExec ($$$)

	This is nothing new, and it is a characteristic shared by almost
all tape backup programs. Put simply, BE does not backup files which are
held open. Besrvr.res is held open, as can be seen easily by visiting
MONITOR on the console.
	If your BE registration number exists only in that file then,
clearly, your site is exposed. So write it down again. And devious
system managers make a usable copy of critical directories on other
systems so the contents are available without tape drives.
	Joe D.

------------------------------

Date: Mon, 27 Oct 1997 19:05:07 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Novell Workstation to backup unix server

>The tape backup on our unix server has died.  WE have a tape backup
>on a novell workstation.  Is there some reasonably priced software
>that would allow the unix filesystem to be mounted on a windows 95
>desktop, or look like a novell filesystem, etc.?  Any pros and cons?
>Reasonable means cheaper than reparing or replacing the unix tape.

You can try NFS for Win95 from Netnmanage, it allows you to access Unix
filesystems like they are regular drives and then you can back them up.

------------------------------

Date: Mon, 27 Oct 1997 19:07:29 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Tape Backup

My personal experience with autochangers has been that they are
incredibly prone to problems due to temperature changes and dust.  If
you are looking for a better solution, go for the large capacity DLT
tapes. They are very fast, allow for a maximum compression, and you can
take the tapes home with you as you want.

I took out our changer at one client and installed a DLT instead and
have had 0 problems since then.

>I am currently backing up several Novell file servers (about 5 Gb
>total)
>and about 90 workstations with (2) DAT drives and ArcServe 6.x. I am
>putting a new Novell server into service that has 29 Gb of storage and
>in the coming year I expect a couple of Windows NT systems to come on
>line with another 30 Gb between them.
>
>I have looked at DAT autochangers but I would like to shorten the
>backup time so I am more interested in either DLT or AIT single drives.
>Additionally, I like to take the most recent backups offsite with me
>each night for insurance and the autochangers don't seem to lend
>themselves to this scenario very well. One or two tapes is a lot
>easier to keep track of then 4 or 5.

------------------------------

Date: Wed, 29 Oct 1997 08:45:54 +0100
From: Poul Lausen <pla@EKJ.DK>
Subject: Backup Exec v.7.11 and Netware 4.1 -Reply

>Is there anyone out there using Seagates Backup Exec for Netware?  One
>of the options Backup Exec offers is to backup open files.  The
>documentation states that Backup Exec will lock those open files as it
>copies it to the tape.  When we do full system backups, we were concerned
>about all the open files used by the server (i.e. NLMs).  Will this cause
>problems with the server?

The documentation states that Backup Exec will lock open files, but as I
remember, the documentation also recommends to use a dedicated
program, if Backup Exec fails.

I use St. Bernard Open file Manager to solve the problem with
open files, and it works great.

------------------------------

Date: Thu, 30 Oct 1997 10:23:34 -0800
From: Steve Maybo <steve@RIS.RISINC.COM>
Subject: Re: Backup Exec v.7.11 and Netware 4.1

>Is there anyone out there using Seagate's Backup Exec for Netware?
>One of the options Backup Exec offers is to backup open files.  The
>documentation states that Backup Exec will lock those open files as
>it copies it to the tape.  When we do full system backups, we were
>concerned about all the open files used by the server (i.e. NLMs).
>Will this cause problems with the server?

NLM's used by the server are not OPEN files.
When the server loads an NLM, it loads the "program" into memory and
uses it...it doesn't keep the SYS volume copy of the NLM open.

You can check the MONITOR File Open/Lock option to see this.

I use backup exec and do not backup open files as we have some really
old database programs (which employees are instructed not to leave
running at night when backups run) that suffer corruptions if backup
exec tried to backup any open files.

------------------------------

Date: Thu, 30 Oct 1997 16:20:49 -0600
From: "Gregory Gerard Carter (Mascot)" <gcarter@DIGIVIS.COM>
Subject: Re: Cheyenne ARcserve

>Does anyone use Cheyenne ARCserve to backup their server? I am thinking
>of buying the software, does anyone have feedback on the software?

I use Cheyenne Arcserve 6.1.  I am quite pleased with it.  I am co-owner
of a local integration company here in Milwaukee WI and I bet the business
on it.

No other piece of software encompasses so many diffferent platforms as
effectively as Arcserve, at least in the tests that I carried out.
I have Unix, NT, Win95, and Macintosh systems to worry about.

It is a bit finicky though.  But, I have never had to shutdown my server
from abends in the last 9 months.  Unlike in past jobs, I design my
systems internally using a lab, then I deploy.

If you use this kind of method, anything you install goes smoothly.
Of course, I had to quit my job and start my own business with a friend
to finally have the top guy have enough smarts to realize you don't
deploy technology and cross your fingers.

---------

Date: Thu, 30 Oct 1997 15:25:59 -0700
From: Robert Seifert <seifert@GWC.MARICOPA.EDU>
Subject: Re: Cheyenne ARCserve

We use Cheyenne ARCserve for NetWare 6.

Upon release of the product (v6.0), the Manager software was quite
unreliable.

With their recent service pack of v6.1, I have seen much improvement.

Make sure you purchase a Tape Drive/Changer supported by the software.

The manual is sometimes difficult to follow.

------------------------------

Date: Fri, 7 Nov 1997 11:40:56 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Backup software for 4.1

I use Arcada Backup Exec and have had no problems with backing up a
multi environment system (Netware, NT, WSs etc) or restoring them.

Some others like or prefer Arcserve.

Personally to tell the truth, I like Arcada because their service is top
level and they get back to you on every issue, no matter how minor or
major and 90% have solved every issue for me.

On the other hand Arcserve has put out 7 versions (including patches
etc) in the past 2 years.

Think about it :)

------------------------------

Date: Wed, 12 Nov 1997 08:57:20 -0800
From: Craig Willox <cwillox@CARIBOOCA.COM>
Subject: Arcserve 6.1 with Novell 4.11 SFT-III

>I can't get arcserve 6.1 working on novell 4.11 sft-III..
>We have an aha2940AV in one IO..
>the documentation says we need to load ham-drivers on the io and
>nwaspi.cdm on the ms to communicate. There are no ham-drivers for this
>card..
>
>Can someone help me with a sample configuration or something alike??

From what I've read and seen, SFTIII doesn't allow any backup software
to be run on it.  You'll have to invest in another server for this sole purpose.

------------------------------

Date: Thu, 13 Nov 1997 16:27:56 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: On reading "High Speed Backup Solutions" -Reply

>I've just got round to reading the thread on high speed backup
>solutions from September.
>
>I'm flabbergasted by speeds of around 100Mb/min. Presumably the
>tape drives are connected directly to the server machines?
>
>Ours is. We use a DLT 15/30 gig tape drive that gets from 60-120 MB/min.
>
>On our little setup we're backing up about 8Gbytes from 2 servers
>to a couple of DAT drives connected to a workstation running ArcSolo.
>The setup is extremely simple but we get only about 1-5% of this
>throughput.
>
>Would it be quicker if we attached each tape drive to one of the
>(V3.12) servers? What (simple, inexpensive) software could we then use,
>presumably an NLM?
>
>Have you looked at Seagate Backup Exec for Netware? I believe they still
>give a 60-day full-version evaluation.
-----------
	Keep in mind the network. On the same wire regular 10Mbps Ethernet
maxes out at about 1MB/sec (60MB/min). Add a bridge or router and this
figure drops by up to half. Do it again and get divided again.
	BackupExec is a good product, use it here, but... The network
connection is via SPX (Novell's attempt at TCP) for acknowledged and
sequenced delivery and that is exceptionally chatty on the wire. Throughput
goes down accordingly. Confidence does cost. Expect many MB/min via routers.
	Joe D.

---------

Date: Thu, 13 Nov 1997 15:52:07 -0800
From: Steve Maybo <Steve@RIS.RISINC.COM>
Subject: Re: On reading "High Speed Backup Solutions" -Reply

>>I've just got round to reading the thread on high speed backup
>>solutions from September.
>>
>>I'm flabbergasted by speeds of around 100Mb/min. Presumably the
>>tape drives are connected directly to the server machines?

Backup speeds also vary greatly depending on WHAT you are backing up
(certainly having the backup drive directly on the server helps
greatly and avoids your cabling/router/hub limits)

Backing up large database files on our exabyte 8mm drives that are a
few years old via Backup Exec yields about 60MB/min.  Other volumes
(with lots of smaller files) backup at 35-45MB/min.  Our average is
about 45MB/min.

So...MB/min levels are relative!

------------------------------

Date: Thu, 20 Nov 1997 15:09:16 -0500
From: Eddie AFC Evans <eevans@AFC-IT.COM>
Subject: Moving from compressed to uncompressed volume(s)

The purpose of this post is threefold, one I hope to save someone else
the trouble I've just been through, two if anyone can suggest a better
way, and finally would Arcserve 6 have helped, or is this solely up to
the TSA, and (fourth?) can I modify the behaviour of TSA's ?

I recently decided to 'uncompress' a (mirrored, duplexed) 2.0G Netware
4.10 volume, not SYS.  I had several recent backups of all but a mail
PO.  After using native tools to backup the PO to another location,
deleted the volume using Nwadmin.  Went to console, removed the volume
and recreated it, this time without compression.  (Suballocation on in
both cases.)  Gave volume same name as original had.  I decided to do
the tape restore first, then move PO back, so no danger of older data
being in the post office.  Loaded tape, submitted restore, failed.
Couldn't talk to TSA.  TSA's loaded on both target server, and 'backup
server'.  Backup server Netware 3.12 Arcserve 5.x, w/HP 6 DAT
autochanger and  DLT.  TSA's match.  Aha- volume created after TSA
loaded!  Much later that night restart server, talk to TSA's just
fine, but.  Restore still fails.  Erc fffdfffd on many, but not all
files/dirs.  Restore to alternate location AOK, all files & dirs back.
Poke around with permissions, restrictions for many hours to no avail.
Work with Intel TS (Backup server is an Intel Storage Express.)  Find
eventually that the TSA's move the data to tape
_in_compressed_format_from_compressed_volumes_.  Sigh.  The alternate
location was compressed.  Intel suggest to do complete restore to
alternate location, copy files/dirs to intended location, do full
restore to intended location _deselecting_ all files. (Exclude filter
= *.*.)  Works! Wonderfully!  Time spent 20-25 hours.  Time actually
needed 3-4 hours, including native backup/restore of PO.
eevans@afc-it.com

------------------------------

Date: Fri, 2 Jan 1998 20:46:58 +0100
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Question about your post on the NW list *trustees backup*

>I used trstsave to save the trustee assignments.  That zip file
>contains a strustee and an rtrustee (save and restore).  The save
>feature saves them to a text file and the restore feature restores
>them to the drive....works great!  I've been using that for years.
>I see in the novell consulting area there is something there that
>may do the same thing but I haven't checked that one out.

Novell has made available some unsupported tools regarding trustees.
TBACK2.EXE and TCOPY1.EXE for Netware 3.x and 4.x.

I've tested TCOPY in a 3.12 environment and it works great.
Syntax: TCOPY <source-dir> <target-dir> /S

BTW <source-dir> and <target-dir> may differ.

------------------------------

Date: Tue, 6 Jan 1998 14:52:08 +0000
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Arcserve problem

>I am not sure that this is a Netware problem, but I am curious if anyone
>has seen this problem. I have a ArcServe (5.0) tape backup machine that
>I am trying to use to restore files to a Netware 3.12 server
>(HP Netserver LH Plus, HPDisk array, 64 MB, 3Com 3c595-TX NIC). The
>problem I am having is that the throughput is very slow (30 KB/min).
>I have taken the target server off the backbone and put it on its own
>segment with the tape machine. I have changed the cable and run the
>diag program on the NIC and it checks out fine. I have played with the
>various settings (Min directory cache buffers, max concurrent directory
>cache writes, max concurrent disk cache writes) but nothing is helping.
>I am going to insert a new NIC tomorrow and wanted to know if anyone
>had any suggestions.

Check your SCSI settings (and hardware configuration), and make sure
you're running the latest drivers and patches.  ARCserve 5.x is up to
version 5.01g the last I've heard.

Only to speed up the restore, try the following:
	1. Set NCP File Commit to Off
	2. Set Dirty Disk Cache Writes to the maximum
	3. Set Dirty Disk Cache Delay to the maximum
	4. Set Dirty Directory Cache Writes to the maximum
	5. Set Dirty Directory Cache Delay to the maximum
	6. Set Maximum Concurrent Disk Writes to the maximum

If you are using good quality equipment, it's all set up correctly,
all the patches have been applied, and you have enough RAM, then this
should be helpful.

This technique not only saves me time, but it also provides yet
another way to stress test the system (there are other ways to stress
test a system, and all systems should be pushed to work really hard
on a regular basis to ensure stability).  I've found that some
systems don't handle stress very well, and this is a really good time
to find out.

------------------------------

Date: Wed, 14 Jan 1998 16:18:36 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Vrepair and other emergency repairs, a suggestion

	When disaster strikes it does so at the most inconvenient times
and ways. It is not unexpected that volume SYS: will not mount, and in
such cases our repair and emergency recovery tools and NLMs are out of
reach. Oh &?&*%*! (er, goodness).
	My recommendation is this. Allocate sufficient space on C: or
equivalent reachable area not on a NW volume and put ALL the components
needed to bring up the server and run the tape backup system. This includes
all parts of Vrepair (meaning the .nam files too), and a current copy of
autoexec.ncf. This way you can start the server and load by hand all the
parts to make it run even without volume SYS:. DS.NLM is needed to resurrect
NDS.
	As a fallback, include client software to log into another server
from C: and all the DOS tools to tinker with disks, edit and copy files.
A TCP/IP stack and ftp client are useful to go across the net to Novell
or official mirrors or other vendor sites to get what's needed Right Now!
	A good C: area would hold an image of sys:system and essentials
from sys:login. That's a lot of space, but precious when needed most.
	Note: whenever adding patches and updates, ensure those files too
are copied to C:. Inconsistencies may cause failure to operate.

	I had a situation the other day when SYS: went down in the middle
of the day on a major production server. There were insufficient NLMs on
C: to get the machine on the air enough to run the tape software or do much
of anything constructive. Frantic running between buildings ensued, with a
floppy accumulating NLM after NLM trip after trip, as I discovered which
were required. Not fun, but intense emergency recovery efforts never are.
	Joe D.

---------

Date: Thu, 15 Jan 1998 01:50:23 +0100
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Vrepair and other emergency repairs, a suggestion

>When disaster strikes it does so at the most inconvenient times and
>ways. It is not unexpected that volume SYS: will not mount, and in
>such cases our repair and emergency recovery tools and NLMs are out
>of reach. Oh &?&*%*! (er, goodness).
<snip>

Also add to the First Aid kit:

Bootable DOS floppy (more if needed)
including SYS, FDISK, FORMAT, XCOPY, the SCSI drivers (!), LowLevel
Format tool, DiskEditor Tool, Diagnostic Tool, text editor tool, CD-ROM
DOS drivers + MSCDEX (!), sample AUTOEXEC.BAT + CONFIG.SYS +
STARTUP.NCF + AUTOEXEC.NCF, PKUNZIP, CMOS battery, screwdriver, lamp,
textfile with settings including BIOS, textfile with names and phone &
modemnumbers, textfile with How-To instructions, textfile with Not
Forget (like >1Gb translation=disabled), VLM-kit, Anti-virus, NIC DOS
driver, NIC Netware drivers, roadmap, keys, serial numbers and unlock
codes (perhaps in floppydisk form).

If possible carry a Rescue Diskette containing CMOS-data, Partition
Table, etc.

---------

Date: Thu, 15 Jan 1998 15:17:01 +0100
From: Jan Chochola <jchochola@DEMSYS.CZ>
Subject: Re: Vrepair and other emergency repairs, a suggestion

And I several jumpers of various sizes (disk manufacturers
like to reinvent a wheel).

Recently, we purchased an external ZIP drive and this proved
a nice piece of hardware. Almost any computer has a parallel
port and the slowest protocol works (almost) always, so
I created several emergency disks with DOS, appropriate NWOS,
DOS network/disk drivers, patches, utilities, and other stuff
and quite a lot of free space. If everything works OK, a single
bootable floppy (I still keep the 5 1/4" sails, too) gets
me to (N times 100) MB of valuable data.

E-Documents from Seagate/WD on their products we often use
were useful several times, too.

---------

Date: Wed, 14 Jan 1998 18:05:17 +0000
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Vrepair and other emergency repairs, a suggestion

If you're concerned about disk space, just purchase a small IDE hard
drive for the boot drive.  I assume we're all using SCSI devices for
the NetWare stuff.

The advantage here is that you can also load a copy of Windows 3.1x
and Netscape Navigator 4.04 (stand alone version will do).  If you're
caught in a situation where all you need is some internet access, you
can simply dial out with Trumpet WinSock, and download the required
files.

This is especially useful on remote sites.  Nobody can ever mess
with your Windows setup because it's sort of hidden on the server's
boot drive.

---------

Date: Thu, 15 Jan 1998 00:51:00 -0500
From: Israel Forst <iforst@BWAY.NET>
Subject: Re: Vrepair and other emergency repairs, a suggestion

BIG MISTAKE!! I would not reccommend anyone install both IDE and SCSI on
the same machine. I have heard to many stories of people who have done
so and one day they find that the SCSI disk is trashed. In more than one
situation the person viewed the Partition tables of the crashed disks
and it was over written with the IDE partition table. I wouldn't risk it.
I think one can spare 150 MB on a 4 GB disk for a DOS partition.

---------

Date: Wed, 14 Jan 1998 23:59:42 +0000
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Vrepair and other emergency repairs, a suggestion

>BIG MISTAKE!! I would not reccommend anyone install both IDE and
>SCSI on the same machine.

Thanks for the warning, I'll just go for an additional SCSI drive if
I can't spare the disk space.

Personally, I've never run into this problem between IDE and SCSI,
but due to all the recent feedback I've been receiving on this issue,
I can clearly see that it's time to change my mind.

---------

Date: Thu, 15 Jan 1998 09:06:24 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Vrepair and other emergency repairs, a suggestion

Sorry Dave, but I have to disagree with you on this.

It is quite possible to install both IDE and SCSI disks in the same
machine, I'v done it. It isn't suggested, but it can be done.

As far as using it for crash survival, I do the same as Randy does, I
have a spare disk which I use only under those circumstances otherwise
I use purely SCSI.

IDE is easier to install on some occasions then SCSI so the idea has
merit.

---------

Date: Thu, 15 Jan 1998 14:52:07 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Vrepair and other emergency repairs, a suggestion

>There is good reason always to do what Joe D. suggests here, altho I
>can't say that having a C: that is large enough to hold all Joe D.
>suggests is practical on all servers.
>
>I always define my C drive to be around the 100MB limit, which is
>usually well sufficient for most files and patches, but would NOT be
>sufficient for images of system and login as well as ftp files etc.
>
>What I do tho is keep a secondary IDE disk ready which has basics of
>what I need in order to get the system up and running, as well as having
>a mobile tape that is the same as my backup tape. Downtime has been at a
>minumum, but then, a minimum can also be a few hours depending on the
>problem issue.
--------
	There's method in my madness. If we use plain old regular C: then
Novell's update tools could put copies of new files there automatically
when we apply patches and updates. This won't happen if we use a spare
disk drive in a drawer or have it active (yikes, talk about asking for
systems troubles). I have made this suggestion to Novell and shown how
their existing tools are ready to do the job once a C: topology is
selected.
	Until then we can use the COPY facility of Rconsole to move from
NW to DOS the files which are critical. This is NOT a lot of space if
folks would restrain themselves to the essentials (no kitchen sink).
	Joe D.

---------

Date: Thu, 15 Jan 1998 17:00:05 -0500
From: Robert Earl <rearl@IVISOFT.COM>
Subject: Re: Vrepair and other emergency repairs, a suggestion

Joe made some excellent suggestions here.  I'd like to make one more,
based on our experience two days ago (Tuesday).

Have a bootable floppy for each server that has properly configured
client drivers to allow logging in to another server, just in case the
partition that gets trashed isn't the Netware one, but the DOS one
(this happened here).  A zipfile of the server's boot directory would
be darned useful to have on whatever server you can log into, also!

---------

Date: Thu, 15 Jan 1998 15:14:00 -0800
From: Knute Ream <knute@QUAKE.NET>
Subject: Re: Vrepair and other emergency repairs, a suggestion

I may be jumping in the middle of the thread, but an easy solution at our
site for the problem of maintaining a backup copy of the C: drive (DOS
partition) is simply to use a parallel port Zip drive.  For redundancy and
peace of mind, I maintain several duplicate zip disks with the full DOS
partition, in case one goes south.  (Plus manually ensuring that both of
our duplexed/mirrored drives have a perfect mirror of the DOS partition so
that either disk is bootable after swapping the SCSI cabling)

When I had that problem a couple of weeks ago with the BIOS translation
settings on my Adaptec controller (remember me?) this strategy worked like
a charm.  After reformatting the drives, I simply loaded "guest" from a
floppy to assign a drive letter to the zip drive, then xcopy'd the zip
drive contents back to the C: drive.  After everything made it across, I
simply unplug the parallel connector & reboot, and the zipdrive is no
longer part of the system.

I'm sure an extra IDE drive would work, but the parallel Zip drive has
several advantages:

 - easily connected / disconnected without cracking the case
 - easily updated with a current "mirror" of the DOS partition
 - easily allows multiple archive copies of the DOS partition

The only remaining concern I have is related to the shelf life of the Zip
disks, but since I plan on updating them every 6 months (or sooner if
changes are made to the DOS partition) they should always be reasonably
fresh.

---------

Date: Thu, 15 Jan 1998 16:08:57 -0800
From: Anthony Baratta <Anthony@BARATTA.COM>
Subject: Re: Vrepair and other emergency repairs, a suggestion

[ZIP drive approach snipped]

I'd like to give a big thumbs up to this setup, since I use it myself.
But I use Jaz Drives.  I also make sure that I have enough room on my
DOS boot disk to hold 2 or 3 core dumps.  The Jaz drives come in handy
to be able to store multiple core dumps for analysis. They are 1 GB
versus the 120MB of the Zip disks.

I also use Ghost (www.ghostsoft.com) to mirror my partitions between
drives and image dump the partitions to my Jaz drive.

------------------------------

Date: Tue, 27 Jan 1998 13:00:51 -0700
From: "Lyle Bingham" <lbingham@vinca.com>
Subject: Novell to sell StandbyServer for NetWare/intraNetWare

Novell, Vinca Partner to Add Leading High-Availability
Software Solution to Novell Product Line with
StandbyServer for NetWare/intraNetWare
	http://www.novell.com/press/archive/1998/01/pr98004.html

Novell documents on High Availability with StandbyServer for
NetWare/intraNetWare are located at:

	http://www.novell.com/products/clusters/sbs.html

This is StandbyServer for NetWare/intraNetWare sold in Novell
packaging through Novell channels.  First line support will
also come from Novell.

All other Vinca products including StandbyServer Many-to-One for
NetWare, StandbyServer Entry-Level for NetWare, SnapShotServer
for NetWare are available from the Vinca channel:
	http://www.vinca.com/sales/idist.html

------------------------------

Date: Tue, 10 Mar 1998 09:28:00 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Backup Exec and IntraNetware 4.11

>I am having a problem with the speed of backups.  I administer four
>IntraNetware Servers and one NetWare 4.10 server.  I have a IntraNetware
>server dedicated to backup only running Seagate BackupExec  version 7.11d.
>On my main file server,  I have about 8GB of data that gets backed up once
>per week.  Average throughput on all other servers is approx. 22MB per
>min., however when the main server is backed up, throughput decreases to
>approx. 8MB/min.  I have applied all patches to all servers,  searched the
>Seagate BackupExec Web Site, and called Seagate tech Support to no avail.
>The backup server is a Dell OptiPlex XMT33 with 96MB RAM. Here are a few
>settings that were recommended by Seagate and applied to all servers:
>
>Min. Service Processes - 100
>Max Service Processes - 500
>Min. Packet Receive Buffers - 100
>Max Packet Receive Buffers - 500
>Load Spxconfg a=540 v=110 w=1500 r=50 q=1
--------
	Ensure you have the latest SPX patches. They made a huge difference
in performance here, with Backup Exec. I know you said you applied them all,
but a double check (view archives, see those files are really in use on the
server) is worth while. I do no SPX tweaking (spxconf is not used here).
	Then, check the health of the lan adapter on the "main" server. If
it can't take the strain without dropping packets then all is in vain.
	Joe D.

------------------------------

