Reactivate the original terminated storage service when correcting an accidental termination, provided its required data remains. A new order is not an automatic attachment to the original bucket.

Establish the retained state

1. Identify the original service and its tracked backend and buckets.
2. Open PD Object Storage → Retention and put the relevant pending purge on Hold.
3. Inspect Activity and the recorded state for any purge already started.
4. Establish which required objects and versions remain.
5. Keep the original account/backend wiring and any independent recovery copy available.

A purging or purged service is not a retained-data recovery promise. Hold cannot reverse earlier deletion. Check the original service’s retention and purge state before changing account credentials or provisioning another order.

Reactivate the original service

After reviewing the service and payment decision, open its WHMCS service record and use the supported module Create action to reactivate retained terminated storage. Restore the billing status deliberately as part of the review; editing status alone does not establish module reactivation.

Inspect the original result and Clients & Storage. Reactivation issues fresh service credentials. Update dependent applications with the current returned details rather than expecting revoked credentials to work again.

Verify application recovery

Check the original backend, bucket, placement and expected data. Verify the application’s required operations and recovery path. A successful billing change or an empty current-object list does not establish that every historical version is present.

If reactivation fails, check the original service’s Activity result and retention state before another attempt. Do not use purge as a reset.

See the PD Object Storage WHMCS guide for related tasks, or explore PD Object Storage.