In October 2011 I posted a simple backup script that has made my development life easier, but of course that version was for .fp7 files only (the release of FM 12 being six months in the future), and when I began converting files to FileMaker 12, I realized that the backup script was not intelligently rolling with the changes. So recently I modified the script to accommodate both .fp7 and .fmp12 files, and also to be more flexible with regards to separators within the backup file name, e.g.,
Rather than repeatedly referring the reader back to the earlier article, I have “deprecated” the prior one and reproduced it here with appropriate changes, and have also updated the demo file (see below).
Broadly speaking, FileMaker developers fall into three categories: a) those who do all their development on local files; b) those who do all their development on hosted files; and c) those who sometimes develop locally, and sometimes in a hosted environment. I happen to fall into category “c”, and suspect that many of my colleagues do as well.
A few years back I put together a basic script to create on-the-fly backups when working on local files. Any time I make regular use of a tool or technique, I figure there must be at least a few other people out there who will find it useful as well. And a big thank you to Bruce Robertson, who gives so much to the FileMaker community, for writing the Mac-specific code for this demo: Backup-Revisited
Disclaimer: This is not a substitute for a well-thought-out offsite backup scheme… just a quick and dirty way to make backups during development without having to first close the file, take the time to compress it, decide what to name it or where to store it. As with all techniques on this site, view with skepticism, and use at your own risk.
Overview: the backup script generates a compressed copy of the file with an OS-friendly timestamp prepended to the file name, e.g.,
20111009_112831_yourFile.fp7
or
2012.06.25 - 15.42.24 ~ backup,revisited.fmp12
…and saves it in this location, creating the folder structure as necessary, like so:
(current folder)/Backup/Saturday/
I’d like to take a brief walk through the script and make a few observations on the way.
First we declare a number of variables. When I’m working through something, I find it much easier to declare a number of separate variables, and use them as building blocks, rather than write one ultra-efficient code statement. I find this helps me debug more quickly, and also, when I come back later, it makes it easier for me to figure out what’s going on.
The term “filespec” signifies not just the file name, but the location as well. In this case the file will be stored two folders “below” whatever folder our solution happens to be in. The $timestamp variable is sliced and zero-padded in this particular manner a) to remove characters that are forbidden on either the Macintosh or Windows platforms, and b) so that if a number of separate backups are later sorted by name, they will sort in chronological order. (I know, I know, they can be sorted that way at the OS level by sorting on the creation or modification date/time — just humor me, okay?)
Next, do we need to bail out?
If we’ve made it this far, then it’s safe to proceed. Now it’s time to ensure that the folder structure is in place, which we can accomplish via the Send Event script step on Windows…
…or via Perform AppleScript on the Macintosh.
And the remainder of the script is self-explanatory.
This script is completely portable. You can copy it from the demo file, paste it into your solution and immediately start using it. If you convert your solution from an earlier version of FileMaker to FileMaker 12, the backup script will continue to purr along like a contented kitten.
Think of this version as a starting point. No doubt it can be improved and extended in various ways, for example…
- During active development, have an on-timer script trigger run the backup script every x minutes
- As part of the backup routine, call a shell script (or perform Applescript, or use a plug-in) to make a zipped copy, and then…
- FTP the zipped copy to an off-site location
As always, comments or suggestions for improvement are welcome.