At long last, 10 has arrived! After all the tantalizing little glimpses that we got last devcon, I for one am glad we finally have something we can get our hands on. There are a lot of new features and changes to go over, and I’m going to mention them all here, but for this particular article I am going to be focusing on the huge improvements to backup scheduling and how the configuration methods have changed for the better. The level of depth in the scheduling options that the new Retention setting and souped up controls over the timing of the schedules is a big step forward. Essentially, one schedule can now take the place of many. So, without futher ado, onto the details.
##A Few Improvements
First off, there are a few small additions that will make a big difference for some developers.
1. While the limit of connected users for Server is still 250, you can now have up to 999 connected users in Server Advanced. Why they didn’t round that up to 1000, I don’t know.
2. You can Import/Export and Send Mail on Server. For those of us who have always had to find ways to schedule scripts in the client environment using a robot machine or alternate scheduling method, you can now use the Import, Export, and Send Mail script steps in server-side scripts. Now nightly transfers of data into or out of our databases, or sending out some type of custom notification won’t require any voodoo.
3. Improved PHP Site Assistant. The PHP Site Assistant has been heavily overhauled.
4. Improvements to server efficiency on multi-core and multi-processor machines. Server will now use more CPU cores when performing finds (and possibly in other cases). So finally we have an excuse for getting the new oct-core, quad-processor server we’ve always wanted!
##Backup Schedules
The first thing to do before setting up your backup schedules is to set a default backup location. You can change this location for the individual Backup Schedules as well, but if you are using one loaction for all your backups this will save you from having to type in the path every time you set a schedule up. You can do this from the Database Server, Default Folders section of the Admin Console (see image). Also, now with the inclusion of retention settings the backup names are going to include a timestamp, so if you have an existing solution that is looking for a specific name, you’ll need to adjust it to account for the timestamp.
If you are using a mac to run your server, be sure to use “filemac:” before the path. Windows users should use “filewin:”. Any valid path will work here be it network of local, just be sure to validate it before implementing your backup scheme. Generally, the backup folder shoulde be on a separate physical drive than the databases themselves in case the database drive fails. If they are both on the same drive, and that drive dies, it’s game over. So, a separate physical drive or a network drive is your best bet for the backup location. Another thing to consider is offsite backups. Whether that means backing up to tape and taking the tapes to a separate location or having an online backup solution that lets you upload your backups it is always good to have a copy of your information somewhere other than your building. It just takes one errant meteor strike (or fire if you want a real world example) to wipe out all your data if it’s in one spot. If you implement both a separate backup location and an offsite backup scheme you should be able to recover your system as quickly as possible and avoid a huge amount of hassle.
Now to the fun stuff, otherwise known as scheduling if you are a normal person. The problem previously was that in order to run a daily backup with any type of retention policy, you had to create a separate schedule for every day you want a backup to run. In 10, if you want to back up everything on a daily basis and maintain a level of depth for retention reasons, there is a built-in “Daily” schedule that does just that with no additional configuration. You can find it in the Admin Console’s Schedules section labeled as “Daily”. If you have this option checked, Filemaker Server will automatically run a full backup of all your databases every day and keeps a full weeks worth of backups for retention purposes. If a daily backup does not meet your needs, you can go to the Schedules section, uncheck “Daily” and check “Hourly” if you want a little more protection against having to reenter data in the case of a server crash. The “Hourly” option runs every hour, shocking, I know, and keeps eight copies before overwriting the oldest. So, if your hourly backups start at noon at 8 pm you will have reached your retention limit and the 9 P.M. backup will overwrite the noon copy and so on and so forth. The final pre-canned backup you can select from is the “Weekly” backup schedule, which will keep four copies of backups for you. All of these pre-canned schedules can be edited. Just double click on the schedule and it will walk you through all the available configuration options. So, should you want to run your daily backup at 5 in the morning instead of 8 A.M., that is how you would modify it.
To ensure that you have both current, up to the date information and more long term, just in case backups we recommend that you turn on all three options if you can. Hourly backups will ensure that as little data as possible is lost should a crash occur, daily backups give you a good fallback in case you have a problem like older records being deleted or a change being made that takes more than a few hours to notice, and a weekly back as a fallback in case a problem goes unnoticed for longer than your daily retention policy accounts for.
If you really want to make sure that the backup scheme meets your specific business needs you’ve got the option of creating a custom backup schedule. To do so, simply select “Create a Schedule” from the Actions pop-up, make sure you have “Back Up Databases” selected and create away! At this point you’ll be asked which type of schedule you want to create and you can either go with “Hourly”, “Daily” or ”
Weekly” to have a template to work from or “Custom” to start from scratch. Now, the next window is going to ask for the location of the backup (again, if possible this should be somewhere other than the drive your databases are on), the retention policy (number of copies of the backups to keep before overwriting) and whether you want to verify the backups or not.
Verifying the backup will check the backup to ensure that the structure of the database is clean. If you have email notifications set, this option will send out notifications to the designated people. Once you have those options set and click next you are ready to specify how often, when and for how long this schedule will last. You can specify everything from which days of the week to run it on (so if you wanted to run it on everyday except friday, just uncheck friday) whether to run the schedule once a day or at specific intervals over the course of the day. So, if you wanted a backup that runs every weekday in the morning and night, you would set it up by unchecking saturday and sunday, set the frequency to Run Every 12 hours then set the start time to 6 A.M. and the end time to 7 P.M.. For this example I would set the retention to at least 10 to keep a weeks worth of backups available. This gets you a morning and night daily backup with five days worth of retention in one schedule.
Personally I can’t wait to go through all my existing backup schedules and consolidate them, and I’m not ashamed to admit it!
I have seen very little info on changes made to IWP. Are script triggers possible within IWP? Does IWP run faster/slower with 10? Have there been any major changes/improvements to IWP?
Thanks SO much for your wonderfully detailed review! This just makes me even more excited to get moving with 10.
Aaron:
I must confess we don’t use IWP enough to speak very intelligently about it. To your specific questions:
1. Script triggers are not supported in IWP. I suspect of would take a major overhaul of the way interaction works in IWP to get something like this working.
2. There is one report on technnet about poor IWP performance, so there may be some inconsistent bugs to work out, but in general I would expect performance to be about the same.
Server itself has seen some performance improvements, so you may see some speedup, but I don’t think the web publishing engine has been sped up.
Hope it helps,
Geoff
@Geoff:
It turns out that script triggers are partially supported by IWP (and CWP). From the FileMaker Pro Help: “In Instant Web Publishing and Custom Web Publishing, script triggers can only be activated by a script and not by direct user interaction. For example, if a user tabs into a field that has an OnObjectEnter script trigger, the trigger will not activate. If a script step causes focus to move into that field, the script trigger will activate.”
It turns out that it’s not entirely limited to script-based triggering in IWP. A script trigger will also activate based on a button which performs a script step directly. For instance, a button which performs a commit records command will trigger the layout’s OnRecordCommit event.
It’s far less than what a real web client would give us, but it’s better than nothing!
– Dave
As far as I can tell, the backup path has to be on the local filesystem, so you CAN’T specify a network volume. The help recommends making a local backup and then copying it, which is a pain.
If anyone has found a way to trick it, please post.