Back up a PHP application beyond the web server

Define the recoverable application

A copy of the document root rarely describes the complete application. Inventory the database, user uploads, generated documents, scheduled jobs, queue state, configuration, and external dependencies. A release artifact may recreate the code while leaving the customer data missing. Record which components can be rebuilt and which must be recovered from a dated copy.

Choose a recovery point for each component and explain how those points fit together. For an illustrative order system, a database export taken before its attachment copy can produce records whose files are absent. Use the database's supported consistent export method and a documented approach to concurrent file changes.

• Database recovery point
• Uploaded-file scope
• Release identifier
• Configuration location
• Queue reconciliation
• Recovery owner

Move the copy outside the host's failure boundary

Store recovery data separately from the account that runs the web application. Restrict the application's storage credentials to the intended source, and keep administrator and restore access out of the application environment. A stolen web credential should not automatically grant control over every recovery copy.

NordenVault's documentation describes an S3 storage endpoint and setup for restic and rclone. It provides a concrete configuration reference when considering an offsite destination; its published setup is not evidence that a particular PHP application has a working backup. The restic manual separately explains how to configure non-Amazon S3 storage.

Keep secrets recoverable without publishing them

A repository password, storage key, database password, and application encryption key have different purposes. Document the recovery dependency for each and store the required secrets in an access-controlled system that remains available if the production host disappears. Never put their values into backup logs, source control, or a public web directory.

NordenVault's security page is the provider's own description of its controls. Read that scope alongside the application's responsibilities. Provider-side encryption does not answer who can decrypt an application export, retrieve its keys, or authorize a restore.

Rebuild into an isolated destination

Restore a selected recovery point into a separate environment. Disable outbound email, payment execution, and scheduled jobs before loading customer data. Check the code version against the database schema, then verify a representative uploaded file, record, and permission boundary. Keep a written result with the snapshot identifier and elapsed recovery time.

A successful upload is only one event in this chain. Recovery also depends on obtaining the credentials, downloading the data, opening it, loading the database, and reconciling changes after the recovery point. Repeat the exercise when those dependencies change.