As the hosting operator, guide your customer through requesting a manual snapshot from their active PD AWS SQL Server service before planned application work. An RDS snapshot covers the instance rather than a single application database. Confirm the correct instance first, then allow AWS to finish creating the snapshot before relying on it.

Customer steps: request a manual snapshot

1. Open the intended customer service and confirm its database and region.
2. Open Snapshots from the service’s navigation.
3. Choose Take snapshot and read the confirmation.
4. Confirm once, then follow the request in Activity.
5. Return to Snapshots and check the new snapshot’s status and creation time.

A queued or accepted request is not proof of an available recovery point. Activity can show Done when AWS has accepted the snapshot operation; the snapshot can still be creating. Avoid requesting more copies while the original action is pending.

Distinguish manual and automated backups

RDS listings can contain automated backups as well as manual snapshots. Automated retention and manual-snapshot storage are separate considerations. Manual snapshots can incur provider storage charges, so retain the copies the application needs rather than creating repeated copies to test a button.

An empty list can also be a read failure, and the displayed results are not a complete inventory of every recovery point. Check the original service, backing and region against the snapshots in your AWS account before assuming no backup exists or creating more copies.

Plan the recovery workflow

The customer snapshot page does not offer Restore or snapshot export. SQL Server also does not support AWS’s native RDS snapshot-to-S3 export feature. Read the SQL Server recovery-planning guide before changing the original database; a snapshot is useful only when the administrator can restore and verify it. Keep any required recovery point intact.

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