probkup - backup file appers fast, command then hangs for 40 minutes

[jurriaan]

We're having a difficult time with slow backups to a NetApp san.

probkup online p:\genrw t:\genrw.bck

creates a 1.5 Gb genrw.bck file in a matter of seconds, but the command only returns after 40 minutes or more.

Needless to say, this wreaks havoc with our 'main' backup, where 50 Gb is divided in lots (50) of different files (because windows experiences some 'resource problems' when restoring large files) - each files takes 40 minutes and our total backup thus takes all night.

Is there a specific system call that probkup issues after physically writing the backup file? Something like a sync call? Any hints on how to configure the NetApp to handle that call (or the backup process) a lot faster?

Thanks,
Jurriaan

 

[TomBascom]

Get rid of the NetApp. Those things are boat anchors. Actually that's probably an insult to boat anchors.

Q) How do you make RAID5 even slower? A) Add another parity disk! (i.e. RAID "DP")

You don't mention what version of Progress you are using. There have been some very recent improvements made to probkup performance. Nor the version of Windows. That could be important too.

In general you should also use -com with probkup.

 

[jurriaan]

Oh, if my wishes counted - we'd use Linux and no NetApp anywhere. Alas, they don't, so I'm stuck. We're using 10.1c04 on a up-to-date windows 2003 server install (1x quad-core xeon, 8 Gb memory, gig/10-gig connection to the SAN etc), and I know raid-5 is slow, oh yes!

However, that still leaves me with the question what probkup is doing after the file is written that takes so much time.

 

[tamhas]

Chances are, it isn't an issue of what probkup is doing so much as it is a question of what the NetApp is doing.

 

[TomBascom]

FWIW my guess is that probkup is waiting for the NetApp to actually and really and truly complete the IO. There may be something in the NetApp or Windows settings that is telling it to "write thru" instead of "write back". Write thru is more conservative -- it means that the IO isn't considered done until it really is done. Write back is faster from the applications POV -- but the downside of that is that if A Bad Thing Happens your data might not really get written. In truth though most SANs just do write back these days and don't give you the option anymore, or they bury it *very* deeply.

Of course it could also be something else. I'm just guessing.

Windows + NetApp... the very definition of, oh never mind, it's a family website.

Anyhow... earlier this week there was a thread on PEG about slow backups on Windows. The upshot of it is the a) Progress made some very beneficial changes in 10.2B04 and b) MS has also been doing some good things with Windows Server 2008R2.

So get off those ancient, obsolete and barely supported releases (and junk the NetApp) and onto up to date releases and things should improve

 

[jurriaan]

It would be so very nice to be able to tell here that my employer has decided to switch the server to linux, install a raid-10 of ssd's, that the manufacturer has decided 10.2B04 runs well with our application etc.

Unfortunately, not so.

However, the IT department decided to map our backup disk on a different physical location (different server room) in the NetApp compared with the database disk location. This speeds up backups (for 50 gigabytes) from 12-14 hours to just under 2 hours. The reason for this is as of yet unknown, and the fact that there is a difference does point out the validity of some of the boat anchor comments. But I'll gladly present this solution anyway, in case somebody else has to suffer with this combination of windows and netapp.