As the hosting operator, plan recovery for your customer’s database before a PD AWS Oracle service needs it. The administrator needs a usable RDS recovery point, a verified destination and a deliberate application cutover; the customer snapshot page is not an in-place Restore control.

Establish the recovery point

Identify the original service, AWS region and database. Record the required point in time and confirm that a usable manual snapshot or automated recovery point exists. Normal RDS provisioning requests seven-day automated retention. Verify the actual retained backup state before relying on that window for an existing database.

Do not infer that a missing customer-list item means there is no backup. Ask the AWS administrator to check the provider’s recovery points. Preserve the original database and any required snapshots while planning the recovery.

Use the administrator’s RDS workflow

RDS restoration from a snapshot creates a new DB instance; it does not overwrite the original database in place. The module’s customer controls do not include Restore or point-in-time recovery. The administrator must use the appropriate AWS workflow and verify the resulting instance.

Oracle is also excluded from AWS RDS snapshot-to-S3 export. Do not treat another engine’s snapshot-export instructions as an Oracle backup procedure.

Coordinate the destination and cutover

A restored AWS resource is not automatically adopted by the original billing service. Record the source and destination separately and establish how the recovered database will be managed before changing module settings or retiring the source. Do not press Create again as an attempt to attach a separately restored resource. Privately verify the destination’s network access, working credentials and recovered application data, then plan the application connection change. Keep the original service and recovery-point references with the observed recovery result.

See the PD AWS Oracle Blesta guide for related tasks, or explore PD AWS Oracle.