Updates, backups, and recovery

Back up the complete recovery set

A database dump alone is not enough. Preserve the database, application tree, settings.php, encryption hash, attachments, downloads, custom storage, custom extensions, theme assets, and scheduler configuration together.

Safe release process

1. Read the changelog.Identify breaking routes, schema changes, and runtime requirements.
2. Create verified backups.Record sizes and checksums, then test that the database dump can be imported.
3. Clone staging.Use isolated database and storage paths; prevent outgoing customer email.
4. Deploy files.Preserve local configuration and custom code deliberately.
5. Apply release data.Use only the release's documented installer or upgrade mechanism.
6. Test.Authenticate, traverse public/control routes, exercise billing and support, and inspect logs.
7. Cut over and monitor.Reset caches, restore scheduler traffic, and watch failures and queues.

Recovery priorities

Restore the settings file and encryption hash with the matching database. A mismatched encryption hash can make protected values unreadable. Restore private file stores before testing customer downloads or ticket attachments.

Automatic updates

Since 1.3.1 WBAMS applies releases itself. It asks the license server for the newest release on its channel, receives an expiring download token, fetches the package, checks it against the published SHA-256, verifies every file against the package's own manifest, and only then installs it. Since 1.3.4 the update-check response is a signed envelope: a signature that is present and does not verify is a refusal, and a package with no SHA256SUMS.txt is refused outright rather than installed on the strength of the archive checksum alone.

Every file an update replaces is copied aside first, so a failure part way through restores what was there; files the update created are removed again. The three most recent rollback directories are kept under the staging path. php upgrade.php is the command-line route for when the browser one has failed.

Knowing when a release is out

WBAMS checks for a new release every eight hours through the WBAMS Updates automation task, and whenever someone presses Check Now on Update WBAMS. The first check that finds a release newer than the installed one tells the people who can install it:

• By email - once per release, to every active administrator whose role has the Update WBAMS permission. The email names the installed and the new version, the release date and its highlights, and links to Update WBAMS. Switch it off under Update WBAMS › Configure Update Settings › New release emails.
• In the admin area - the notifications bell shows WBAMS 1.7.2 is available (with the real version) at the top of its list, for those same administrators, until the site is updated.

Administrators without the permission are not told, and a release is announced only once however many checks find it. The automation task needs the scheduler running; without it, only Check Now finds new releases.