Article

khurni's picture
article
Reads:

8296

Score:
5
5
1
 
Comments:

15

Caveats when using Symantec NetBackup 6.5.x with Novell OES2 SP1 Linux

Author Info

22 July 2009 - 4:01pm
Submitted by: khurni

Author Blog
Author Profile

Tags

Tags Map

(View Disclaimer)

If you are thinking about Enterprise backup solutions when implementing Novell OES2 SP1 Linux, please be aware of the following regarding Symantec NetBackup v6.5.x (formerly known as Veritas NetBackup).

  1. NSS volumes on OES2 SP1 Linux are supported with NBU 6.5.1 using the Linux Agent (the SLES agent)
  2. You need to make sure to edit your /etc/opt/novell/nss/nssstart.cfg file (or use nsscon) to have the following two settings:
    /ListXattrNWmetadata
	/CtimeIsMetadataModTime
  3. Symantec has a bug where your backup jobs will be marked as “failed” because it does not exclude the mount point of /opt/novell/nss/mnt/.pools However, even if you are able to create the exclude mount point file and put that exclusion list in, NBU does not read this file properly. Unfortunately the fix is a binary level patch from Symantec (specific to each version of the agent, 6.5.2, 6.5.3, 6.5.4, etc.) This patch can only be obtained from Symantec. They were supposed to include this in 6.5.4 and have not. The latest we have heard is that Symantec “may” include this in 6.5.7 or 7.0 of the NBU product. You may have to refer to case #320-151-041 to get the patch.
  4. If you use Compression on your NSS volumes, NBU will decompress the files every time they are backed up. This is because NBU does not use ANY TSA code from Novell at all. Only Linux APIs. You will need to buy more disks. This means you also will have problems with the following
  5. You cannot backup your GroupWise data because NBU won’t use TSAFS /enableGW=yes, or TSAFSGW. Your only choice will be to double your drive space in your entire Enterprise for your GroupWise data and spend the time to use dbcopy to copy the data to a secondary storage volume and then use NBU to back up the copy. Or switch to MS Exchange or another backup product.
  6. Also, if you use iFolder, this means you cannot use TSAIFS to properly backup iFolder either.
  7. Beginning in NBU v6.5.2 (server-side, not agent side), Symantec introduced a bug where a TIR (True Image Restore) option will cause any differential (or incremental) backups on any platform (We tested on NetWare, SLES 10 SP2/OES2 SP1, and Sun Solaris) to take about 5x longer than previous backups. Symantec was supposed to have fixed this in 6.5.4, but our testing says it’s not fixed. The only workaround is to not use TIR (turn off the option).
  8. The only good thing about item #4 (not using any TSA code) is that you can now utilize Synthetic backups and checkpoint restarts on your OES2 servers.

If you are already a Symantec NBU customer with NetWare and are thinking about converting to OES2 SP1 Linux, please let Novell and Symantec know that the above items should be addressed in a timely matter.


Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.



Related Articles


User Comments

vsayfullin's picture

Very interesting

Submitted by vsayfullin on 22 July 2009 - 10:44pm.

Thank you for information. Very usefull, especially this: "Symantec introduced a bug where a TIR (True Image Restore) option will cause any differential (or incremental) backups on any platform (We tested on NetWare, SLES 10 SP2/OES2 SP1, and Sun Solaris) to take about 5x longer than previous backups."

My opinnion is that Symantec is not backup solution for Novell and mixed networks. Many my customer has big-big trouble with NBU.

Do you have similar tests for other backup solutions? For example Syncsort Backup Express 3.1?

WBR,
Vitaliy Sayfullin

khurni's picture

It's ironic that you should

Submitted by khurni on 23 July 2009 - 10:51am.

It's ironic that you should mention SyncSort BEX. We used to use that product 3-4 years ago and got rid of it because of many issues. Most notably:

1) It would repeatedly abend our cluster nodes. We know this isn't a LAN issue because the minute we switched to NBU the problem went away. We had multiple cases open with Novell and SyncSort (some for more than a year) and never got resolution.

2) SyncSort BEX (to my knowledge) still does not properly backup sparse files on Unix/Linux/Solaris platforms. The only option is to purchase a several hundred thousand dollar "image" option to backup the sparse files. However, even with the expensive image option, it doesn't properly restore the sparse files because it's image-based, not file based. It's possible this has been fixed, but as of 2 years ago at Brainshare, I was told this was not going to be addressed outside of the use of the Image option.

