we are facing some strange NSS issues, and now it seems,
that ArcServe 9 is not working smoothly as well:
We do full backups only with a full compare tape to disk.
Everything is operating normaly, at least the AS log files
tell this.
Just right now I wanted to restore a single, really not
important file from tape and receive that error message!
The CA knowledge base has some few TIDs telling about
problems with AS6.6 and older, to solve e.g. the tapes
should be erased prior backup. (All tapes are formatted
with AS9 at least once)
NW6sp2+nss3a
AS9 + all patches
ADPTU160M.HAM (SP3 Unsupp.Drv) + Tandberg SLR 60
How reliable are the result messeges of ArcServe, *if*
stating that backup and compare to disk were successfuly completed?
Can I trust, that this is just an anoying, but solvable issue,
I mean: is it verified that way, that it is prove, the data
are on the tape and somehow it will be possible to restore
them, in the case *importand* data was erased or corrupted?
Regards, Rudi.
Rudolf Thilo
GaPo GmbH
Am Zollwasen 6
D-97353 Wiesentheid
Rudolf Thilo wrote:
>
> Just right now I wanted to restore a single, really not
> important file from tape and receive that error message!
>
> The CA knowledge base has some few TIDs telling about
> problems with AS6.6 and older, to solve e.g. the tapes
> should be erased prior backup. (All tapes are formatted
> with AS9 at least once)
Formatting isn't sufficient. Have the tapes been used with earlier
versions of Arcserve or not? If yes, they absolutely have to be *erased*
fully at least once.
>
> Can I trust, that this is just an anoying, but solvable issue,
No. In my experience you can't do anything with that data.
> I mean: is it verified that way, that it is prove, the data
> are on the tape and somehow it will be possible to restore
> them, in the case *importand* data was erased or corrupted?
I guess it can from a data recovery company. But not using Arcserve. And
I agree that this is an almost unaccepatble flaw (if yours is indeed the
tape format issue).
CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
Your problem is resolved ?
I have the same problem in many site but in NWFS volumes.
I have found the temporary solution to exclude (not by filters) all files in
the root of each volumes (??)
Regards,
Romano
> Hi,
>
> Your problem is resolved ?
Yes. The way Massimo mentioned. That is (at least on that machine) a after
business hours job: That full erase seems to consume all CPU time it can get.
Regular backups don't do that: They can run without problems even during peak
hours.
Rudi.
Rudolf Thilo wrote:
>
> Romano Banchieri wrote:
>
> > Hi,
> >
> > Your problem is resolved ?
>
> Yes. The way Massimo mentioned. That is (at least on that machine) a after
> business hours job: That full erase seems to consume all CPU time it can get.
Load dosfat.nss.
CU,
--
Massimo Rosen
Novell Support Connection Sysop
> Hi,
>
> Rudolf Thilo wrote:
> >
> > Romano Banchieri wrote:
> >
> > > Hi,
> > >
> > > Your problem is resolved ?
> >
> > Yes. The way Massimo mentioned. That is (at least on that machine) a after
> > business hours job: That full erase seems to consume all CPU time it can get.
>
> Load dosfat.nss.
???
Loading dosfat.nss solves that utilisation problem?? AFAIK dosfat.nss just
supplies protected mode access to the DOS FS of a server. How does this
interact with a full tape erase by Arcserve's tapeserver?
Thanks, Rudi.
[AS9 Full Tape Erase eat's up all CPU Time]
> > Load dosfat.nss.
>
> ???
>
> Loading dosfat.nss solves that utilisation problem?? AFAIK dosfat.nss just
> supplies protected mode access to the DOS FS of a server. How does this
> interact with a full tape erase by Arcserve's tapeserver?
Can you please drop a line upon dosfat.nss and that util phenomenon?
> Thanks, Rudi.
Rudolf Thilo wrote:
>
> Massimo Rosen wrote:
>
> > Hi,
> >
> > Rudolf Thilo wrote:
> > >
> > > Romano Banchieri wrote:
> > >
> > > > Hi,
> > > >
> > > > Your problem is resolved ?
> > >
> > > Yes. The way Massimo mentioned. That is (at least on that machine) a after
> > > business hours job: That full erase seems to consume all CPU time it can get.
> >
> > Load dosfat.nss.
>
> ???
>
> Loading dosfat.nss solves that utilisation problem??
Yes.
> AFAIK dosfat.nss just
> supplies protected mode access to the DOS FS of a server.
Exactly. And exactly that solves the high utilization.
> How does this
> interact with a full tape erase by Arcserve's tapeserver?
In that the server will be at all able to go to the dos partition during
the tape erase, which it has to do regularily to write out the CDBE
database (the server registry). Without dosfat.nss loaded, the server
has to wait before it can switch to real mode until the SCSI protected
mode command to erase the tape is finished. While it waits for that, the
server will spike to 100%, and in worst cases become completely
unresponsive.
> Hi,
>
> Rudolf Thilo wrote:
> >
> > Massimo Rosen wrote:
> >
> > > Hi,
> > >
> > > Rudolf Thilo wrote:
> > > >
> > > > Romano Banchieri wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Your problem is resolved ?
> > > >
> > > > Yes. The way Massimo mentioned. That is (at least on that machine) a after
> > > > business hours job: That full erase seems to consume all CPU time it can
> > > > get.
> > >
> > > Load dosfat.nss.
> >
> > ???
> >
> > Loading dosfat.nss solves that utilisation problem??
>
> Yes.
>
> > AFAIK dosfat.nss just
> > supplies protected mode access to the DOS FS of a server.
>
> Exactly. And exactly that solves the high utilization.
>
> > How does this
> > interact with a full tape erase by Arcserve's tapeserver?
>
> In that the server will be at all able to go to the dos partition during
> the tape erase, which it has to do regularily to write out the CDBE
> database
A ArServe full tape erase needs frequent updates to the CDBE? What for?
Thanks, Rudi.
Rudolf Thilo wrote:
>
> A ArServe full tape erase needs frequent updates to the CDBE? What for?
No. The server does that all the time, it has absolutely nothing to do
with Arcserve. But the the tape erase is just one single SCSI command,
and the server can no longer access DOS (aka the CDBE without dosfat)
until that SCSI command is finished.