Groupwise backup , TSA, St. Bernard Open File Manager

[jpp]

Historically, we have used Arcserve and St. Bernard Open File Manager )OFM) to backup our open groupwise files.
In recent times, we periodically have a situation where the OFM is hogging CPU time, or the backup is running extremely slow. It may also coincide with a gwcheck repair process.

Besides any thoughts on above, I'd appreciate if anyone can explain to me:
- do we need an open file agent anymore if groupwise now uses the Target Service Agent (TSA) ?
- how can i make sure I am using the TSA ?
- is there a better way to backup groupwise ?

thanks

 

[terry712]

no you dont need a ofm
they were always progmatic as hell

the gwtsa backs it up perfectly well
do be truthful with newer versions of groupwise a flat file backup works just as well - fair enough you may miss a few .idx's etc but theyre not critical

 

[ITsmyfault]

SP3 of Groupwise 6.5 is introducing GW backup via the TSAFS - the regular file system TSA. This is a very welcome development as the old GWTSA was not cluster aware (and likely would not have become so..) There are new command line switches to tell the TSA it is backing up Groupwise. SP3 is pretty new (might want to wait a few weeks..)

AFA using the GWTSA now.. when you run it with it's /HOME switch (see docs on setting this up), it will send the backup app components of the system. Rather than backup the PO directory or volume, you would browse in the backup app and see something like "Groupwise System" listed perhaps like a volume and/or something like this as you browse the file system:

1[DOM] MyDomain
2{PO] PostOffice
3[DMS] lib001

etc. You'll see the doc mgt pieces whether you have them installed or not. Select these items to be backed up. and you're all set.

 

[jpp]

Thanks to both of you for your helpful replies.
I am now doing it with just the TSA, and it seems well and good but a few of the backups I have received a few of these
AE3125 Failed to read xxxxx data set, fffdffc6

where xxxx is a message or user database.

i assume that means i did not get a good backup on those particular files. anything i can do about that ?

 

[ITsmyfault]

Best way to check your backup is to restore it to another volume (better yet, create a dedicated restore area if you have not already) restore your backup, point your client to it (in C1) and see what you get. Can you connect, and is your mail there? then you can log in as the user whose file generated the error and see what's up.
That TSA error code does mean what it says - it could not read the file. What happens sometimes is mail is moving through the system and so files are getting created and destroyed all the time. Depeding on the volume of mail you receive during the backup window, you may see artifacts from this. At the same time, we get plenty of email in during our backup window and I have none of these errors.. Hmm. What version of GW, netware etc are you on?

TSAFS error code:

http://www.novell.com/documentation/nwec/index.html?page=/documentation/nwec/nwec/data/aky23bq.html

 

[jpp]

We are on gw 6.5 sp1
netware 5.1 sp5

most of the errors involve message databases, so I am concerned about that.

we are 24/7 shop, so there could be activity , including folks in their mailboxes, during backup window.

thanks.

 

[bytehd]

i believe one of the benefits of TSAFS is that
when you LOAD TSAFS.NLM /GWEnable=YES, that any
SMS aware app (SBCON, BE, Arc/Bright) can grab
the open GW files. Sees them as a "BLOB", which
actually may be a good thing as you usually need
to restore the WHOLE GW file tree anyways..

There are notes in the beta about "freeze/release"
actions going on here.

http://support.novell.com/cgi-bin/search/searchtid.cgi?/2970478.htm

Nothing different any OS vendor has tackled over the years.
BAsically have to flush open file buffers, close, allow backup, reopen, etc..

I would REALLY like to know if anyone can test this along with me....

Marv?
Lawnboy?
ITSMyFault?



George Walkey
Senior Geek in charge

http://www.insyncva.com

 

[LawnBoy]

I'm waitin' on a new tape deck, the old one died ignobly. I'll then need to talk my boss into applying SP3.

I have every intention of using SBCON. I'm sick of screwing with 3rd party backup software. We'll see.

 

[LawnBoy]

BTW, I had a Veritas rep tell me that BE 9 does not recognize the NSS FileCopyOnWrite option, so you still have to get an OFM.

Sheesh.

 

[bytehd]

figures.....

sounds like SBCON is the best thing going.

especially since you can schedule it now in 6.5!



George Walkey
Senior Geek in charge

http://www.insyncva.com

 

[jpp]

Forgive me, but I am still not sure about what strategy I should take in getting good backups of my groupwise system
we are using netware 5.1, and I have no plans to upgrade to netware 6.x.
therefore, sounds like SBCON is not an option.

I'd like to continue using Arcserve (I know, that's probably the first you'll hear anyone say that !)
but I'd like to stop using St. Bernard Open File Manager because it tends to hog CPU.

So do I understand correctly - if I simply use
LOAD TSAFS.NLM /GWEnable=YES
then Arcserve will talk thru the TSA and get clean backups of my post office message and user databases, while they are open and in use ??

Thanks.

 

[LawnBoy]

Sorry, didn't mean to hijack your thread...

SBCON is always an option. You can load Cron.NLM on your server and schedule it.

So do I understand correctly - if I simply use
LOAD TSAFS.NLM /GWEnable=YES
then Arcserve will talk thru the TSA and get clean backups of my post office message and user databases, while they are open and in use ??

I don't think that NSS on NW5.1 has the FileCopyOnWrite option (this enables the native OFM), therefore you will still need your OFM. Someone will correct me if I'm wrong...

And any non-NSS volume will always need an OFM.

 

[ITsmyfault]

fwiw I put in SP3 on our GW 6.5 server last Fri and also patched up to TSA5UP17 (the newest TSAFS) Backup ran fine (no errors, got every file), but I am having a time stamp issue - eg: no one can empty their trash.. The SP3 agents need to be in the path and my path was still pointing to the old 652 folder so maybe that was my issue. Fixed my search paths so I am hopfull that time stamps work tonight.

Another good fix in SP3 - there is a switch for the GWIA and POA to allow IMAP to poll where there are >5000 items in a folder. A buddy of mine said the one thing he lost in his SP3 install was his RBL settings; they got blown out.

last note: unlike the GWTSA which maintains database "state", the TSAFS backup does not so they reccomend running GWCheck against the restored files to fix broken links etc.
I've only done 2 backup jobs with the new TSAFS on Groupwise so far but it was not much faster than the GWTSA was (maybe 20%?) and is still nearly 3 X slower than my normal backup jobs. If I can't get the time stamp thing working tonight I may go back to GWTSA for now.

 

[bytehd]

how are you measuring speed?
backup log mb/s rating i guess?
traditional or nss?
sbcon or third party?

George Walkey
Senior Geek in charge

http://www.insyncva.com

 

[ITsmyfault]

Measuring speed: Avg KB/sec reported by backup app for the actual "backing up" portion of the job, not the verify we run after. BEX gives a summary in the log of time to backup, avg speed (total bytes over total sec..) and then a total time for job (incl verify) My typical volumes run at anywhere from 22MB/sec to 44MB/sec. GWTSA backup ran at just over 6MB/sec, TSAFS is running a solid 7.7MB/sec. Still 1/3 as quick as an average volume. Better, but not there (yet.. IMHO.)
All volumes are NSS (NW 6.5.2)
Backup app is Syncsort BEX 2.1.5D
Groupwise 6.5.3 running clustered in protected memory.
Storage is IBM FastT600 on 2GB fiber.
Tape is IBM LTO2 library on fiber.
Fabric is zoned single initiator. (tape and disk seperate)
Servers are IBM x345 2.8Ghz, 4GB RAM

timestamps still not working.. running gwtmstmp each morning manually and it's gettin' old.