Server Backup Experience: time taken/lockouts on large files?

[Thomas Seidler]

Greetings all,

[color:gray]This is only really relevant to those hosting files in excess of 200-300MB at a guess... where back up time begins to become an issue.

I'm posting because of a TechNet meeting today in the UK, where a guy lecturing on FMS10 shared that it still locks users out of files, and for one client running a 1.2GB file 40 users were being locked out (on a windows hosted solution he admitted!) for 4 minutes at a time during back up. His solution was to use FMDataGuard to creat roll forward logfiles etc. and just do one file back up at night when system not in use.

This came to me as a bit of a disappointment, as the heralded server back up improvements (i.e. it hardly locks you out - just stores changes during back up and writes them at end of backup) could have meant an end to any backup time / file size considerations. But alas, if FMS9/10 have not really changed the backup methodology (and therefore lock out time issues) then as a user group we need to know for sure.

So I thought it would be good to gain, with your help, cross platform & setup experiences. Here is my example of the kind of data we could usefully use to consider the problem - demonstrated by my legacy FMS5.5 solution (but I'm only interested in 9 & 10 experiences - those with the claimed new backup methodology):

• OS Type [Mac OS 10.4.9]
• Processor [G5 2GHz]
• RAM [8GB]
• Exact hard disk configuration and speed [files shared on one 2 disk 7200rpm RAID 0, and backup files written to another 2 disk 7200rpm RAID 0, system on yet another single disk!]
• FileMaker Server Version [5.5v4]
• File system [48 total file system, 2.6GB total; regular back up of only 16 files, weighing in at 750MB]
• Lockout time experienced [15 seconds tops for regular backup]

On a MacMini (2GHz Core Duo 2, 2GB RAM) the same backup was taking 60+ seconds!

If I find you are getting similar lock outs on FMS9/10, I will have to be very careful about potentially consolidating my 2.6GB solution into one data file... If you don't find it a problem on Mac OS then it don't matter, but if it is still a problem!!! : u know the rest... we talked about solid state drives for our data too! Good times!

Even if you can't share the detail, i'd love any perspectives on this? Backup speed on large volumes of data... Does it lock you out?

Many thanks in advance from your time and help, in the hope that this will be of some use to others too, :

Cheers,

tom

www.thegoodbook.com

www.thegoodbook.co.uk

[Vaughan]

Server backup time will be directly related to disk throughput, with RAM and CPU next. Your backup figures with a RAID plugged into a G5 demonstrate this.

I didn't even know FMS 5.5 would run on an Intel box. It it running under Rosetta emulation? That might account for the poor performance. Or maybe it's because it's running on a Mac Mini. As much as I love them, they are not server class machines.

[Thomas Seidler]

Hey Vaughan,

what are your experiences of actual file backup times on FMS 9/10?? Speed/lockout? It simply shouldn't be the same kind of problem if FMS backup methodology has changed as it states it did from 7 onwards.

But like I say, I heard that the problems are still identical, and [color:gray]"Server backup time will be directly related to (file size &) disk throughput, with RAM and CPU next."

So it has very similar backup times to FMS 5.5 even though the FMS9 Techbrief says the following:

One of the primary reasons to use FileMaker Server 9 even in smaller setups is the ability to perform “hot” backups (live backups).

If you are not familiar with that process, this is how it used to work with FileMaker Server 5.x:

• At the scheduled backup time, all files are first paused, then copied to their destination folder
  
• The files remained paused until all files are backed-up
  
• Changes that the users make during this time are stored in cache, or if there are too many data requests, the users are put on hold (the famous “coffee cup”) until FileMaker Server 5.X un-paused the files. This would happen especially in a busy environment or with large FileMaker files.

That behavior [color:red]changed radically with FileMaker Server 7 and is still the same with FileMaker Server 9:

• FileMaker Server 9 starts copying the live files while users are still accessing them
• At the end of the copy process the file is momentarily paused to synch the changes since the start of the copy.

The gains? The files are physically paused only for a very short time so the clients are not inconvenienced while the backup occurs. And the copy reflects the state the files were in at the end of the backup process rather than the state they were in when the backup started.

The gains are clear and massive for those serving big databases, [color:brown]the change is radical and wonderful - IF IT IS REAL. And like I say, at the TechNet meeting organised by FileMaker the lecturer on FileMaker Server was saying it was not real in his experience on Windows, but he experienced 4 minute 'hot' backup times on 1.2GB files.

This is something I wish to verify from the experience of others also, especially those on Mac platforms (he was basing his comments on Windows). Does it lock the file up for a long period of time if you are running a 1GB file and choose to back it up live???

I hope I have more clearly made the case for needing to know the experience of others running large file systems, the question is FileMaker documentation true in reality, or ideality only???! : It is not unimportant to those of us with large data sets.

Many thanks for your patience, sorry I had not explained myself clearly the first time.

Tom

[Vaughan]

My experiences with FMS 8 and later have enjoyed significantly reduced interruption to users during backups.

You are making some strong conclusions based on one person's experience with FMS, without any knowledge of the quality of their setup. FMS 8.0 *is* significantly better than earlier versions, but it needs the optimal hardware to get the benefit, especially the disk and network subsystems.

I'm prepared to wager that the 4 minute backup time would have easily been several times longer with FMP 5.5. I've had several minute wait times with databases just a couple of hundred megabytes in size with FMS 5.5.

BTW in the past it's generally been accepted that FMS has run slightly better on Windows than on Mac OS X. Only slightly though. The choice of platform is better based on operating system knowledge etc.

[Thomas Seidler]

OK, update from the 4 minute man, Mr Paul de Halle, of LinearBlue UK - he would agree with you Vaughan:

On the whole I would say FMS 10 is faster than FMS 5.5

The issue was with Server 9 and 10 and once properly configured we got the main time down to 2 minutes for a 1.2Gb file. We had mixed results (ie FM didn't agree with mine) with a Mac. Unfortunately the client had just spent a fortune on a state of the art Windows server. To get the best results you need an entirely Mac network from what we can gather.

Hope this is helpful, though mildly conflicting OS efficiency thoughts. I will post when I've got mine running with SSD drive... This will not be till May.

[Thomas Seidler]

OK my dears, thanks for bearing with me,

It must have been a very strangely configured Vista server to produce such poor results.

I have 1.4GB single file being backed up every 20 minutes. It takes 11 seconds to complete as it backs up from one 150GB Velociraptor to another.

There is *no* lockout (single user test), though a slight barely discernable slow down. 5GB Ram, full 800MB being used for cache etc.

Very happy indeed my fears are gone, and, though still not over the pain of 46 fp5 files to 1 fp7 file, am excited about the possibilities FMPA10 brings...

The future is bright. Am running it on 10.5.1

Blessings,

Tom