Restoring FileMaker 12 Backups With Managed Containers

In the course of my work on a customer project, I discovered that the links to externally stored container fields with a FileMaker Server 12 backup can break if the backup is not restored properly. After trying a number of different scenarios, I have come up with a list of circumstances where container fields will remain intact and when they won’t.

All examples are using a Windows based FileMaker server and apply equally to both secure and open external container storage.  Understanding these situations will help you properly restore FileMaker 12 files that use external container storage.

In case you need to get some basic knowledge about FileMaker Server 12 and the new features related to backup and enhanced container fields, here are some great resources to get you started:

Circumstances where external container data will break (container fields will show files as missing):

  • Uploading FMP12 backup files with the FileMaker Server admin console.
  • Opening backup files in FileMaker Pro — ie, not hosted by a server
  • Opening files in FileMaker Pro that were removed by the FMS admin console

Circumstances where external container data will remain intact:

  • Copying FMP12 backup files, with the respective container data folder from the RC_Data_FMS folder, to the FileMaker server data directory, then opening the files with the admin console.
  • Copying backup files, as above to a different FileMaker server
  • Downloading the files with FMS admin console, then opening the files in FileMaker Pro (e.g., not hosted).  In this case, the databases and remote container file directories are downloaded together, so references to externally stored container fields are preserved.
  • Downloading the files with FMS admin console, then uploading to another server, or the same server, with the admin console. Again, the act of downloading the files brings the container file directory along with it.  Uploading these same files will restore the container data on the FileMaker server.
So to conclude, when restoring backups of FileMaker files that use external container storage, copy the files (don’t upload with the Admin Console) to the data directory of your FileMaker server.  In addition to the FMP12 files, copy the respective subfolder for your backup file in RC_Data_FMS to the RC_Data_FMS folder in the server data directory.  Note that on Mac OS servers, permissions for the FMP12 file and container directories need to be reset when copied to the data directory and not uploaded with the console.


  1. Taylor Sharpe says

    And we’re back to the good old days of modifying permissions for files copied to the FileMaker Server live database folder. While not a problem for a server administrator, it does make things confusing for users who are not used to working with permissions. I really liked when the Admin console started taking care of permissions automatically via uploading. You would think it would handle external container fields for us automatically. Maybe that is coming in a future release.

  2. Darren Burgess says

    Thanks for stopping by, Taylor. We are hoping for an improvement in that regard as well. Would be better if the admin console upload process would recognize and restore the backed up container data when uploading a backup database to the server.

  3. Dan Smith says

    While this is technically correct, I don’t think it tells the whole story. The listed circumstances where external container data will break can all be prevented by moving the directory with container data up two folder levels.
    FileMaker Server looks for container data in this directory:
    [database location]/RC_Data_FMS/[database name]/
    FileMaker Pro/Admin Console look for container data in this directory:
    [database location]/

    So, if trying to upload a FMS backup via the admin console, first copy it out of the backup directory (so you don’t mess with the files in your backup), then move everything from:
    [database location]/RC_Data_FMS/[database name]/
    to here:
    [database location]/

  4. Darren Burgess says

    Thanks for the additional info Dan and making a contribution. I would add that you say to copy the files – this is the correct action to take as opposed to moving them. When copying, the OS will properly access the hard-linked back up files. (hard linking occurs because FMS now creates hard-linked copies to files that have not changed, saving backup time and space.

  5. Peter Wagemans says

    It seems to me that FileMaker Server ( admin console ) has trouble with uploading very large files.
    Under the hood, the admin console zips the file + external data, and if the zip file size exceeds 2GB, it has trouble unzipping it back again on the server. My experience on a Win 2008R2 x64 server, it could be different when using OSX, I didn’t test that yet.
    If this turns out to be a correct observation, I see problems arising when restoring backups using the admin console.

    • Darren Burgess says


      That is really excellent additional information, thank you. I suspect that with very large files it may be best to move them manually to the server. Have you tried such?

      • Peter Wagemans says

        Hi Darren,
        I experienced the problem before reading this excellent blog article. It surely would have helped.
        So indeed, after experiencing the unzip error I tried copying the 6 GB of external PDF data to the server – not using the admin console, to discover that the containers did not load anymore. Dan’s remark probably explains why this did not work, allthough it could have been me not paying enough attention to the exact path required.
        I ended up uploading the only the file, and then adding the PDF’s again through a FileMaker script, uploading them that way. Not really optimal, but suprisingly fast. Since that worked for me, I did not examine any other way. I have spent a lot of time watching uploads that day…:-)

        • Darren Burgess says

          Well, I am glad the information was at least belatedly useful to you! Thanks again for contributing your experiences on this article. It benefits everyone.

Leave a Reply