I have heard good things about SEP/Sesam, but have not used it, let alone in an Enterprise mode to backup 100+ Solaris, 100+ Windows 2000/2003/2008, and 60+ NetWare/OES2 servers to a Tekstorage tape library (I think now owned by Sun?).

We also looked at Commvault, but they refused to provide us with an evaluation copy before purchase, even though we told them it would cost them the sale. Perhaps after losing a possible $250,000 sale they have changed their mind since then?

ta's picture

NSS backup problems ... again

Submitted by ta on 1 August 2009 - 12:41am.

6 or 7 years ago. We have a lot of problems with backups of NSS volumes.
We switch from ArcServe, to BackupExec, to Netbackup.
With the latest we still had some issues but has the most stable.
For what you are telling me the problems are back.
Then I think the problems were related with TSA.

If Netbackup is not using TSA how can it be a certified backup solution for OES?
What other implications does it have (besides GroupWise, iFolder, that you mention) if it is not using TSA? Does it backup Directory Quotas, User Quotas, Extended attributes?

Thanks in advanced, TA.

kjhurni's picture

I've inquired to Novell

Submitted by kjhurni on 4 August 2009 - 7:27am.

I've inquired to Novell about removing the "certified" for OES2 for NetBackup but I don't think I'll have much success. I mean, technically it'll work, just so long as you don't use GroupWise, iFolder, or NSS Compression. You know, nothing major.

I'm not on an expert on the NSS stuff, but it's using the NSS NWMetaData attribute, I think, so that should cover the extended attributes. I know that covers the trustees, but I don't know if it covers directory quotas, user quotas, or the other extended attributes (I'll have to test and find out). IF Novell puts/stores those items in that nss /ListNWMetadata. But I don't know for sure.

jffgrnfld's picture

Symantec works, with caveats

Submitted by jffgrnfld on 4 August 2009 - 6:59am.

We run NetBackup on our OES2 SP1 servers and it protects the data appropriately. I have counter experience with point #3. While the details of the job show a warning that it couldn't cd into that directory, the job is still labeled successful with no failures (warnings are not failures).

Adding the NSS flags in step #2 allows for the full protection of the NSS filesystem, including directory quotas, user quotas, extended attributes, etc. The only side-effect that I've seen is that the "/CtimeIsMetadataModTime" setting doesn't allow me to see the file create timestamp from the command-line anymore. This would change the behavior of Dynamic Storage Technology (DST) to look at ctime as essentially the last time the file was backed up (archive bit reset) instead of the create time of the file. If you want to use DST and desire the use of create time in your DST move job, you're going to have a conflict.

The Groupwise backup issue is indeed a problem. We've added GWAVA Reload to our portfolio in order to handle these backups.

I'd say that while there are issues with NetBackup and Novell, it is not unlike most other products with their challenges as well.

bsix's picture

It's all about proper testing before purchase

Submitted by bsix on 13 August 2009 - 11:18am.

It's unfortunate that backup vendors don't use the cool tools provided by Novell to make their lives easier. The TSA's do all the work so why make it harder. For example, the TSA can report back all the files that have changed since the last backup vs scanning every single file looking for an archive bit. Before selecting a backup vendor, do the homework necessary for the task. Do a pilot/POC. Vendors such as SEP welcome this and it should be considered. Then, find out who measures up and dump the others.
Let's not forget why we love NSS in the first place and why hands down NSS is the best file system for user data. It has salvage, tons of file system attributes, dynamic inheritance, directory integration, compression, purge with no recovery, cluster awareness, and others. If backup vendors can't figure out that those features are important to us and support US vs themselves then we dump them for someone who cares.

tobo's picture

It is supported

Submitted by tobo on 11 February 2010 - 6:01am.

Hi,
I'm not a fan of NetBackup, but I do have a couple environments with that Product - so I have to deal with it.

GroupWise actually is supported for Backups, please have a look at:
http://seer.support.veritas.com/docs/271459.htm

So after that modification, NetBackup is aware and does a consistent backup.

skapanen's picture

we backup many OES2 fileservers with Netbackup

Submitted by skapanen on 11 February 2010 - 11:49pm.

Hi,

thanks for that Groupwise / TSA link, have to read that one..

Currently we backup many OES2SP1 fileservers with NBU6.5, no issues with mount points or compression. We use basic linux agent with metadata switches on NSS, no TSA. Works just fine.

Groupwise will be moving to OES2@NSS later this year.. that maybe interesting.

-sk

kjhurni's picture

Thanks for the update

Submitted by kjhurni on 11 February 2010 - 11:21am.

