Every FFC-managed WordPress site is backed up automatically by WPMUDEV Snapshot Pro on a daily cadence. This SOP covers the manual backup path — what an FFC admin runs before risky operations, on quarterly verification cadence, and during rescue scenarios.

The charity-facing version of this page on freeforcharity.org is access-controlled (it is an internal FFC SOP). This ffcadmin.org copy is the operations-team reference for volunteer admins onboarding to backup duty.

When to run a manual full backup

Before a major plugin or theme update.
Before a content audit run that rewrites images at scale.
Before a Simply Static export attempt on a charity site (the export rewrites links and clears caches; revert path needs a known-good baseline).
Before any DNS / nameserver / SSL change at the registrar.
On a quarterly cadence per site (restore verification).
Whenever Snapshot Pro reports red for more than one consecutive day.

The five-step procedure

Step 1 — Pre-flight checks

Confirm disk-space headroom in cPanel/DirectAdmin/hPanel ≥ 2× the current site footprint.
Confirm WPMUDEV Snapshot Pro shows green on the most recent automated run; if red, fix that before doing a manual backup so you do not chain failures.
Pause any active Simply Static export — the export branch will compete for the same resources.

Gotcha: On Hostinger hPanel, the "Disk Usage" widget under-reports email storage. Open File Manager and confirm the mail directory separately.

Step 2 — cPanel / DirectAdmin full backup

Log in to cPanel / DirectAdmin / hPanel for the charity account.
Navigate to "Backup" (cPanel), "Create / Restore Backups" (DirectAdmin), or "Files → Backups" (hPanel).
Choose "Full Backup" — includes home directory, MySQL, mail, and configuration.
Set destination: "Generate / Download a Full Backup", then download to the FFC encrypted volume once it completes.

Gotcha: Full backups can take 30-90 minutes for a populated charity site. Do not interrupt the panel session — most hosts produce a partial tarball if you do.

Step 3 — Database export (belt and suspenders)

Open phpMyAdmin from the panel.
Select the WordPress database for the charity site.
Export → custom → format SQL → check "Add DROP TABLE" → check "Save as file" → gzipped output.
Store the .sql.gz alongside the full backup, named <charity>-<YYYY-MM-DD>.sql.gz.

Gotcha: wp_options.cron and wp_options.transient bloat databases over time. If the export is > 100 MB, run a transient-cleanup plugin before re-exporting.

Step 4 — Verify the backup is restorable

Pull the cPanel tarball into a local Docker (e.g. lscr.io/linuxserver/wordpress) or a staging subdomain.
Confirm site loads, admin login works, key pages render.
Log the verification timestamp in the charity intake record.

Gotcha: A backup that has never been restored is not a backup. Run this step at least quarterly per charity.

Step 5 — Rotate and offsite

Move the backup off the host volume to FFC offsite storage (Microsoft 365 SharePoint, Google Drive nonprofit tier, or the FFC SFTP archive).
Retention: keep weekly snapshots for one month, monthly for one year, annual indefinitely.
Encrypt the offsite copy at rest (host storage encryption is fine; if using consumer cloud, wrap with `age` or `gpg`).

Gotcha: Do not store the backup on the same host volume long-term. A compromised host loses both the live site and the backup.

Restore quick-reference

Spin up the target environment (staging subdomain or local Docker).
Restore the database from the .sql.gz first.
Extract the cPanel tarball into the WordPress document root.
Run wp search-replace against the live → staging hostname.
Run wp cache flush and wp transient delete --all.
Spot-check: home, donate, two interior pages, admin login.

Cross-references

Hosting Techstack — the layer the backup operates against
Service Delivery Stages — Stage 8 first-backup verification

See also docs/ffc-simply-static-config.md — Simply Static export interactions with the backup window.