Take an ElastiCache snapshot in Blesta
As the hosting operator, guide your customer through requesting a manual snapshot from their active PD AWS ElastiCache service when the application needs a recovery point. This guide covers the module’s node-based cache offering; confirm that backups are supported for the actual node type and service before relying on them.
Prepare the snapshot
Coordinate the timing with the application owner. AWS explains node-based backup considerations: taking a backup can affect performance when available memory is limited. The module normally provisions one primary node, so do not assume a separate replica will absorb the backup work.
Customer steps: request and verify the copy
- Open the intended active service and confirm its cache and region.
- Choose Snapshots from the service navigation.
- Choose Take snapshot, read the confirmation and confirm once.
- Follow the request under Activity.
- Reopen Snapshots, identify the new snapshot by name and check that its status becomes available.
A queued or accepted request is not an available backup. Avoid requesting repeated copies while the original operation is pending. Keep the snapshot name with the request time so your hosting team can verify the intended recovery point.
Review names and dates carefully
Lists can contain manual copies and automatic backups. Do not identify a recovery point by the displayed date alone. If several snapshots show an identical old date or a date inconsistent with the request, your hosting team should compare the snapshot name and actual time in AWS before relying on it. An empty list can also reflect a read failure or incomplete listing.
The customer page does not provide Restore. Read the cache recovery-planning guide before changing the original service, and keep the recovery point the application needs intact.
See the PD AWS ElastiCache Blesta guide for related tasks, or explore PD AWS ElastiCache.