The latest article:
http://seer.entsupport.symantec.com/docs/305788.htm
explains it better and basically you are still forced to use a legacy (soon to be non-supported) NetWare server in order to fully protect yourself.

Given Symantec's lack of "enthusiasm" for adding/fixing the issues (all they have to do is use the TSA API's that Novell has already provided them in a Linux client), I don't see anything being resolved any time soon (especially since the above URL references NBU 7 which is yet to be shipped).

So if you're not opposed to having to backup TB of data through one NetWare server (can you say bottleneck) that's going to be EOL in 2 months . . .

Also one thing they don't mention that we just found out is that you CANNOT backup data on NSS on NetWare via their NetWare client and restore it successfully to an NSS volume on OES2 with the Linux client. Symantec does not support multi-platform backup/restores like other vendors do.

jffgrnfld's picture

Backup on NetWare / Restore on OES2 Linux

Submitted by jffgrnfld on 11 February 2010 - 11:52am.

It's not surprising that you cannot restore files via the Linux client that have been backed up with the NetWare client. Given the extra metadata included in files stored on an NSS volume, and the fact that this metadata is backed up differently via the TSA (Netware) and the posix extra attributes (Linux) these formats are incompatible.

I do agree with the assessment that it's unfortunate that Symantec refuses to use the TSA APIs, but can understand the decision, and it a lot of respects - when Novell chose to go down the linux route, they need to fully embrace the fact that some vendors aren't going to cater to their specialty cases and continue to write hooks for their low-marketshare APIs.

For our current situation - we have a different backup solution (GWAVA) for Groupwise than for everything else. This is a very unfortunate high additional cost in order to backup Groupwise, but I keep reminding myself that special connectors for Exchange, SQL Server, etc. are also an additional cost to backup, and Groupwise is more than just a bunch of files on a fileserver. So - an additional cost is in some respects justified.

tobo's picture

correct

Submitted by tobo on 11 February 2010 - 12:40pm.

You are right - it's actually not possible with NetBackup to restore to an OES Linux if you got them from a NetWare Server.
I also agree with you, that the effort Symantec has in Novell Product Support is very poor. Also with the smaller BackupExec Version.

I don't know about other Vendors, but I do know about SEP Sesam (http://www.sep.de/) - it does support Backup's from NetWare NSS and Restore to OES Linux NSS Volumes. It also supports GroupWise on Linux, also a clean eDirectory Backup.

kjhurni's picture

It may work

Submitted by kjhurni on 12 February 2010 - 7:25am.

So far we haven't had any issues backing up groupwise without the TSA

Note that I HAVE done a restore and not had any errors.

However, technically there's the possibility of an inconsistent database via this method although Linux doesn't care about file locking at all (under normal circumstances)

If we do run into problems I'll have to use dbcopy but I have some very large post offices and am low on disk space (I don't think I have a spare 1 TB of drive space laying around to do a full dbcopy for a full backup).

sigh

nm75's picture

NetBackup 6.5.x on SLES 11 or 10?

Submitted by nm75 on 27 September 2010 - 10:11am.

Hi,

Has anyone seen any issues (in particular file system corruption) with NetBackup 6.5 running on plain SLES 10 or 11? (no OES 2)

We have experienced data corruption (apparently upon reboot) on Masters NetBackup servers running on SLES. The file systems were XFS, and ext3 running on SAN with multipathing enabled.

TIA

kjhurni's picture

Not yet, but we're on Solaris

Submitted by kjhurni on 27 September 2010 - 11:37am.

Our NBU Master server is on Sun Solaris (not sure which file system they're using--ZFS maybe). All our media servers are Sun Solaris as well. Everything else (client) is NetWare, SLES 10 SP2/SP3, SLES 11, Windows 2003/2008.

But NBU has tons of bugs (we're going on 2 years now waiting for a fix still) but Symantec is just a big slow behemoth.

nm75's picture

File system corruption was due to lvm/multipath misconfiguration

Submitted by nm75 on 14 October 2010 - 6:02am.

Thanks for your response. FYI after further investigation, it was determined that the cause of the file system corruption was most likely due to incorrect lvm filter (they were using the default lvm filter which reads the raw devices) and user friendly names being used. (See Novell TID (7001133) Recommendations for the usage of user_friendly_names in multipath configurations.)

After turning off user friendly names and changing lvm filter we tested rebooting for over 35 times (made storage changes in the process) and experience NO data corruption. Again, this is for SAN attached storage, LVM2 and multipathing.

Cheers

© 2013 Novell