Disk errors during backup

Question

Hi, I'm baaaaaaack!
I have a new (replacement) Netware 6.5 SP8 server running Groupwise,
with 4 RAID'ed 450GB 10K SAS drives giving me about 1.2TB of space. In
keeping things arranged close to the way they were before I arrived, for
now at least, I have a "DATA_POOL" which holds "SYS2" volume. During
nightly backups, since the new server went in about 12 days ago, I'm
getting backups failing, and eventually the SYS2 volume dismounted last
weekend during the full backup.
I tried doing a poolrebuild even though poolverify showed no errors, per
Symantec & Novell documentation, and that didn't suffice. Had to do the
"purge" rebuild, and then was able to re-mount the volume. I wasn't
sure if the error was somehow related to the server migration, so I
tried the same full backup again and got the same nasty results.
Rebuilt again, and made some changes to the OFMCDM.CFG file as
recommended in some Symantec documentation, and the backups have been
succeeding.
However, the logs show lots of entries like the following, still, always
during the backups:
3-08-2011 9:43:15 pm: COMN-3.26-178
Severity = 5 Locus = 3 Class = 0
NSS-2.70-5009: Pool AIRP_COMM/DATA_POOL_SP had an error
(20012(beastTree.c[510])) at block 129200397(file block
-129200397)(ZID 1).
3-08-2011 9:43:15 pm: COMN-3.26-180
Severity = 5 Locus = 3 Class = 0
NSS-2.70-5008: Volume AIRP_COMM/SYS2_SV had an error
(20012(beastTree.c[510])) at block 129200397(file block
-129200397)(ZID 1).
It's not clear to me if this means it *has* to be a disk drive error.
New disks would seem to increase the likelihood of physical disk
failure, but it only happens during the Backup Exec 9.2 backups of this
volume, and never on the SYS volume during those same backups.
The Groupwise total database is about 100GB, and the total volume space
is about 800GB, if that matters. (This server is built to GROW.)
Suggestions? Does this clearly point to a hardware (disk) error even
though it only happens during backups, and the symptoms changed when I
made the OFM configuration changes?
The changes I made to OFMCDM.CFG were:
InitialCacheSize = 0x0000000000400000 (was 200000)
CacheSizeExpandThreshold = 0x30 (was 0x1e)
The old server didn't have any problems backing up, and everything was
brought over intact/identical in configuration, even though the above
changes did seem to help somewhat. I'm posting here because this seems
more of a "storage" (disk) issue than really a backup issue, despite the
failures occurring during backups.
Any suggestions, or clarification about the above cause & possible fixes?
Thanks.
-- DE

Answer 1

Thanks, but I don't know of any way to back up Groupwise without using
OFM; you just can't get the data if you do that because so many
important files are open. And I do agree that it's OFM if it is not a
hardware issue.
Your entries under "device" look like the defaults, which I started
with, and yet there are a bunch of references on the Symantec (Backup
Exec) site which suggest changing those. But I will want to compare
your entries with mine, higher in the file, to see if there is any
particular setting that is non-default and might address the issue.
I do have slots for a spare drive on this new server. Currently, the
cache is directed to the very same volume that is having issues,
although it worked fine that way in the past on the old server. But I
can easily get another drive if that will resolve this.
Thanks.
-- DE
[email protected] wrote:
> Besides other possibilities I would at first take the OFM
> out the game and run backups without it.
>
> In case that does the trick and you need to backup open file
> - as we did - I would try the following (here we run
> NW6.0-SP5 with BackupExec 9.1 and OFM from St. Bernard,
> which comes with BE):
>
> Place a single spare disk in the server with a seperate pool
> and volume and direct the open-file-cache to this device. In
> our case it is directed to TMP and the ofmcdm.cfg is the
> following:
>
> [General]
> BreakOnAssert = 0x1
> BreakOnException = 0x1
> MinServerMemoryPercent = 0x6
> StatusPrintLevel = 0x0700000000000000
> ThreadsPerQueue = 0x3
> QueuesPerPool = 0x1
> WriteInactivityPeriod = 0x2
> SyncTimeOut = 0x3c
> CacheLFS = 0x0
> CacheBlockSize = 0x4000
> GetHamSetStateTimeout = 0x3c
> LFSCachePoolName =
> BackupCachePoolName =
> BreakOnCluster = 0x0
> VerboseMessageLogging = 0x0
> SyncLFSVolumes = 0x0
> CacheToLFSVolumes = 0x0
> AutoMountVolumes = 0x0
> LogFileBufferSize = 0x10000
> LogFileNumBuffers = 0x4
> LogFileWriteFrequency = 0xf
> DebugDumpOnSyncFail = 0x0
> LFSCacheLocation =
> BackupCacheLocation =
>
> [Advanced]
> SmallEmergencyMemBlockSize = 0x400
> SmallEmergencyMemBlockCount = 0x32
> MediumEmergencyMemBlockSize = 0x2800
> MediumEmergencyMemBlockCount = 0xa
> LargeEmergencyMemBlockSize = 0x19000
> LargeEmergencyMemBlockCount = 0x2
>
> [Device SYS]
> MinFreeSpace = 0x0000000000400000
> InitialCacheSize = 0x0000000000200000
> CacheSizeExpandThreshold = 0x1e
> CacheSizeFailThreshold = 0x5
> Status = 0x29
>
> [Device BAK]
> MinFreeSpace = 0x0000000000400000
> InitialCacheSize = 0x0000000000200000
> CacheSizeExpandThreshold = 0x1e
> CacheSizeFailThreshold = 0x5
> Status = 0x29
>
> [Device TMP]
> MinFreeSpace = 0x0000000000400000
> InitialCacheSize = 0x0000000000200000
> CacheSizeExpandThreshold = 0x1e
> CacheSizeFailThreshold = 0x5
> Status = 0x79
>
> [Device GWX]
> MinFreeSpace = 0x0000000000400000
> InitialCacheSize = 0x0000000000200000
> CacheSizeExpandThreshold = 0x1e
> CacheSizeFailThreshold = 0x5
> Status = 0x29
>
> [Device IVM]
> MinFreeSpace = 0x0000000000400000
> InitialCacheSize = 0x0000000000200000
> CacheSizeExpandThreshold = 0x1e
> CacheSizeFailThreshold = 0x5
> Status = 0x29
>
> [Device ZFD]
> MinFreeSpace = 0x0000000000400000
> InitialCacheSize = 0x0000000000200000
> CacheSizeExpandThreshold = 0x1e
> CacheSizeFailThreshold = 0x5
> Status = 0x29
>
>
>
> I do not remember all the other tweaking we did with the
> BE-Support, but this finally did the trick and helped us to
> run the server without any problems.
>
> Sincerely
>
> Karl