Restoring Backup Files on FileMaker Cloud for AWS

by Darren Burgess
Posted in All, FileMaker, FileMaker 17, FileMaker 18, FileMaker Cloud, Server Administration, System Administration
Recently, we had a client who required restoration of FileMaker backup files for their FileMaker Cloud for AWS 1.17–hosted solution. This seemed a simple enough request—we would download their backup files using the FileMaker Cloud for AWS Admin Console and then re-upload them to the server. However, things did not go smoothly as there was seven gigabytes of data to download and the process was too slow for their fast-paced production environment…like half-a-day too slow. Clearly we needed a better way that could get our client up and running much faster. Special thanks to Simon Brown for working out the details of this procedure. The basic idea is that FileMaker Cloud for AWS 1.17 is hosted on a Linux (specifically CentOS) server. What if we could log into the server and restore database files by simply moving them to the correct directory? While there are a few details to pay attention to, if you are reasonably comfortable working from the Linux command line then you can use the tools available too quickly and safely restore backup files. Note this method really would only be necessary if the files to restore were very large and you were in a hurry. You can restore backups more safely using the FileMaker Cloud for AWS Admin console by preserving, attaching and downloading a backup and then uploading it back to the server. Warning! You are soundly entering “knows enough to be dangerous” territory here! Reach out to us if you need some help with FileMaker Server administration.

Prerequisites

  • Your applications are hosted with FileMaker Cloud for AWS 1.17. This approach may vary for other versions of FileMaker Cloud.
  • The FileMaker Cloud for AWS Admin Console is working
  • You have FileMaker Cloud for AWS instance root credentials
  • Established SSH access to the FileMaker Cloud for AWS instance
  • Basic proficiency with the Linux command line

Establish SSH Access

This part of the procedure should only need to be done once per user requiring access. Basically, you need to grant access on the server for the user that will be logging in to restore the backup files.
  • Whitelist the IP address of the user. This is completed via the AWS management console.
  • The administrator should navigate to the ~/.ssh directory on the local machine and use ssh-keygen -t rsa -f hostname.key to create a public and private key pair. Copy the hostname.key.pub public key to the server.
  • Now the admin should be able to use the below instructions to ssh to the server to restore backup files.

Attach the Backup Files(s)

The first step is to attach the backup using the FileMaker Cloud for AWS Admin Console. Once the backup file(s) are attached, they will show up in the Linux directory structure.
  1. Log into FileMaker Cloud for AWS Admin Console.
  2. Navigate to the Backups tab.
  3. Preserve the desired backup by checking snapshot and clicking Preserve Backup.
  4. From sidebar, select Preserved Backups.
  5. Check the desired snapshot and click Attach Snapshot.
  6. Click through the dialog and expect to wait several minutes, especially for large files.
  7. Close the production file(s) that will be replaced by the backup using the Admin Console.

Move and Rename the Backup File(s)

Next, ssh into the FileMaker Cloud for AWS instance, move the attached backup to the production directory, and rename it. Directory paths specified below assume a standard installation. Adjust paths according to particulars of your configuration and filename(s).
  • ssh to the FMC server: 
    ssh -i ~/.ssh/hostname.key username@hostname.domain.com
  • Establish session using sudo privilege: 
    sudo -s
  • Should now be at # prompt
  • Change to directory containing backup files. These will be the files that were attached using step 5 above (Attach Snapshot): 
    cd /media/Data/Databases/
  • Copy backup file(s), preserving permissions (-p) 
    cp -p filename_appendedTimestamp.fmp12 /opt/FileMaker/FileMaker\ Server/Data/Databases/
  • You could optionally confirm that the copy command worked by listing the files in the production directory: 
    ls -la /opt/FileMaker/FileMaker\ Server/Data/Databases/
  • Remove the original production database file(s): 
    rm /opt/FileMaker/FileMaker\ Server/Data/Databases/filename.fmp12
  • Or if you want to be extra cautious you can just rename it and delete it later: 
    mv /opt/FileMaker/FileMaker\ Server/Data/Databases/filename.fmp12 /opt/FileMaker/FileMaker\ Server/Data/Databases/filename_OLD.fmp12
  • Rename the backup(s) to the original name: 
    mv /opt/FileMaker/FileMaker\ Server/Data/Databases/filename_appendedTimestamp.fmp12 /opt/FileMaker/FileMaker\ Server/Data/Databases/filename.fmp12
  • Confirm by listing: 
    ls -la /opt/FileMaker/FileMaker\ Server/Data/Databases/
  • Open the copied backup file(s) in the FMC for AWS Admin Console

Optional Restore of Externally Stored Container Data

If you have external stored container data in your solution then that may also need to be restored. In some cases you will only need to restore the database files that reference the externally stored container data. Use these commands to remove the production container data and copy the backup data to the correct directory. The paths provided are samples only; adjust them based on your servers configuration and filename(s) for your installed applications. In these examples the files are stored using the secure option. Paths may be different if the files are stored using the non-secure external storage.
  • Consider copying the production container data just in case you make an error. Make a temp directory first: 
    mkdir /opt/FileMaker/FileMaker\ Server/Data/Databases/RC_Data_FMS/filename_OLD
  • Then copy the production container data there, preserving permissions and using recursion: 
    cp -pr /opt/FileMaker/FileMaker\ Server/Data/Databases/RC_Data_FMS/filename/* /opt/FileMaker/FileMaker\ Server/Data/Databases/RC_Da_FMS/filename-OLD/
  • Remove the production container data (recursively and forced with -rf. Warning!  This cannot be undone!  -rf is extremely dangerous as it will delete all directories and files in the specified directory with no confirmation. Change to the directory first so that there less risk of deleting more than you want): 
    cd /opt/FileMaker/FileMaker\ Server/Data/Databases/RC_Data_FMS/
rm -rf filename/
  • Copy backup container data recursively, preserving permissions (-pr): 
    cp -pr /media/Data/Databases/RC_Data_FMS/filename_appendedTimestamp/* /opt/FileMaker/FileMaker\ Server/Data/Databases/RC_Data_FMS/filename/
  • After confirming that your restored files have the required container data, you can remove the backup of the production containers you made in the first step: 
    cd /opt/FileMaker/FileMaker\ Server/Data/Databases/RC_Data_FMS/ 
rm -rf filename_OLD/
A safer, although slower, alternative to this procedure would be to move the externally stored containers to stored by modifying the storage settings in the container field definition. Then perform a backup and attach that backup.  Once the files are restored you can move the files back to external storage. These extra steps may take a long time if there is allot of container data however.

Wrapping Up

As you can see, the restore process is as simple as moving backup files to the correct location. The best advice we can give at this point is to set up this restore option in advance and to test both the access and the procedure monthly. Best practice backup procedures include periodic restore testing to make sure your backups can really be used to restore your data. Good luck and let me know if you have any questions. darren_b(at)beezwax.net

Leave a Reply