Documentation edition: 9 September 2026

Backup and recovery guide

What the supplied backup tool covers

If both configs target one database, both SQL buttons can export the same tables. Do not import either casually over a shared production database. The supplied SQL dumper includes table definitions and rows, not a complete server backup of users/grants, events, stored routines or views. It does not establish a consistent transaction snapshot; coordinate a quiet period or use the host's consistent backup for an active site.

The file tool's default per-file limit is 25 MB. It excludes various config/parameter files, logs, caches, dependencies and backup folders. Do not assume every credential file is excluded: the supplied filename rules do not specifically exclude the newer siteadmin_password.php. Treat the resulting ZIP as private and inspect the current exclusion rules before distributing it.

Keep configuration/password files, large media, dependencies, hosting settings and a full-account recovery route separately. A small changed-files update ZIP is not a backup.

Make and validate backups

1. Use /siteadmin/backup.php. Choose Download, Store privately or Download and store as appropriate.
2. Retain copies on your computer or trusted private storage, with dates and target database names recorded privately.
3. Check that downloads completed and archives open. Compare their contents to what should be included; missing expected files can be due to exclusions.
4. Confirm SQL includes table definitions and inserts for populated tables. Empty tables legitimately have no inserts.
5. Restore into an isolated database/site copy and test representative records. File size and the presence of SQL statements alone do not prove recoverability.
6. Keep at least two dated generations before deleting old copies.

For encoding repairs, also retain an original host-level dump before any conversion. Application exports run through a connection charset and can transform incorrectly labeled bytes.

File rollback

For a small code update, restore the exact overwritten files from the pre-update copy. Preserve current database configuration and password files. Do not restore an entire old website merely to undo one JavaScript change. Test affected pages and authentication after restoration.

For full recovery, work on staging or use maintenance mode. Restore compatible code, media and configuration, then the intended database snapshot. Recreate the private backup folder outside the public root. Verify permissions and paths, PHP version, extensions and credentials before reopening access.

Database restore with phpMyAdmin

1. Identify the intended target database from its config, not the backup filename alone.
2. Export the current state privately even if damaged, if possible.
3. Prefer an isolated test database first. Import the SQL using phpMyAdmin or the host's supported method.
4. Verify table names, record counts and representative names/accents, flags, accounts and club details.
5. Schedule the actual restoration so newer submissions/edits are not silently lost.

The supplied dump contains DROP TABLE IF EXISTS: import replaces matching tables and their data. Database DDL is not reliably undone by a surrounding transaction. A real backup is the rollback mechanism.

Failures and escalation

• If ZIP support is missing, use hosting File Manager or an account backup.
• If creation times out, avoid repeated long requests. Use the hosting backup/CLI route. Lowering the per-file size limit cannot solve every timeout or large SQL table.
• If the private directory is unwritable, have the host create the configured folder outside the public root with appropriate owner-only permissions. Do not solve this by placing SQL downloads in a public folder.
• If MySQL connection fails, verify config paths and user grants without exposing credentials in screenshots.
• If a download is interrupted, use a retained private copy if creation completed and download through the hosting file tools.

After recovery, rerun functional and database checks before accepting a new checksum baseline.

Include the new continent and certificate assets

Back up wherecountry after reviewing classifications: restoring an older snapshot may lose wherecountry_continent_real and the assignments. The original migration CSV is only an initial proposal, not a backup of later admin edits.

Include the current milestones, world-map, export and continent-editor PHP files, the certificate-fonts folder and existing logo. Check actual file-backup exclusions rather than assuming font assets are present.

A code-only rollback can restore the previous PHP file while leaving the new column in place. Removing the column is not necessary to undo a page update. The full project handoff is useful context and source, but is not a complete hosting or database backup.