We are using a third-party cloud service to store our FMS backups. Yet, from what I’ve read, even if you encrypt the FMS database itself, that encryption does not apply to the backup.
Thus, the backup needs to be separately encrypted before copying to the external cloud server.
I run a shell script routine which grabs the entire backups folder from the 00:00 (midnight) backup (from external RAID storage), which is encrypted (EAR). The script compresses the DB folder using zstd (slightly better compression for my files than gzip); then tarballs the externally stored container data (not encrypted, nor compressed, just for tidiness); finally copies to AWS EC2 instance via rsync (with resume enabled in case of upload interruption). The DB files remain encrypted.
This script runs at 1:30 AM after all other routines are completed, 6 nights per week. Then a rotation of backups are transferred to Glacier storage (cheap). These backups are only for absolute catastrophe recovery (hopefully never to be used) as we have many local backups.
What if the data theft poses little to no risk? What if I could mitigate data theft by other means?
EAR is meant to slow down access to a file’s data by anyone or anything not authorized to do so. I say slow down because breaking encryption is a thing. It’s just a matter of time. Security ultimately comes down to limiting one’s ability to access the file, encrypted or not.
A file that sits on an external drive located on a desk in a generally accessible office is super easy to steal. Grab that external drive and run. Assuming you made a clean getaway, you have all the time in the world to break any encryption.
It’s not so easy for a file that sits in a data centre where physical access is control by biometric devices and escorts and where network access is tightly controlled with strong passwords, firewalls and the like.
I am over-simplifying the details but hope you get the idea. EAR, like all other security measures, has its pros and cons. I am suggesting you weigh the costs and benefits of multiple approaches to achieve your security (or any) goals before choosing an implementation.
For us and anyone (worldwide) who has files containing any personal information relating to individuals who are UK or Europe based, then EAR must be enforced to conform within the GDPR and UK equivalent rules. I’m sure this would apply within PIPEDA in Canada. Regardless of performance, the protection of personal information takes precedence. We even have to pay the Information Commissioner’s Office (ICO) to police us in the UK.
If the databases don’t contain personal information and the data is not sensitive in other ways, then EAR is optional and, back to my point, would not be encrypted by the FileMaker backup if not applied to the source files.
PIPEDA requires the use of security safeguards appropriate to the sensitivity of the personal data. Encryption at rest (EAR) is one of many safeguards. In the context of PIPEDA, it can be inappropriate or inadequate in some circumstances.
I’m not trying to throw mud at EAR. It’s an extra layer of protection. As you say, it can be a requirement. All I am saying is that there is a cost to EAR and there are alternatives (with their costs). Be aware of and weigh these costs and benefits before selecting an implementation that will satisfy needs. By all means, use EAR if you are okay with its cost or its cost is mandatory.
For me, even 'losing' client email addresses would be a catastrophe (as in a gross disservice to clients' clients). In our cases, we've not seen discernible performance degradation with the use of EAR, but we are currently 100% on-premises-based. It may be more apparent in WAN access applications. We are looking at hosting FMS on AWS for certain clients, so this may become an issue, but we are also refactoring the FM solutions (performance enhancements) in preparation for this.
Of course, I agree with @bdbd that choices typically present trade-offs and must be weighed against one's needs and requirements. For us, it's pro-EAR.
We haven’t seen any noticeable performance differentiation between EAR enabled files and unencrypted over a WAN or LAN. Normally the WAN network speed and database design are the biggest factors, so I threw the question to ChatGPT to compare the performance between EAR and non-EAR files. This was the answer (with full appreciation that AI is not to be trusted):
What EAR does
Encryption at Rest encrypts the database file (.fmp12) on disk, using AES-256.
This means the file is unreadable if someone steals the physical file.
The file is transparently decrypted in memory once opened by FileMaker Server, so users work with it normally.
Performance impact on
FileMaker Server
Minimal to negligible in most cases.
FileMaker Inc. (Claris) states that the performance difference between encrypted and non-encrypted files is generally not noticeable for typical deployments.
Why:
Once the file is open, data in memory and client/server communication are unaffected.
The main overhead comes when reading/writing blocks to disk. Modern CPUs (with AES-NI hardware instructions) handle AES-256 extremely efficiently.
FileMaker Server caches aggressively, so disk I/O is usually not the primary bottleneck (network latency, schema design, unstored calcs, large container fields are bigger performance factors).
Where you might see impact
Startup/shutdown times may be slightly longer (decrypting the file header at open).
Backup creation with EAR-enabled files takes longer, since FileMaker Server must re-encrypt the backup copy (cannot just do a file-system-level copy). This is often the biggest noticeable difference.
High disk I/O workloads (very large files with frequent commits, or container-heavy solutions) may show a few percent slower throughput.
Practical considerations
For most modern servers, the performance hit is in the single-digit percentage range or effectively negligible.
The security benefit is significant if physical theft of the files is a risk (e.g., offsite backups, hosted environments).
Many developers enable EAR by default and accept the slightly longer backups as the tradeoff.
In short:
On FileMaker Server, encrypted-at-rest files perform essentially the same as unencrypted ones during day-to-day use. The biggest performance difference shows up in backup time and, in some cases, slightly slower disk I/O.
Another issue is compression: Encrypted data is incompressible, whereas FileMaker databases often can be compressed 5x to 10x or better with modern compression tools.
This can impact decisions regarding frequency and quantity of backups.
Personally, I find the threat-model for EAR somewhat unusual. For EAR to prevent data loss, you have to imagine a somewhat weird situation:
an attacker has managed to hack into your server
they are able to read files in your filesystem
but they are not able to read RAM
they can not access FileMaker server commands
Is this scenario possible? Sure. But it seems much less likely than scenarios in which the attacker gains root on your server, in which case you are FUBAR.
If you are worried about physical access (e.g. an attacker walking off with your server or a backup drive) then full-disk-encryption is a much better answer.
While encrypted data is not strictly incompressible, its randomness prevents most traditional compression algorithms from being effective. However, theoretically, there could still be niche cases where a specific compression algorithm might exploit some property of a poorly implemented encryption scheme, but this isn't common for modern encryption methods like AES.
In short: