Anonymous_User Absent Member.
Absent Member.
1166 views

Reattach NSS Volume After Crashed Server

If I have an OES SP2 Linux server where the hard drive has crashed, but a
NSS volume is on another physical disk, how do I reattach that NSS volume
back to a newly installed server?

Labels (2)
0 Likes
5 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Reattach NSS Volume After Crashed Server

On Mon, 02 Apr 2007 17:38:05 +0000, email wrote:

> If I have an OES SP2 Linux server where the hard drive has crashed, but a
> NSS volume is on another physical disk, how do I reattach that NSS volume
> back to a newly installed server?


I think you should just be able to plug it in and then boot the server.
You may even be able to do it live if it's SCSI.
You might need to go into nssmu to select the volume and then choose the
update nds option to properly associate this volume with the new server in
the tree.


--
Mark Robinson
Novell Volunteer SysOp
www.nds8.co.uk
One by one the penguins steal my sanity...

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Reattach NSS Volume After Crashed Server

> On Mon, 02 Apr 2007 17:38:05 +0000, email wrote:
>
> > If I have an OES SP2 Linux server where the hard drive has crashed, but a
> > NSS volume is on another physical disk, how do I reattach that NSS volume
> > back to a newly installed server?

>
> I think you should just be able to plug it in and then boot the server.
> You may even be able to do it live if it's SCSI.
> You might need to go into nssmu to select the volume and then choose the
> update nds option to properly associate this volume with the new server in
> the tree.
>
>
> --
> Mark Robinson
> Novell Volunteer SysOp
> www.nds8.co.uk
> One by one the penguins steal my sanity...
>


What if I have a NSS volume from a NetWare 5.1 or later server? Can I do
the same thing and the meta-data (like trustee rights assignment) still be
retained? Or should I migrate the NSS volume to the new server using the
Server Consolidation and Migration Tool (SCMT)?

I also have read there are disadvantages of placing a NSS volume on a RAID
5 array (like if the controller dies and the vendor no longer makes or
supports the controller, you could potentially not be able to get to the
disk that was attached to the controller). I know, this is what backups are
for, but we all know how reliable those are for servers at remote sites
where tape rotation is placed in the hands of the branch office janitor.
Makes rsync all the more appealing, IMHO.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Reattach NSS Volume After Crashed Server

On Tue, 03 Apr 2007 13:20:34 +0000, email wrote:

>> On Mon, 02 Apr 2007 17:38:05 +0000, email wrote:
>>
>> > If I have an OES SP2 Linux server where the hard drive has crashed,
>> > but a NSS volume is on another physical disk, how do I reattach that
>> > NSS volume back to a newly installed server?

>>
>> I think you should just be able to plug it in and then boot the server.
>> You may even be able to do it live if it's SCSI. You might need to go
>> into nssmu to select the volume and then choose the update nds option to
>> properly associate this volume with the new server in the tree.
>>
>>
>> --
>> Mark Robinson
>> Novell Volunteer SysOp
>> www.nds8.co.uk
>> One by one the penguins steal my sanity...
>>
>>

> What if I have a NSS volume from a NetWare 5.1 or later server? Can I do
> the same thing and the meta-data (like trustee rights assignment) still be
> retained? Or should I migrate the NSS volume to the new server using the
> Server Consolidation and Migration Tool (SCMT)?


Hmm, not sure if it works this far back. I think I might prefer SCMT in
this instance.

> I also have read there are disadvantages of placing a NSS volume on a
> RAID 5 array (like if the controller dies and the vendor no longer makes
> or supports the controller, you could potentially not be able to get to
> the disk that was attached to the controller).


Well, if you get this far, there would be any number of component failures
that would render the box useless. I would reckon that this issue is far
outweighed by the benefits that hardware RAID brings. I always put my
data on HW RAID if I can.

> I know, this is what backups are for, but we all know how reliable those
> are for servers at remote sites where tape rotation is placed in the
> hands of the branch office janitor. Makes rsync all the more appealing,
> IMHO.


I love rsync. You might also want to look at nbackup...

--
Mark Robinson
Novell Volunteer SysOp
www.nds8.co.uk
One by one the penguins steal my sanity...

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Reattach NSS Volume After Crashed Server

