Hosting backups and restore: build a recovery plan

Choose how much recent work you can afford to lose

Start with the data that changes: website content, uploads, database records, store orders and application configuration. Decide how much recent work you could reconstruct after a failure. A rarely edited portfolio and a store receiving orders throughout the day can need different recovery plans.

Compare that need with the backup schedule you choose. If important changes occur between scheduled copies, decide how you will preserve them. A daily schedule does not mean every transaction is continuously recoverable, and a backup option is not a guarantee of a particular recovery time.

Plan how to preserve recent website and store changes

Distinguish backup frequency from restore-point retention

The VPSLibre configurator offers no additional backups, weekly backups or daily backups. The weekly option describes one backup per week with seven restore points; the daily option describes one per day with seven restore points. These are requested service options, with their own quotation lines when selected.

Seven restore points are seven retained copies, not a universal promise of seven days. Their dates and usable coverage depend on the chosen schedule and successful completed copies. After delivery, verify the actual backup information, the data covered, where copies are kept and how recovery is requested before relying on the service.

Without an additional backup option, you manage your own backup plan. Additional service storage is a separate option and does not create backups. Keep an independent copy of important data so your recovery does not depend on one account or one environment.

Make each recovery set complete and identifiable

A WordPress recovery normally needs both files and the database. Uploads, themes, plugins and configuration live in files, while posts, settings and other application data also live in the database. Downloading the website directory alone does not normally capture its database.

For any application, list the data and configuration needed to recreate a working environment. Group compatible files and database exports by the time they represent. Record the application version and relevant environment requirements, and protect copies that contain credentials or personal data.

Check the scope of a service backup rather than assuming it includes every external dependency. Data held by a third-party service needs its own recovery arrangements. A synchronised copy that immediately reproduces deletions may also be insufficient when you need an older version.

Identify persistent container and database data

Test restoration away from the live website

Prepare a separate environment with the requirements needed for the chosen recovery set. Restore the copies using the tools appropriate to your application and the access actually available. Use separate credentials and restrict access to restored personal or customer data.

Prevent the test environment from sending real emails, charging customers or running live integrations. Verify representative pages, media, logins and database records. For a store, check that the recovered order data corresponds to the expected point in time without initiating real customer transactions.

Record what worked, what was missing and how long your own test took. That observation helps improve your recovery plan; it is not a published restore-time guarantee. Keep the live environment intact while resolving test failures.

Restore WooCommerce without discarding newer orders

Restoring an older store database can remove orders, customers or stock changes created after that backup. Record the recovery point and identify what changed since it before replacing live data. Payment-provider records are separate from the website database; a restored order screen does not establish that those two records agree.

Rehearse the restore in an isolated copy with outbound integrations contained. Agree on how recent transactions will be reconciled and who can authorize reopening checkout. For a code or extension problem, first establish whether a targeted rollback can solve it without replacing the entire store database. A product CSV is not a complete copy of orders, customers or subscription records.

• Record the backup time and the latest live order reference.
• Identify orders, customers and stock changes after that point.
• Reconcile payment and fulfilment records before reopening checkout.
• Verify the restored application and keep the reconciliation record.

Contain payments, emails and webhooks in a staging copy · Budget recovery copies and maintenance space

Back up Docker Compose volumes as application data

Keep the Compose configuration and an inventory of named volumes, bind mounts, database exports and uploads. Recreating containers from their images restores code, not the records held in those data paths. Use the database or application’s supported backup procedure to obtain a consistent set; copying a live volume without that procedure is not a verified database backup.

Restore into an isolated project with separate volume names and destinations. Recreate the approved services, check ownership and configuration, then test representative reads and writes against the restored data. Record the version and snapshot time used. Avoid pointing the rehearsal at production data or integrations while checking recovery.

Include backup and restore peaks when sizing a Compose VPS

Keep the recovery plan usable as the project changes

Review the plan when you add a database, move files, change software or introduce a new integration. Make a recoverable copy before a major application change and verify that the recovery instructions still match the environment. Use the actual service management information for any provider-specific procedure.

Before replacing live data, decide which newer changes must be preserved and who can approve the operation. For a busy store, a complete older database can omit newer orders. Identify the required recovery point and a rollback path before an administrator performs the live restoration.

• Record the data to protect and the acceptable loss window.
• Confirm the selected schedule, retained restore points and actual backup scope.
• Keep complete files, database and configuration sets with identifiable dates.
• Store an independent protected copy and verify who can access it.
• Test a restore separately, with live integrations disabled, and update the written recovery steps.