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 original cancelled service’s purge on Hold.
2. Confirm its module state is terminated, not purging or purged, and that the required buckets, objects and versions still exist.
3. Open that original cancelled service in Blesta and use Uncancel, keeping Use module enabled so the storage operation runs too.
4. Inspect Activity and Clients & Storage for successful reopening of the original storage and a stopped purge countdown.
5. Retrieve the fresh service credentials, update the connected applications and verify the required data and access mode.

The released Blesta integration supports Uncancel. For this original retained service, it calls the module’s create workflow, which recognises the terminated storage and reissues credentials for its existing buckets. Using Uncancel without the module changes the billing record without reopening storage. A new unrelated order does not automatically adopt the retained buckets, and Uncancel cannot restore objects already purged.

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 Blesta guide for related tasks, or explore the module.