Deleting an old backup can be sensible housekeeping. Deleting the last useful recovery point can turn a manageable failure into a rebuild. Age, size and an “available” status do not tell you which situation you have.
Start with the recovery need: what would you have to restore, how much recent work could be lost, and how long could the website be unavailable? Write those answers in ordinary language. They give you a reason to keep or retire a particular copy.
1. Identify the snapshot type and retention behaviour
Manual Lightsail snapshots remain until deleted. Automatic instance and disk snapshots follow a different lifecycle; disabling their schedule retains existing copies. An automatic snapshot must be copied to a manual snapshot before direct export to EC2. See the manual and automatic snapshot guidance.
Deleting the source resource is another operation with different consequences. AWS documents keeping automatic copies as manual snapshots when they must survive source deletion in its automatic snapshot configuration guide. Do not apply instance and disk behaviour to managed database backups without checking that product separately.
Record the source, recovery date, snapshot type, owner and retention reason. “Before upgrade” is useful only if you know which upgrade and whether that recovery point is still required. Ask the business owner about contractual retention before technical cleanup.
2. Check what an export actually produced
A Lightsail instance snapshot export creates an EC2 Amazon Machine Image, or AMI, and EBS snapshot storage. Attached disks can produce additional snapshots. A disk-only export has a different result. AWS describes these relationships in the export guide; inspect the completed export and its actual destination resources.
| Stage | Relationship | Evidence needed |
|---|---|---|
| Lightsail manual instance snapshot | Source for an EC2 export | Correct recovery date and complete source scope |
| Successful export | Creates a separate AMI and EBS snapshot(s) | Destination identifiers and completed export |
| EC2 AMI | Refers to backing EBS snapshot(s) | Every required backing snapshot remains available |
| Restored application | Needs disks plus database, uploads and configuration | Isolated test and recorded recovery time |
| Retirement decision | Applies to the Lightsail copy only | Retention owner approves this exact copy’s removal |
This fictional chain shows dependencies, not an instruction to delete each item in order. The EC2 image depends on its backing snapshots. The exported resources are distinct from the Lightsail source copy, but that does not prove independence from account access, a region failure or missing application data.
3. Check that the recovery set is complete
A server image may not contain the database or media if those live elsewhere. List the pieces required to rebuild the service: data, uploads, configuration, access, certificates and encryption keys where applicable. Check that their recovery points work together.
Think about the person doing the recovery. Can they obtain the necessary access if the normal server or administrator is unavailable? Can they understand the instructions without relying on an undocumented setting? A recovery set is less useful when the only working instructions live on the failed machine.
Do not call an export an independent backup merely because it appears under another service. Decide which failure you are protecting against and check whether the copy would survive it. Record any remaining shared dependencies rather than hiding them behind a green status.
4. Restore before you rely on the replacement
Plan an isolated restoration. Prevent the recovered application from sending real customer email, processing payments or running production jobs. Establish how access and test data will be controlled before starting it.
Check more than the home page. Open representative records and original media, exercise the important application journeys, and verify that required background work can run safely. Record which recovery point was used, what was tested, how long it took and what failed.
A successful test is evidence for that recovery route at that time. Keep the limitations: a small sample does not prove every file is intact, and a later application change can invalidate old instructions. Agree when another test is due.
5. Approve one specific disposal decision
Write down exactly which Lightsail copy is being retired and which retained recovery set replaces it. Keep the tested EC2 AMI and required backing snapshots out of that disposal list. AWS treats Lightsail snapshot deletion as permanent.
EBS has separate deletion rules, including restrictions for snapshots backing registered AMIs. Its snapshot deletion documentation also explains why removing an incremental snapshot may not reduce stored-data charges as much as expected. Do not deregister a working recovery image simply to clear a deletion error.
After an authorised cleanup, confirm the intended copies remain and review the relevant storage usage. Estimate savings from billable storage, not the number of snapshot rows removed. Record disposal and the next retention review together.
What can go wrong?
An export can be successful while application restoration fails. A fresh backup can faithfully preserve already-corrupt data. A recovery image can lack an external database. These are different failure modes, so “there is another copy” is not enough detail for approval.
Proceed, investigate or keep?
- Proceed: retention permits deletion, the complete replacement recovery set has been tested, and the owner approves the named copy.
- Investigate: an export exists but its backing storage, data coverage or access has not been checked.
- Keep: the copy is the only required historical recovery point or a retention obligation still applies.
For another example of checking recovery rather than just storage, read why Git history needs a restore test.
Continue the AWS review
If you are reviewing your website’s hosting, tell AceMedia Host what you need.