As the hosting operator, plan your customer’s graph-database recovery before a PD AWS Neptune service needs it. Establish the recovery point, the destination and the application cutover. The customer Snapshots page does not offer an in-place Restore control.

Confirm the recovery point

Identify the original service, AWS region, cluster and required point in time. Ask the administrator to verify an available manual snapshot or automated recovery point. Normal module provisioning requests seven-day backup retention; confirm the actual retained backups before relying on that window for an existing service. The AWS service’s default and a particular module-created cluster’s settings are not interchangeable.

Preserve the original cluster and the required snapshots while planning. A missing customer-list entry does not prove there is no backup. Keep the snapshot name and verified creation time with the service reference, and avoid repeat creation or removal requests while the original outcome remains uncertain.

Prepare a new cluster and compute

AWS snapshot restoration creates a new Neptune cluster, rather than overwriting the existing one. The administrator must add the required compute instances after the restored cluster becomes available. Custom parameter and security-group settings also need deliberate review; restoration is not proof that the original application access model was reproduced.

The module’s customer actions do not expose Restore, point-in-time recovery or native snapshot export to S3. Use the administrator’s supported AWS recovery workflow. Keep the intended private network access, TLS and any configured IAM database authentication in view before testing the destination.

Coordinate service tracking and cutover

A separately restored AWS cluster is not automatically attached to the original billing service. Record the source and destination separately and establish how the restored cluster will be managed before changing module settings or retiring the source. Another Create request does not attach a separately restored cluster to an existing service. Verify the recovered graph and intended Gremlin, openCypher or SPARQL interface privately, along with network access and application authorisation. Then plan the endpoint change and check the application’s result.

Keep the original service, recovery-point reference and required time alongside the observed destination result. Do not look for a database-password reset: the module creates no master database login.

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