Backups and storage

Before you start

Use Storage in the company that owns the site. You need a connected WordPress install and an owner account to manage backup destinations. Downloading a complete backup requires recovery permission and a recent Hub sign-in. If a control is unavailable, check your company and role before asking the company owner for access.

A retained recovery point is a captured version of the site. A scheduled client copy sends a complete backup to your own storage. WordPress audit exports are separate: connecting audit exports does not connect full backups.

Check your site's protection

1. Open Storage and read the protection summary and last recoverable time.
2. Find the site in the per-site storage list. Check its usage and recovery status.
3. Review available quota and recent backup jobs. An old recoverable time does not prove that newer changes are saved.
4. If no complete point is available, resolve the reported capture or connection problem before relying on a download.

Expected result: you know which site and capture time you can recover, and whether new backups need attention.

How retained points use allowance

Each retained recovery point uses allowance, even when it captures the same site or reuses unchanged file content. Several retained points are separate recoverable versions, not one point charged repeatedly by mistake.

When a point expires or is deleted, its charge is released once. Other retained points and captures already in progress keep their own allowance. Releasing a point's allowance does not mean shared file content is removed while another retained point still needs it. Copies in your own Google Drive or S3 destination have their own retention schedule.

Files included in complete-site capture

Complete-site capture keeps plugin, theme and vendor runtime code, content-root drop-ins and custom runtime folders. Declared generated-cache exclusions are wp-content/cache/, wp-content/upgrade/, and MetForm's generated icon cache at uploads/metform/cache/icons/. MetForm rebuilds that icon cache from its bundled JSON; its other uploads remain included.

The uploads root's WooCommerce logs, version-control metadata and protected secret paths are also excluded by default. A folder named cache is not excluded merely by its name: plugin and theme runtime code, vendor source such as vendor/psr/cache/src/, and ordinary uploads remain included. Outside these declared exclusions, a file that changes or disappears can still fail capture; a failed capture is not a complete backup.

Schedule a Google Drive copy

1. In Storage, find Connect or update a destination and its Google Drive form.
2. Choose the site and give the destination a useful name, such as Store backups.
3. Choose an app-created My Drive folder, an existing My Drive folder, or a Shared Drive folder.
4. Choose the interval and Retain complete copies count.
5. Select Connect Google Drive, sign in to the intended Google account, and complete the folder selection.
6. On returning to Hub, confirm the site and select Save Google Drive connection when prompted.
7. Check Scheduled client copies for the saved schedule and the next delivery result.

A saved connection is not a completed backup. Confirm a successful copy at the destination before relying on it.

Schedule an S3 copy

Have a private bucket, its region, and credentials permitted to use that destination ready. For an S3-compatible provider, also obtain its public HTTPS endpoint.

1. In the S3-compatible storage form, enter a destination name and choose the site.
2. Set the interval and retained-copy count.
3. Enter the bucket, region, and optional prefix. Leave the endpoint empty for Amazon S3, or enter your provider's HTTPS endpoint.
4. Enter the access key, secret access key, and optional session token only into the form.
5. Select Save S3 destination and check the saved schedule.
6. Confirm a successful delivery and the resulting private object in your storage account.

Example: a daily schedule retaining seven complete copies keeps a rolling set of successful copies. It does not promise seven calendar days of coverage when deliveries fail.

Change or reuse a destination

Under Destinations, use Apply to selected sites to reuse a connection. Review the result: a busy site can be deferred until its current delivery finishes. Moving a site changes where future copies go; existing copies remain at the old provider and Awthy stops pruning them there.

In Scheduled client copies, change the interval or copy count and select Save schedule. Use Pause to stop scheduled work, Resume to restart it, or Retry after resolving a reported failure. Revoked credentials require reconnecting or replacing the destination credentials before resuming.

Disconnect every site using a destination before deleting it. Deleting a destination removes Hub's saved credentials; copies already at the provider remain there. Keep your last verified archive while troubleshooting.

Download a complete backup

1. Open Recovery in Hub after signing in recently.
2. Under Download a complete backup, check the site name and capture time.
3. Select Download complete backup for that point and allow the download to finish.
4. Store the original archive in a private folder accessible only to the restore operator.
5. Follow Restore a WordPress site to validate and use it.

A complete WordPress backup requires site files, database content, and portable configuration when the capture requires it. Missing DNS, mail, server configuration, or external-service backup evidence is a restore warning; it does not block the download. Those services need separate recovery. Missing required site content, including unprotected offloaded media, still blocks a complete backup. Capture metadata keeps the external-service warnings without claiming those services were backed up. Treat it as sensitive site data. Do not email it or attach it to support tickets.

Names follow awthy-backup-<site>-YYYYMMDDTHHmmssZ-<12hex>.tar.gz. The timestamp is the capture time in UTC. Renaming a site or destination does not rename an existing point's archive.

If a copy or download fails

Check the displayed error, destination authorization, site connectivity, and available recovery point. Sign in again if Hub asks for recent authentication. A partial, expired, revoked, or corrupt point cannot become a complete backup by retrying its download.

For support, provide the site host, point time, job reference, and displayed error code. Never provide provider credentials, archive contents, session cookies, or recovery links. A failure in one destination does not prove that another destination's copy failed; check each result.

Retry a failed database step

For an operator with authorized WP-CLI access, wp awthy recovery database status CAPTURE_UUID shows the database step's safe status and failure code. After fixing the reported cause, run wp awthy recovery database retry CAPTURE_UUID. It retries only a failed or partial database step whose file capture is complete; it preserves the completed file backup. A failed or incomplete database step still prevents a complete backup download.

For a slow capture, use wp awthy recovery capture status JOB_ID --format=json. Its Hub summary includes bounded client phase timings, request timings and storage counts. These timings overlap; native helper lifetime and upload request time must not be added to the top-level elapsed phase total.

For mixed InnoDB/MyISAM databases, a complete capture requires the database user's LOCK TABLES privilege. Awthy holds bounded read locks on the nontransactional tables while its separate dump connection takes the InnoDB snapshot. Writes to those legacy tables wait during the export; backup progress and cancellation remain writable. Without that privilege, the copy remains partial and cannot be downloaded as a complete backup.