My employer had the same concern so i came up with cheap and quick way to make a backup of the entire server and have it available to run in a matter of minutes. I made a virtual clone of the machine and set it up on a second computer. If the main server ever goes down, with a click of a button you can have a fully functional FileMaker Server running and all you would need to do is copy the backup database file to it and you are in business, no need to point the FMP clients to a different IP or anything.
Knock on wood....i have yet to have a need for the redundant server but it's there if i ever need it.
I made a virtual clone of the machine and set it up on a second computer.
I don't know where to start with this. How does one make a *virtual clone*?
VMWare has a converter that will take a physical machine and convert it to a virtual. I have an older version that works well but haven't played with the new one which is here: http://www.vmware.com/products/converter/
Like you, I'd not be all that confidant of cloning a server configuration. You only have to watch an installer placing hundreds of components in their intended locations to see how complex the configuration has become. Matt's VMWare converter is presumably for a Windows installation.
What I've thought of doing for our FMS on a MacPro with OSX 10.6 is to make a replicated system from scratch on a separate drive. Then, in the evnt of a failed HD, the new system has to be selected as the startup volume and the files reloaded from the latest backup.
This is not something that I've rushed into. Thus when it's needed it will likely still be near the bottom of a ToDo list!
the client is asking for a 'failback' implementation
You do not say what sytem you are on
On a Mac:
close the databases and stop fms
clone the entire HDD using Carbon Copy Cloner ( there are others) to a drive on a spare server
the server needs to have a registered IP to its MAC address - IN ADVANCE of the failure
So, FMS backs up hourly to a local attached usb drive. The destination directory needs appropriate permissions to get a valid path in fms admin
I also use a push backup to push the fms to usb hourly, to a LAN NAS RAID.
the push backup uses a launchd to run a shell script, that tests for the target being mounted, iterations thereof, and other conditions., then archives the hourly and pushes the archive to the remote (LAN) NAS.
An additional push to a separate WAN NAS is required to deal with the building burning down, but then serving may or may not be an issue.
IF you run your backups to the fms drive (why?) or a different partition on the same drive (why?) a hourly scheduled push backup across the LAN, one might consider ABSOLUTELY mandatory.
So come failure time, swap the usb from the failed server to the failback server. Pull the last backup to the failback server. The restored db's will now be served from a different address.
If the servered files are on an attached drive rather than the server HDD, then even easier. BUT, are the db's sound or corrupted? So using the last ( presumptively) good backup is arguably safer. Depends on what data loss can be tolerated, and how frquent is the backup. Whatever it is, write it up and get it signed off; you advise, they decide.
A written failback protocol is needed, so that a trained responsible person/monkey can implement it.
remove tab a from slot b, insert tab a into slot c ...
TEST the failback implementation.
The fms server is a dedicated box right? Nothing else running.
You as the developer will not always be to hand. Downtime is the issue. How much can the client tolerate?
In an enterprise or university setting, you may also have a look at Symantec Netbackup (was formerly Veritas Netbackup) to backup the whole system to an external tape library or other backup media. This software is cross-platform and runs on a variety of operating systems.
The important thing is to exclude the Databases folder where your live databases reside in the exclude list file. In addition, one should make sure that the Netbackup and FMS backup schedules don't overlap, so that closed databases are being transferred from the FMS backup folder to the external backup media. No downtime is needed to do the backups. Restore is another thing, see points discussed by cortical.
Anyway, it's always good to agree on a SLA with your clients (whether internal or external).
Don't forget to abide by FileMaker backup rules to never backup or virus scan a live database (see Martin Braendle's comment). Only backup from the FileMaker backups folder. Personally, I think your client has a need and is telling you how to do it when there is a better way and you should be directing them in the proper manner of achieving the goal instead of getting restricted by the clients ideas of backups. If you want to be safe, have frequent backups that are saved on an external serial RAID separate from the production RAID. Of course the OS should be its own hard drive and really isn't all that important if it is backed up or not. Copy the schedule scripts to the backups folder. Also get something like 360Works SafetyNet and have it make regular backups to the Amazon cloud and include the backup of the schedule scripts. Also have on your backups a copy of the latest FMS installation software and its associated serial number. Then practice recovery which means bring in a new box, install FMS, copy the databases, and install the schedule scripts and you'll be up and running again very quickly. Once you've done this a couple of times you'll realize there is little reason to be down for more than a very short while. Of course eneterprise level hardware will make the need much less likely. The only reason I can see for doing a backup of the whole system is that you have other things you are trying to save on the system and that just is not necessary on a FileMaker server. And of course if you're serious about your FileMaker Server, you are not running other services or applications on it anyway.