*Just realised that most of this was already covered in Darren Burgess' fine blog last November: http://www.mightydata.com/blog/restoring-filemaker-12-backups-with-managed-containers/ Apologies for any unintended plagiarism.
The Remote Containers feature of FMS 12/13 significantly improves the backup speed1 but restoring backups can be tricky. Hopefully the following will be helpful, either in an emergency or to establish good protocols ahead of time, so that emergencies are less likely.
We have an FMS 12 install (v12.0.4) with a conventional backup regime of several schedules per day. Periodically, we copy down files or folders from the backups, to check backup integrity.
When opening backup copies we found:
- 1. Grabbing a backup file with the RC_Data_FMS folder next to it and uploading via the Admin Console – external container storage references are broken.
- 2. Opening a backup file in FMP with the RC_Data_FMS folder next to it – external container storage references arebroken.
- 3. Log into Admin Console, close the database, download database, open in FMP – External container storage references are intact.2
- 4. Uploading a file which has been previously downloaded from Admin Console – External container storage references are intact.3
- 5. Grabbing a backup of a file, with the RC_Data_FMS folder next to it, manually copying into FileMaker Server/ Data/ Databases directory. Then going to Admin Console to open the file – links are intact.4
- If viable in the working environment, plan to semi-regularly close the hosted file and download a copy using the Admin Console, just in case a ‘minimum fuss, emergency backup’ is required.
- Have a strategy in place to fill in the gaps between the safety copy and the daily backup. For example, you could import the most recently modified records from the backup, excluding the container field. Then add the container info back again, manually.
- The new Save As A Single File option (File menu, Save A Copy As…) works best with a Console-downloaded backup.
- 1. A pre-RC, verified backup took around 15 mins whereas a post-RC, verified backup took less than 2 minutes. Total data: around 4.5 Gb, spread across approx 85 files. Only one file has one field with RC. RC data: approx 750 Mb.
- 2. Option 3: the download process creates two items, a copy of the database itself and (Windows 7) a folder calledFiles. The Files folder contains the RC structure and the references in the database are automatically adjusted to this new folder.
- 3. Option 4: the upload process ‘knows’ to grab the Files folder and therefore the RC structure gets re-created on the server.
- 4. I have not personally tested Option 5 but I have been assured that it works.
- 5. Our RC files are Open rather than Secure; I have been assured that Secure works the same way.
- 6. The default RC path uses the original name of the file rather than the file’s current name however this does not have any adverse effects, should a restore be required.
- 7. Some users have had problems uploading large files (eg > 2 Gb) to their FMS servers. The recommendation is to upload an empty or a ‘lite’ copy and then import the bulky data. If you have a ‘good’ backup available, you can upload a ‘lite’ file with disconnected links and then import the container contents from the good backup file, matching on the primary key.