> On Tue, 03 Apr 2007 13:20:34 +0000, email wrote:
>
> >> On Mon, 02 Apr 2007 17:38:05 +0000, email wrote:
> >>
> >> > If I have an OES SP2 Linux server where the hard drive has crashed,
> >> > but a NSS volume is on another physical disk, how do I reattach that
> >> > NSS volume back to a newly installed server?
> >>
> >> I think you should just be able to plug it in and then boot the server.
> >> You may even be able to do it live if it's SCSI. You might need to go
> >> into nssmu to select the volume and then choose the update nds option to
> >> properly associate this volume with the new server in the tree.
> >>
> >>
> >> --
> >> Mark Robinson
> >> Novell Volunteer SysOp
> >> www.nds8.co.uk
> >> One by one the penguins steal my sanity...
> >>
> >>

> > What if I have a NSS volume from a NetWare 5.1 or later server? Can I do
> > the same thing and the meta-data (like trustee rights assignment) still be
> > retained? Or should I migrate the NSS volume to the new server using the
> > Server Consolidation and Migration Tool (SCMT)?

>
> Hmm, not sure if it works this far back. I think I might prefer SCMT in
> this instance.
>
> > I also have read there are disadvantages of placing a NSS volume on a
> > RAID 5 array (like if the controller dies and the vendor no longer makes
> > or supports the controller, you could potentially not be able to get to
> > the disk that was attached to the controller).

>
> Well, if you get this far, there would be any number of component failures
> that would render the box useless. I would reckon that this issue is far
> outweighed by the benefits that hardware RAID brings. I always put my
> data on HW RAID if I can.
>
> > I know, this is what backups are for, but we all know how reliable those
> > are for servers at remote sites where tape rotation is placed in the
> > hands of the branch office janitor. Makes rsync all the more appealing,
> > IMHO.

>
> I love rsync. You might also want to look at nbackup...
>
> --
> Mark Robinson
> Novell Volunteer SysOp
> www.nds8.co.uk
> One by one the penguins steal my sanity...
>


Thanks! Yep, I agree with you on all points, but I did have one last question:

My understanding, on a high level, is that you can use SCMT to initiate a
server consolidation in advance of the actual date that the server goes
live, and then right before the server goes live run SCMT again to complete
the consolidation. Is this correct? That's been my understanding of SCMT.

Basically I want to copy the bulk of my data (with trustee rights) to the
new server a week or so before the migration, and then the day before the
server goes live, copy *just* the changes in the data on the source server.
I know there are issues like when a file was deleted during this window you
will still have the file on the target server. But my take on that is I
would rather have data that does not belong on the server (within reason),
than data that does belong on the server but isn't there. Plus I know there
are caveats like file ownership issues that are resolved by LUM-enabling
your users before the migration, not after. All in the docs, of course.

Just looking for ways to reduce the impact the consolidation will have on
my end user population :-)The improvements like being able to monitor the
progress of the consolidation from the server side (vs. client side) are
cool. I wonder what happens if the workstation loses the connection to the
server during the migration. I'm assuming you would get errors and have to
re-initiate the consolidation which isn't that big a deal since the source
server will still be on the wire (and not downed like in the case of a
migration). So many tools/features, so little time to play in the sandbox!


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Reattach NSS Volume After Crashed Server

On Tue, 03 Apr 2007 17:26:13 +0000, email wrote:
> Thanks! Yep, I agree with you on all points, but I did have one last
> question:
>
> My understanding, on a high level, is that you can use SCMT to initiate a
> server consolidation in advance of the actual date that the server goes
> live, and then right before the server goes live run SCMT again to
> complete the consolidation. Is this correct? That's been my understanding
> of SCMT.


Yep, SCMT will do incremental updates of copied data AFAIK.

> Basically I want to copy the bulk of my data (with trustee rights) to
> the new server a week or so before the migration, and then the day
> before the server goes live, copy *just* the changes in the data on the
> source server. I know there are issues like when a file was deleted
> during this window you will still have the file on the target server.
> But my take on that is I would rather have data that does not belong on
> the server (within reason), than data that does belong on the server but
> isn't there. Plus I know there are caveats like file ownership issues
> that are resolved by LUM-enabling your users before the migration, not
> after. All in the docs, of course.


You won't need to LUM enable users unless you are using quotas and other
advanced features of NSS, or want shell based access to the server for
the users. If you just have straight mapped drives with rights set on
files etc then you'll be fine just doing a migration.


--
Mark Robinson
Novell Volunteer SysOp
www.nds8.co.uk
One by one the penguins steal my sanity...

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.