File Corruption Check

Checks a hosted FileMaker file for structural corruption by recovering one of its backups with FMDeveloperTool and exporting XML of both the original backup and the recovered copy. Diffing the two XML files reveals what recovery had to change — the signal that a file is corrupt. Runs via AWX.

AWX template: Generic - FMS File Corruption Check Primary use: Detect structural damage in a hosted file.

Mac servers are not supported. Servers in the macs_fms group will not appear in the client/server selection for this workflow.

Only full backups are supported. Progressive backups are not, because there is no reliable way to tell when a progressive backup has finished writing.

All pages in this flow show an Experimental warning banner.

The wizard has four steps:

Select a client
Select the host
Select a backup file
Review and run

1. Select a client

Choose the client group whose server you want to check. Every client with at least one server you can access is listed — unlike Migration and Refresh, a deploy chain is not required, because a corruption check runs against a single host.

2. Select the host

Choose the FileMaker Server whose backup you want to recover and check. Only servers you have access to within the selected client are shown. Production servers display a red badge. Click Browse backups to continue.

3. Select a backup file

The portal connects over SSH and lists the server’s backup directory. This is the same browser used by Host from Backup — On-Server:

Click a folder to navigate into it.
Use the breadcrumb trail to jump to a parent folder.
Click .. to go up one level.

Select the backup .fmp12 file you want to recover and check, then click Review.

The file you pick is both the backup to recover and identifies the hosted file being checked — the role derives the hosted filename from the backup’s filename.

4. Review and run

A summary card shows the client, host, the backup file to recover, and the hosted file being checked.

Disk space

A stacked bar shows the host’s backup volume. Recovery stages a copy of the backup and writes a recovered copy beside it, so the projection charges twice the backup’s size. The disk-capacity policy applies: above 90% projected usage the Run Corruption Check button stays disabled until you tick the acknowledgement, and above 95% the run is refused.

Options

Host the recovered file (`host_recovered_file`)

When checked, the recovered copy is moved into the live databases folder and opened on the server as RECOVERED_<timestamp>_<filename>. Leave it unchecked to only produce the comparison XML without touching what is hosted.

Where results are published

When the run finishes, the recovery log and both XML files are published behind FMS admin basic-auth (use the FMS admin credentials) at:

https://<server name>/recovery-xml/<backup-date>/

The <server name> is the server config’s Name (its web FQDN), and <backup-date> is the dated backup folder the file came from. The directory contains:

<file>_<timestamp>.xml — XML of the original backup
RECOVERED_<file>_<timestamp>.xml — XML of the recovered copy
Recovery_<timestamp>.log — the FMDeveloperTool recovery log

Diffing the two XML files shows what recovery changed.

Admin debug panel

Staff users see a collapsible AWX extra vars panel showing the exact variables that will be submitted to AWX. The panel updates dynamically as options change — useful for verifying the job configuration before launch.

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
Published results — on success, a link to the recovery-xml directory (above)

Unlike the data-transfer 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 (the failing task), not the full log.

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

AWX variables submitted

Variable	Value
`fms_file_recovery_file`	Hosted filename being checked (the backup’s basename)
`fms_recovery_backup_path`	Full path to the selected backup `.fmp12`
`host_recovered_file`	`true` / `false`

The job is limited to the selected server’s host (inventory_hostname). File-recovery credentials, FMS admin credentials, and encryption-at-rest keys are fetched at runtime from 1Password by the role — they are never entered in the portal.

History

Completed checks appear under the Corruption checks tab of the History page. Each record shows the host, the file checked, the backup recovered, whether the recovered file was re-hosted, the user, and the result (OK / Failed / Canceled). Running jobs show a View output button linking to the live job output. Finished jobs show a Result badge and a View output button. Failed jobs show the error in a tooltip on the badge. Staff users can filter by user.