Restoring NDS server object after backup
grevans
Our backup product has a problem restoring the server object to the NDS
tree. When calling the system function NWDSRestoreObject() it returns
error -628. This means "Attempted to add an object without specifying the
object's base class".
When using the Novell backup and restore product, on restore we get the
following error reported:
Restoring data set: .CN=DELL4.O=BakBone.T=OAK.
NWSMTSWriteDataSet
Error: Object class violation.
The object in question is the same as that causing the error with our
backup product. We get this error with NW6.0 SP5e, but not with NW6.0 with
no service packs.
Is this a known issue? Is there a solution? I have searched the Novell
website but found nothing useful.
David Mair
The actual NetWare versions shouldn't make a difference, only the DS
versions. OTOH, there's no reason to imagine that DS changed the NDAP
feature that supports backup this way so then it must be a change in
NWDSRestoreObject(). Just in case, is the tree your restoring into a
freshly created tree for the purposes? If so then your archive server
object may depend on schema that is not yet present. The SMS code
probably uses the lower level DClient services but they are not
practically different from the NWDS services, so the cause is probably
the same for both cases.
Roger Thomas, DevNet SysOp 22
environment and Auxiliary classes are attached to an object.
Does this match your environment?
Roger Thomas, DevNet SysOp 22
"grevans" <gar...@bakbone.co.uk> wrote in message news:VHn7f.5191$5e6....@prv-forum2.provo.novell.com...
grevans
stand alone box purely for testing purposes with no real operational data
on it. We then reproduced it on our development box, but only after we
upgraded to SP5e. This box is a bit older and has had various things done
to it to reproduce problems in the past, but remains a fundamentally
clean, stand-alone box with no extraneous software added.
The object in question is the object representing the server itself.
Hardly an auxiliary class. We have also not installed any software that
might have added additional classes to any object. Lastly, we are
restoring immediately after backing up, with no changes at all to the NDS
tree, so any auxiliary classes should already be present.
To make it even clearer, what I believe the tester did was:
Install from scratch NW 6.0.
Add SP5.
Do a full system backup.
Install from scratch NW 6.0, using all the same names.
Add SP5.
Restore the NDS tree - encountered error.
What we did to reproduce was:
Add SP5e to our NW 6.0 box.
Backup NDS tree.
Restore NDS tree - encountered error.
Backup NDS tree using SMS.
Restore NDS tree using SMS - encountered error.
Any help would be much appreciated.
grevans
Please see my reply to Roger Thomas' reply which describes exactly what we
are doing to reproduce the problem.
David Mair
have attributes that depend on schema not present at restore, e.g. it
may _have_ auxilliary classes (or any number of other schema dependencies).
David Mair
appears to have happened across a service pack change you should
probably report the problem to Novell Support.
However, there are several other issues. Single object restore can't
restore NCP server objects safely. The private key on the server is
associated with a DS object with a unique name that cannot be re-created
by a single object restore. IOW, restore of a NCP server object is
unlikely to cause the "expected" result (the expectation is the problem,
not the result). The proper way to create NCP server objects is to
install the server into a tree, this creates a NCP server object and a
key-pair at the same time.
System restore using file system backup semantics on the directory is
not going to function. FWIW, backup is something I am passionate about
and I have the luxury of having worked on NSS, SMS and directory
services components at Novell. Until working on the directory services
team I would have assumed directory backup could be like file system
backup but it can't work that way.
Please, contact support about the bug and, if it helps, we can talk
privately about system archive methods.
grevans
Thanks for your reply, and sorry mine took so long.
This code was originally written by another guy based on the Novell
documentation. The backup walks the NDS tree calling NWDSBackupObject() on
each object, writing the data to a temporary file and then writing that
data to tape. On restore we walk the same set of objects in the same order
and read data from tape to a temporary file and then call
NWDSRestoreObject() to restore the object. From the names of the functions
and the documentation it looks like this is/was exactly the right thing to
do, but I appreciate that the way NDS works may have changed since this
API was originally invented. It is however odd that SMS also suffers an
error in this scenario. I will be contacting Support about this issue.
It looks like I may now be inheriting all this work. As you say "backup is
something I am passionate about and I have the luxury of having worked on
NSS, SMS and directory services components at Novell" and "we can talk
privately about system archive methods" I would love the opportunity to
pick your brains and garner any advice you may have. As you didn't give a
private/direct email address, please could you contact me at
Alastair.Growcott_AT_bakbone.co.uk.
Many thanks,
Alastair Growcott.
David Mair wrote:
> There are a few things that need to be considered here. Since the change
> appears to have happened across a service pack change you should
> probably report the problem to Novell Support.
> However, there are several other issues. Single object restore can't
> restore NCP server objects safely. The private key on the server is
> associated with a DS object with a unique name that cannot be re-created
> by a single object restore. IOW, restore of a NCP server object is
> unlikely to cause the "expected" result (the expectation is the problem,
> not the result). The proper way to create NCP server objects is to
> install the server into a tree, this creates a NCP server object and a
> key-pair at the same time.
> System restore using file system backup semantics on the directory is
> not going to function. FWIW, backup is something I am passionate about
> and I have the luxury of having worked on NSS, SMS and directory
> services components at Novell. Until working on the directory services
> team I would have assumed directory backup could be like file system
> backup but it can't work that way.
> Please, contact support about the bug and, if it helps, we can talk
> privately about system archive methods.
> >
David Mair
grevans wrote:
> Hi, David.
>
> Thanks for your reply, and sorry mine took so long.
NP, I've been busy too all week ;-)
> This code was originally written by another guy based on the Novell
> documentation. The backup walks the NDS tree calling NWDSBackupObject() on
> each object, writing the data to a temporary file and then writing that
> data to tape. On restore we walk the same set of objects in the same order
> and read data from tape to a temporary file and then call
> NWDSRestoreObject() to restore the object. From the names of the functions
> and the documentation it looks like this is/was exactly the right thing to
> do, but I appreciate that the way NDS works may have changed since this
> API was originally invented. It is however odd that SMS also suffers an
> error in this scenario. I will be contacting Support about this issue.
The backup/restore APIs in the NDK reflect what might be considered
naivity. At the time these APIs were first declared there was no real
idea of what directories would be and file system semantics seemed like
a good fit. Time has demonstrated that this is not the case at all and
directory backup can't be handled as in a file system. For that reason
I'd consider the NWDS backup/restore object APIs to be obsolete and look
for an alternative solution.
> It looks like I may now be inheriting all this work. As you say "backup is
> something I am passionate about and I have the luxury of having worked on
> NSS, SMS and directory services components at Novell" and "we can talk
> privately about system archive methods" I would love the opportunity to
> pick your brains and garner any advice you may have. As you didn't give a
> private/direct email address, please could you contact me at
> Alastair.Growcott_AT_bakbone.co.uk.
You can reach me at the novell dot com domain and my mailbox name is
dmair. I'm sending you a message now.