What should be included in an application backup strategy?

Your FileMaker system has been quietly running your order process, your production planning, or your customer records for years — and the backup strategy behind it is still "a nightly copy to an external drive someone set up in 2015." Nobody has tried to restore from it. Nobody knows how long a full recovery would actually take. That's not a backup strategy, that's a hope.

This article walks through what a real application backup strategy should include for a business-critical FileMaker system — from what to back up, to how often, to two things most companies still get wrong: never testing the restore, and keeping every copy in the same building as the server.

Why isn't "we have backups" enough?

Because a backup file that has never been restored is an unverified claim, not a safety net. A classic scenario: a company's server disk fails on a Tuesday morning. IT locates last night's backup, restores it — and discovers the container fields (the folder holding scanned invoices, photos, and PDFs) were never included in the backup job. The database opens fine. Every attached document from the last three years is gone.

A real strategy answers three questions before disaster hits, not during it:

1. What exactly gets backed up?
2. How often, and how far back can we go?
3. How fast can we actually be running again — and has anyone proven it?

What actually needs to be in the backup, not just the database file?

A FileMaker system is rarely just one .fmp12 file. A complete backup strategy covers:

• The database file(s) themselves — including every linked file in a multi-file solution, not just the "main" one.
• Container data stored externally — if you use external or remote container storage (common for scanned documents, photos, PDFs, video), that folder structure must be backed up on the same schedule as the database, or the two will drift out of sync.
• The FileMaker Server configuration — schedules, security settings, SSL certificates, plug-in configurations. Rebuilding a server from scratch without this is slow and error-prone.
• Any connected integrations — API connector credentials, webhook configurations, scheduled scripts that push data to an ERP or accounting package like Exact Online. If these aren't documented and backed up, the database can be restored perfectly while every integration around it stays broken.
• Custom scripts and server-side schedules — exported as text or documented separately, so a rebuild doesn't rely on someone's memory of "how it used to work."

How often should backups run, and how many should you keep?

This comes down to two numbers every business owner should be able to state without checking with IT:

• RPO (Recovery Point Objective): how much data can you afford to lose? If it's "at most 15 minutes of order entry," a nightly backup isn't enough — you need progressive backups running every 5-15 minutes, which FileMaker Server supports natively.
• RTO (Recovery Time Objective): how long can the business survive without the system? If the answer is "under an hour," your strategy needs more than a backup file sitting on a shelf — it needs a plan (and ideally infrastructure) that gets a working server back online fast.

A sensible layered schedule for most FileMaker systems looks like:

• Progressive backups every 5–15 minutes (kept for a day or two)
• A full backup every night (kept for 1–2 weeks)
• A weekly backup archived for a month
• A monthly backup archived for a year or longer, for compliance or historical recovery needs

Why does an off-site (remote) copy matter so much?

Because a backup stored on the same server, same building, or same local network as the production system protects you from a corrupted file — but not from a fire, flood, theft, or a ransomware attack that encrypts everything it can reach, including your backup drive.

A real-world example: a manufacturing company had backups running perfectly to a NAS in the server room. A ransomware infection spread across the local network overnight and encrypted the NAS along with the production server. The backups existed — they just weren't anywhere the ransomware couldn't reach.

A sound remote backup approach includes:

• At least one backup copy stored off-site or in a separate cloud location, physically and logically isolated from the production network.
• Immutable or write-once storage for at least one recent copy, so a compromised admin account can't delete or encrypt historical backups.
• Automated transfer, not a manual "someone remembers to copy it to the cloud on Friday" process.

What does FileMaker Standby Server actually add to this?

FileMaker Standby Server is a newer capability that goes a step beyond traditional backups: instead of restoring a backup file after a failure, a second, continuously synchronized copy of the database sits ready to take over.

In practice, that means:

• Changes on the primary server are streamed to the standby server in near real time.
• If the primary server goes down — hardware failure, OS crash, a bad update — the standby server can be promoted to become the new primary, with far less data loss and downtime than restoring from a nightly backup.
• It's designed for business-critical solutions where an RTO measured in minutes, not hours, actually matters — a production-floor system, a customer-facing order portal, a logistics dispatch tool.

Standby Server is not a replacement for backups — it protects against a different failure mode. A backup protects you from data corruption, accidental deletion, or a bad script run. A standby server protects you from the primary machine simply disappearing. A mature strategy uses both together.

How do you actually test that a backup works?

This is the step almost every company skips, and it's the one that matters most. A backup you haven't restored is a backup you don't actually have.

1. Schedule a real restore test — quarterly at minimum for business-critical systems, monthly if the system changes frequently.
2. Restore to a separate, isolated environment — never test a restore against production.
3. Open the file and verify data, not just that it opens — check that recent records are present, container files open correctly, and scripts run.
4. Time the whole process — from "decision to restore" to "system usable again" — and compare it against your RTO. If it's slower than the business can tolerate, the strategy needs to change, not just the backup schedule.
5. Document the result — who did it, what was restored, how long it took, what broke. This becomes evidence for management and a checklist for the next real incident.

A quick checklist for a real application backup strategy

• Database files and all linked files included
• External/remote container storage backed up on the same schedule
• Server configuration, schedules, and certificates documented and backed up
• Integration credentials and scripts documented separately
• RPO and RTO defined in plain business terms, agreed with management
• Progressive + nightly + weekly + monthly backup tiers in place
• At least one off-site or cloud copy, isolated from the production network
• Immutable/write-once storage for recent backups (ransomware protection)
• Standby server in place for systems where minutes of downtime matter
• Restore actually tested on a schedule, with results documented

FAQ: application backup strategy for FileMaker systems

How long should we keep old backups? At minimum: enough daily copies to cover a week, weekly copies for a month, and monthly copies for a year. Regulatory or industry requirements may push this further — check what applies to your data.

Is cloud backup enough on its own? Only if it's genuinely isolated from your production network's credentials — a cloud backup reachable by a compromised admin account offers little extra protection against ransomware.

Do we need Standby Server if we already have good backups? Only if downtime itself is costly. If losing an hour of system access has real business impact — lost orders, stalled production — Standby Server closes a gap that backups alone can't.

Who should be responsible for testing restores? Someone outside daily operations, ideally with management sign-off on the results, so testing doesn't quietly get skipped when things get busy.

A backup strategy is never really "finished" — it should evolve as the system, its integrations, and the business's tolerance for downtime change. If you're not sure whether your current setup would actually hold up in a real incident, that's a good starting point for a conversation. Loggix can help review or build a backup and continuity strategy around a custom FileMaker solution — including standby server setup, remote backup configuration, and restore testing — as part of a broader look at how your business-critical software is secured and maintained.