Host from Backup — Object Storage

Restores a .fmp12 from a FileMaker Server’s off-site object-storage (duplicity) backups and hosts it in FileMaker. The portal lists the available backups (over SSH), and the restore itself is run by AWX. All pages in this flow show an Experimental warning banner.

AWX template: Generic - FMS Backup Rehost Primary use: Restore and host a backup that is older than what a server keeps on its own disk.

On-Server vs. Object Storage. These backups reach further back in time than the ones a server keeps on its local disk (bounded by the object-storage retention — roughly the last six months), but a restore has to pull the file back from object storage first, so it takes longer than Host from Backup — On-Server. If the backup you need is recent, prefer On-Server.

The wizard has six steps:

Select a client
Select the host
Select a backup point
Select a file
Choose the hosted filename
Review and run

1. Select a client

Choose the client group whose server you want to restore to. Every client with at least one server you can access is listed — a deploy chain is not required, because a re-host runs against a single host.

2. Select the host

Choose the FileMaker Server to restore onto. Only servers that have an object-storage bucket configured (the duplicity_bucket host var) appear here — a server the portal has no backup location for cannot be browsed. Each server shows its bucket. Production servers display a red badge. Click List backups to continue.

Reading the backup list from object storage can take a few seconds — the portal runs duplicity collection-status on the server to enumerate the restorable points.

3. Select a backup point

The portal lists every restorable backup point in time, newest first, each tagged full or incremental. Pick the point you want to restore from and click List files.

Both this step and the next one read the backups over the network, which can take several minutes. The portal shows a spinner and keeps working in the background, so the page can be left open — or closed and revisited, which picks the listing back up rather than starting it again. A listing is remembered for a few minutes, so stepping back and forth in the wizard is free.

Only one listing runs per host at a time, because duplicity allows a single process at a time against a server’s backup archive. If a listing is refused with a message about the host being busy, something else is using that archive — most often the host’s own nightly backup — and it will work a few minutes later.

How far back the list goes is set by the backup retention on the server (duplicity’s remove-older-than, currently six months) — the portal itself imposes no limit and simply shows every point the backup reports.

4. Select a file

For the chosen point, the portal lists the .fmp12 files present in that backup (duplicity list-current-files). Select the file you want to restore and click Review.

5. Choose the hosted filename

Enter the filename the restored file will be hosted under. It defaults to a timestamped name — the original name plus the backup point, e.g. PIR_2026-04-03_180501.fmp12 — so that a re-host creates a new file and never collides with something live. It must end in .fmp12.

Change it to a name that is already hosted only if you intend to overwrite that file; you will be asked to confirm on the next step. Click Next — the portal then connects to the server to check for a name conflict and verify disk space.

6. Review and run

A summary card shows the client, host, backup point, the file within the backup, and the filename it will be hosted as.

Disk space

A stacked bar shows the databases volume’s usage before and the projected free space after the restore, mirroring the On-Server flow, and the disk-capacity policy applies: above 90% projected usage the run button stays disabled until you tick the acknowledgement, and above 95% the restore is refused. The disk is read again when you launch, so a review page left open while the disk filled up is re-judged rather than trusted.

Object storage does not expose a file’s size before it is restored, so the restored-size estimate is taken from the copy already on disk (the target when overwriting, otherwise the original name if it is still hosted). When neither exists the size is unknown — the projection cannot be made at all, so the policy asks you to acknowledge that the restore may take the disk above 90% rather than guessing. Make sure there is ample free space.

Overwriting an existing file

If the chosen filename already exists on the server, a warning appears and the run becomes an overwrite, with the same safeguards as the On-Server workflow:

FileMaker Server closes the existing file before it is replaced.
Unless you uncheck Back up the existing file before overwriting, the current file is copied to a timestamped folder first: …/hosted-db-backups/<db>/<timestamp>/<filename>.
The button reads Overwrite & host and the disk bar accounts for the extra backup copy.

If the filename does not exist (the default, timestamped case), the file is simply created and there is nothing to overwrite.

Production confirmation

If the destination is a production server, a confirmation modal appears when you click Restore & host / Overwrite & host. Verify the filename before confirming.

Admin debug panel

Staff users see a collapsible AWX extra vars panel showing the exact variables that will be submitted to AWX.

Job output

After launch, the portal redirects to the job output page, which polls AWX every 4 seconds and displays:

Status — Pending, Running, Succeeded, Failed, Canceled
Duration — elapsed time
On success, a confirmation that the file was restored and hosted under the chosen name

As with the other AWX flows, the raw ansible log is not shown on success — output is only displayed when a run fails, and then only the extracted root cause, not the full log.

A link to the job in AWX is shown in the card header, and a Cancel button is available while the job is running.

How the restore works

Listing is done by the portal over SSH: it runs duplicity on the server itself, as the fmserver user in a login shell, so it reuses that host’s backup credentials, proxy settings, and local duplicity cache. Nothing is downloaded to the portal.
Restoring and hosting is done by AWX (the fms_backup_rehost role): it restores the chosen file to a staging directory, moves it into the databases folder under the chosen name, and opens it in FileMaker. If the restored file is encryption-at-rest (EAR) encrypted, the role detects that and applies the key automatically. When overwriting, it backs up and closes the existing file first (see above).

AWX variables submitted

Variable	Value
`fms_rehost_file`	Basename of the file in the backup
`fms_rehost_target_name`	Filename it is hosted under on the server
`fms_rehost_backup_time`	The backup point to restore from (W3 datetime)
`fms_rehost_source_path`	Path of the file within the backup (`--path-to-restore`)
`fms_rehost_overwrite`	`true` when replacing an existing file
`fms_rehost_backup_existing`	`true` to back up the existing file before overwriting
`fms_rehost_backup_base`	Base directory for the pre-overwrite backup

The job is limited to the selected server’s host (inventory_hostname). Object-storage credentials (duplicity-creds_{host}), FMS admin credentials, and EAR keys are fetched at runtime from 1Password by the role — they are never entered in the portal.

History

Each re-host is recorded in the portal (host, backup point, file, target name, user, and result). They appear in the History feed like any other operation, and the Object Storage tab narrows the page to just these re-hosts.