i have no solution for you, because for the same reason i always schedule fms10 backup jobs to the spooky hours around midnight.
greetings from germany
Thank you for your post.
I don't have experience with a RAID, but there was a discussion earlier about a similar issue:
Try bumping up the RAM cache in FileMaker Server. Also see what happens if you backup to a non-RAID backup drive, or if you do RAID on the backup, try RAID 0 or RAID 1 instead of RAID 5 (RAID 5 is optimized more for reads than writes). If all else fails, try writing an OS script to pause the databases and then back them up.
If you were at DevCon 2009, take a look at the session slides from my 'Backup strategies with FileMaker Server' session.
Filemaker does a hot backup of the files, so if you're writing to RAID 5, you're gonna see a bit of a slowdown. We use a similar setup and we definitely notice when the backup is running. We just try to not do anything major at those times.
Do you have your raid card configured for read/write cache?
Some things that help backup schedules perform better:
- source drive and destination drive are different (actual drives, not partitions on the same drive). I've only gotten this to work in FMS 9.0v3+. Earlier versions would not let non-boot disk paths register as valid.
- turning off backup verification will speed up the backups. Of course this trades off with some risk.
If you think of a backup as a big set of read and write operations, and add some overhead work for switching any disk from read-mode to write-mode, it isn't hard to imagine overwhelming a drive during backup. Using separate disks adds only read operations to the source disk and only write operations on the destination disk. If you think of verification as another huge set of read operations, that's even more work for a disk.
Note that all my server experience is on Mac OS X machines.
My Mac 2.66 Xeon with FMS 11 backs up at 100MB/s (you're doing 22MB/s), so I think I could do the same backup in 2 minutes 30 seconds. You should monitor HD throughputs while backuping.
In my experience, the backup speed is constrained by the writing speed of the HD. Before I had and old HD (20 MB/s) and it completly bogged down the solution. 100 MB/s is easy to get, just a modern SATA drive, and yes RAID 5 in writes is slower than a single HD (in most cases). So, I would ecaomend you the latest 2TB Western digital caviar drives (which are the fastest right now).
But I have to mention that the original files are on a RAM DISK, so raed is as fast as possible. Since you've a very large solution (mine is 3 GB) I'd recommend a FAST HD for the original files (and even better a fast SSD, like OWC's).
If you have deep pockets, you can get INSTANTANEOUS FMS backup :
Also, I wouldn't recommend RAID (any sort) to host the original files, because you add latency. And low latency is the most important thing. Put a SSD.
So besides XFM, I would do this :
A. OWC SSD for hosting the main files
B. OWC SSD for backuping
C. 2 TB Western digital to backup the SSD backup.
So every 15 minutes you do FMS Backup from A to B, you'll get 200-270 MB/s (would means 1 min 15)
then every 18 minutes backup from B to C (that backup wouldn't bog down FMS serving because B and C aren't involved)
You may even get better speed by using 2 SSD in RAID 0 for B.
B should been seen as a buffer, what you want to do is gives FMS the fastest speed possible (hencs fastest drive) to do the backup and be freed the soonest possible.
I'm impressed by the 15 GB weight, is there any image/sound/movie into this ?
If so you may consider storing those a references rather than in container fields. That would cut the fp7 file size a lot, hence you backup will be faster.