Inspect retained data before taking recovery action after a PD AWS S3 service has ended. Retention can preserve an opportunity to recover; inspect whether the required objects and versions still exist.

Confirm the current recovery point

Identify the original service, AWS account, region and required buckets. Review Retention and Activity immediately. If a purge has started or failed part-way, some data may already be gone; do not assume Hold rolls it back.

Follow this platform’s workflow

1. Open Retention and put the intended service on Hold while reviewing recovery.
2. Confirm the module state is terminated, not purging or purged, and the required buckets still exist.
3. Use the original service’s supported module Create/reactivation workflow, keeping the intended account and service identity.
4. Inspect Activity and Clients & Storage for successful reactivation.
5. Retrieve the fresh service keys and update applications.
6. Verify the original primary and extra buckets, required data and access state.

The module recognises the original retained terminated service and reissues scoped credentials rather than provisioning unrelated new storage. Successful reactivation stops its purge countdown. A new order with another service identity is not the same operation and does not automatically adopt the old bucket.

Verify before releasing old storage

Check required object versions and application restore needs, not just bucket existence. If a separate copy was made, confirm its completeness and test the intended application’s recovery before releasing the old purge.

Do not create duplicate orders, delete buckets or run guessed server repairs to bypass a failed recovery. Retain the service references, original action time and redacted result while your hosting team checks the actual recovery stage, without secrets or customer file contents.

Check the recovered service

Your hosting team and AWS administrator should compare the original service identity, account/region, saved Hold, current module state and actual retained buckets/data with the original reactivation result. Fresh credential issuance is not a completeness check for the required objects or versions. A failed later access-policy step can follow changed keys; inspect the actual credential/access state before another attempt.

See the PD AWS S3 WHMCS guide for related tasks, or explore the module.