NSS Volumes

[klin8251]

Any chance that Veeam will add support for file level restore from NSS volumes?

[Gostev]

Hello Peter. We do not have plans on adding NSS support to our multi-OS file level restore engined, as there were very few requests and it is a dying platform. More importantly though, there are licensing barriers (using NSS on Linux requires purchasing OES license, so we cannot include NSS support in the file level restore appliance we are distributing).

However, our SureBackup technology coming in v5 will allow you do perform file level recoveries from Novell servers backups, but the procedure will be different. Basically, you will be able to instantly power-on your server from backup in an isolated environment, and then just logon to the server and copy some files from running server as you normally do that in the production environment.

[klin8251]

Thank-you for that clarification.

[spgsit5upport]

However, our SureBackup technology coming in v5 will allow you do perform file level recoveries from Novell servers backups, but the procedure will be different. Basically, you will be able to instantly power-on your server from backup in an isolated environment, and then just logon to the server and copy some files from running server as you normally do that in the production environment.

ONLY if it happens that the server will have replica, mounting NSS volume & using something like Portlock Explorer would be much easier & more logical option

Seb

[tjohnsonlcsd]

Does this NSS support statement apply to NSS on Linux as well or only the Netware platform?

We have NSS volumes on Linux OES2 server and I was under the impression that I could do a file level restore of NSS volumes on vdisks or pRDMs because the volumes are able to be natively accessed on Linux by the root user. NSS permissions would not be restored bu the data should be able to be restored.

I do not have a lab environment setup to test, anyone have an idea if this would work?

[spgsit5upport]

NSS volumes can NOT natively be accessed on Linux UNLESS it is OES 2 with NSS support

So restore will now work (same as if it was NetWare NSS pool/volume - the format is the same)

Seb

[tjohnsonlcsd]

Right so I backup a linux/OES2 VM with a vdisk say /dev/sdb with an NSS volume on it and I do a file level restore and the VM open up in VMPlayer? I look at my devices and I would not be able to read /dev/sdb? My alternative would be to restore the Vm to a restore server and then copy my data?

Like I said we recently purchased and I do not have a test environment setup and my eval just expired so I cannot try this theory.

[spgsit5upport]

Correct, you would not be able to restore. You can restore the whole VM & copy the data, as it is OEM2 Linux you can login with root (if it was NetWare one would need eDir replica to be able to login)
But in that case if you have a backup to tape solution (ie Arcserve) it is easier to make the backup of NSS data via agent inside the VM

Seb

[tjohnsonlcsd]

Thanks, any chance that NSS on Linux will be supported down the road or is it a licensing issue? I know NSS is a small part of the file system pie but it is a very versatile file system and provides some great access controls.

I suppose also that a POSIX system on a Linux/OES2 system presented as an NCP share would be able to use file level restore since it would be ext2, ext3, reiserFS, XFS, etc. underneath.

Thanks again.

[spgsit5upport]

The first part was replied to by Neeam and sadly they have no plans to support it (why?)

The second one = yes, you can, but probably rights would be stripped

Seb

[klin8251]

I wonder if we could submit as a feature request. I bet there are still many people out there that would be interested in the addition of this feature.

[Gostev]

ONLY if it happens that the server will have replica, mounting NSS volume & using something like Portlock Explorer would be much easier & more logical option

No, you will not needed a replica for this. SureBackup engine allows to power on any VM directly from a compressed backup file. You will also be able to mount any VMDK from a backup file to any other VM (including Windows server with special tools like Portlock Explorer) - without having to extract VMDK first.

[jasonsfa98]

"We do not have plans on adding NSS support to our multi-OS file level restore engined, as there were very few requests and it is dying (pretty much dead platform)."

That was over a year ago and they are still selling their OES products to run on Linux.

[Vitaliy S.]

Jason, you can perform file level recovery from NSS volumes by using Instant Recovery feature. More details in our F.A.Q.topic. Thanks.

[jasonsfa98]

Should I ignore the warnings from Veeam about instantly recovering a VM that is still running?

[Gostev]

Yes, because you are not going to actually start the VM.

[jasonsfa98]

This is a real hack job of a restore solution. I wish my sales guy would have told me this was the case when I told him my primary concern was backing up my Suse Linux boxes running OES.
I switched to Veeam from ZManda, which had no problem backing up NSS volumes with sTar. I moved away because it was slow and had no real VMWare integration that worked well.

Now I've forked over $3,500 and cannot even restore files in a timely manner for my users. This is really frustrating.

[Gostev]

cannot even restore files in a timely manner for my users

It should not be taking longer than 2 minutes? VM publication is nearly instant (less than a minute), and then you just add published VMDK to any Suse box and get files from it. In fact, Multi-OS FLR wizard works in exactly same way, except that VMDKs are automatically added to specially crafted Linux appliance that automatically boots up.

[tjohnsonlcsd]

jasonfsa98,

We are an OES shop as well and I think that the time factor in restoring via Veeam or an agent based solution are about the same, at least in our case. Not having to install an agent on our VMs and the reduction in the backup window makes up for that in our case. The problem is restoring rights which AFAIK cannot be done with Veeam.

I originally had the same reaction to the lack of support for NSS but I do understand the license restrictions and the solution does work well, with the exception of rights restoration I mentioned.

Tim

[jasonsfa98]

The FAQ leaves out a lot of information needed in order to pull off this hack. You can't restore a VM running SLES/OES2 and just fire it up along side other servers running eDirectory. Not only are there name conflict issues but eDirectory will freak out if another server using the same name tries to communicate over the network. You have to jump through a ton of hoops to get to your data since Veeam hasn't added NSS support. I'll post my findings here in case some other poor soul needs help.

