A little background... one of two tape loaders on our Exchange server dies which means we can no longer do bricks-level backups using the installed 10.5 without buying a new loader. As we're virtualising and moving to a SAN soon I'm not going to waste money on a loader that won't be of any use in a few months so we go the other route and buy into upgrading to 12.5 in order to use the much heralded GRT.
Problems:
- no direct upgrade from 10.5 to 12.5. symantec advise that unless many jobs and media pools exist (define "many"!?) to take a backup of the catalogs then uninstall and install 12.5 and import the catalogs. This results in BE losing ALL knowledge of ANY tape it's ever handled, even if that tape is in the imported catalogs and is inventoried and catalogued again. Also lost not just the media pools but also the vaults. Result - five years of tapes, about 800+, are likely to have to be recalled from off-site and run through to recatalog them before sending them offsite again *IF* they can get it to ever recognise the tapes and media pools again. This is about 2-3 man months of work caused by following their advice!
- GRT effectively HAS to be backed up to disk, but it doesn't say this anywhere before you buy it. I've had different answers on this from different Symantec techs, but what the docs basically say is "if you want it to work, it must go to disk" - so we through 2TB of disk storage that's not really spare at backing up about 400GB of Exchange DB and logs.
- Using compression corrupts GRT backups. Not properly documented, and then only in a support tech note - not the install or best practice guides. BE still lets you enable compression on the job, then corrupts the output (so say tech support).
- GRT doesn't support Difs. Documented via one line hidden amongst 1700 pages of other docs and not somewhere you're going to look when doing the install / config. You can still select Difs for GRT backups and it will try to do them and again, corrupt the whole output and further jobs.
- BERemote using 700+MB of RAM during backup.
- GRT Incs hanging while "updating catalogues" causing job engine to lock and have to be killed from Task Manager.
- media rotation of the disk based backups is truely dire.
- the duplicate backup job the copies the disk backups to tapes don't run properly, conflict with other backups, and often fail to copy the data to tape simply due to scheduling problems now that our backup window has at least doubled.
- and last but not least my personal favourite... when backing up using GRT if the place the backup is being written to (disk or tape) runs out of space, the VSS writer just sits and waits for space to become available and leaves the files locked open during this time. After a while Exchange dismounts all the DBs in order to protect them. This MASSIVE problem with the API (lack of cancellation / delay handling) hasn't stopped Symantec building this "advance" into their products and telling everyone it's the best thing since chocolate and to buy and use it immediately.
To make a long story short it's been over four weeks since we "upgraded" and I doubt we've had more than one good GRT full to disk, and I don't think we've had ANY good GRT backups to tape. In the mean time we've ad at least five instances of Exchange taking all the DBs offline due to GRT, and this has mostly occured during production hours so has stopped people working.
I've spent at least 10 man days working on this with Symantec who's now got to the point of "yes that's certainly an issue but we need to be sure if it's related to the one we know we've had for over six months (and still haven't fixed) or if it's another one"
Am I being unreasonable in expecting that an expensive product that's supposed to protect the integrity and uptime of your data and core systems should have been properly designed, tested, and at least partially idiot-proofed and properly documented?!?
Can anyone tell me that BE & GRT for Exchange 2003 does actually work?
If I junk Backup Exec and buy something else, what should I buy?
Please someone help me before I go slam my head in a door to numb the pain!