- Use instant recovery to restore the VM but give it a temporary name that differs from the VM that is in production
- Associate the NIC to an isolated network so that it cannot see or talk to other SLES/OES2 servers. This is very important.
- Power on the restored VM
- Use Yast to make sure your NIC from the restored VM is active and double-check with 'ifconfig'. If eth0 or eth1 is not active with an IP add one. eDirectory/NSS will not start without an IP.
- Modify /etc/opt/novell/eDirectory/conf/nds.conf and make sure all the IP listings point to this restored VM
- Modify /etc/nam.conf and make sure 'preferred-server' is pointed to the IP on this restored VM. DNS will not work.
- Reboot
- You should be able to see your NSS volumes under /media/nss/[volume] assuming you used the default paths during installation.

Hope this helps.

[Gostev]

The FAQ leaves out a lot of information needed in order to pull off this hack.

It provides the exact process, step by step... you are just doing something very different, and completely unrelated to what is explained there

You can't restore a VM running SLES/OES2 and just fire it up along side other servers running eDirectory

The instantly recovered VM should never be powered on, so all the steps you have listed above are not required.

Quote from FAQ (emphasis added):

leverage Instant VM Recovery functionality to publish VMDK from backup on vPower NFS datastore (without actually starting the VM)

[tsightler]

- Use instant recovery to restore the VM but give it a temporary name that differs from the VM that is in production
- Associate the NIC to an isolated network so that it cannot see or talk to other SLES/OES2 servers. This is very important.
- Power on the restored VM
- Use Yast to make sure your NIC from the restored VM is active and double-check with 'ifconfig'. If eth0 or eth1 is not active with an IP add one. eDirectory/NSS will not start without an IP.
- Modify /etc/opt/novell/eDirectory/conf/nds.conf and make sure all the IP listings point to this restored VM
- Modify /etc/nam.conf and make sure 'preferred-server' is pointed to the IP on this restored VM. DNS will not work.
- Reboot
- You should be able to see your NSS volumes under /media/nss/[volume] assuming you used the default paths during installation.

I think you might not be performing the procedure exactly the way the FAQ intended. It appears from your steps above that you are actually performing an instant recovery and powering on the VM. The normal procedure for doing this would be to perform an Instant Recovery, but leave the instantly recovered VM powered off. You would then use vCenter to detach the VMDK which contain your NSS volumes from the powered off instantly recovered VM, and attach them to a running production server that can mount them. Then copy the files with the native tools of your choosing, umount the NSS volume from the running server, remove the "instantly recovered" VMDK from the production environment, and then kill the instant recovery. In this scenario you would never power on the actual instant recovery VM.

[jasonsfa98]

More assumptions on both ends...

More specifics on my setup:
1. My NSS volume is made up of 3 virtual disks that are connected via RDM. Each one is 256GB in size and one is added every time we need more space.
2. I have 4 SLES/OES2 servers and each one uses the same volume/pool naming scheme, "DATA"
3. I was hesitant to try and attach 3 VMDK files to an already running SLES/OES2 VM and hope that there were no conflicts on the production server

I think your FAQ instructions would work well for a single VMDK for an NSS volume that didn't share a naming scheme with other servers. Perhaps it would work just fine but I wasn't willing to risk it. Either way, if you supported NSS we wouldn't be talking

[spgsit5upport]

I would be reluctant to attach the vmdk to another live machine

Also often it is not possible to attach it, as the vmdk migh live (like in my case) on a medium accessible to the Veeam backup server, but definitely NOT accessible to VC and/or the actual VMs

Still it is easier to use the backup vmdk & attach it to a VM that is booted with Portlock (another license!) & restore the data this way.

But it is far cry from what it should be, rights are not restored & depending how much needs restoring it could be problematic & time consuming

Seb

[jasonsfa98]

It was VERY time-consuming. So much that I am looking for another backup solution- which is unfortunate because I really like Veeam's reliability and speed. I just can't keep using a backup solution that fails (for me) at it's most crucial job, restoring data.

[Gostev]

Jason, thank you for your kind words. In that case, I would recommend looking at a file-level backup solutions for your SLES/OES2 servers. As far as image-level backup solution, I only know few which support file level recovery from image-level backup, and no one of them (except us, through vPower workaround) supports FLR from NSS. We would love to add NSS support to our Multi-OS FLR wizard (which already supports as many as 15 file systems), but as I have already explained earlier, there are OES licensing barriers for that.

[spgsit5upport]

Just for fun decided to check new FLR in v6

Chose one of my NetWare VM (that has Novell NSS Sys volume, nothing else)

At the end of the wizard, when it looks like it all goes beautifully, I get:

Cannot mount sda2: "Unknown filesystem"

Which is correct, the tiny Linux appliance does not know anything about NSS, so how would it be able to restore anything?

I just do not see it working, am I missing something?

Seb

[tfloor]

Just for fun decided to check new FLR in v6

Chose one of my NetWare VM (that has Novell NSS Sys volume, nothing else)

At the end of the wizard, when it looks like it all goes beautifully, I get:

Cannot mount sda2: "Unknown filesystem"

Which is correct, the tiny Linux appliance does not know anything about NSS, so how would it be able to restore anything?

I just do not see it working, am I missing something?

Seb

FLR does not support nss volumes, as described earlier in this post. Read this post or the FAQ for further information.

[tfloor]

That's why I use backup exec file level with agent to backup the files.
There is also something like port lock explorer but I don't understand that software. Looks like its a difficult suite. I was hoping on a windows tool that was able to read the nss vmdk files to extract files like winrar. But never found something like that.

[spgsit5upport]

Portlock works fine (not difficult by any means!)

http://forums.novell.com/novell/novell- ... lumes.html

Ofcourse file level backup inside VM (as it would be in physical server) works fine, but that is NOT the point here!

Seb