Approve a Destructive Remediation Without Losing Data

Some remediations cannot be undone. Deleting an unattached volume or removing an orphaned resource are one-way actions, and a wrong one costs more than the saving it chased. ZopNight puts an approval gate in front of destructive remediations started by non-admins. This page is the reviewer’s side: what to look at, what to do natively before you click approve, and how to reject cleanly.

How the approval step fits

A remediation runs as a short workflow in the Remediate wizard: a precondition check, an optional approval step, the cloud action itself, then validate. For destructive operations the approval step is an admin gate: when a non-admin starts the remediation, it waits for an admin. Guided remediations add a type-to-confirm review before anything runs.

When a remediation is waiting, the approver gets an email with the subject “[ZopNight] Remediation approval needed”, and a channel subscribed to remediation events gets the approval-required message. The email is not re-sent if the workflow is replayed.

1. Read what the precondition captured

Open the pending workflow. Confirm the resource ID, account and region match what the requester intended, and that the recommendation’s evidence (the metrics or properties that fired the rule) still describes the resource today. A volume that was unattached last week may be attached now.

2. Check the blast radius

Choose View Blast Radius from the recommendation. The canvas highlights the target and every directly connected resource, classed as affected, warning or safe for the operation, with a 0 to 100 risk score. For a delete, anything classed affected loses something: a member of the target, a trigger that stops firing, or data on a database target. The check covers one hop of connections inferred from metadata, so treat it as a floor, not a full dependency map. Details are in checking blast radius before you remediate.

3. Take a native backup before approving a delete

The approval gate does not snapshot anything for you. If there is any doubt about the data, take one yourself first.

On AWS, for an EBS volume:

aws ec2 create-snapshot --volume-id vol-0abc123def4567890 \
  --description "pre-remediation backup, ticket OPS-1432"
# Use the SnapshotId returned by the create-snapshot command above.
aws ec2 wait snapshot-completed --snapshot-ids snap-0123456789abcdef0

The waiter polls every 15 seconds until the snapshot’s state is completed. On Google Cloud, for a persistent disk:

gcloud compute snapshots create pre-remediation-data-disk \
  --source-disk=data-disk-1 --source-disk-zone=us-central1-a \
  --description="pre-remediation backup"

Record in the description or ticket why the snapshot exists and when it can be removed, so it does not outlive its purpose.

4. Approve or reject

Approve to let the cloud action run, or reject with a reason so the decision and its grounds are recorded against the workflow. Reject when the evidence is stale, when the blast radius shows affected neighbours nobody has explained, or when the owner has not been asked.

5. Read the result

After execution, the validate step checks the outcome. If the action fails, the wizard shows one of three categories:

• User action (yellow): a permission or quota problem, with a fix hint and a console link.
• Transient (blue): throttling or a 5xx from the provider; this is the only category offered a retry.
• System (red): an unsupported API; copy the diagnostic and contact support.

What the gate never covers

ZopNight’s pause template excludes customer databases outright (RDS, Aurora, Cloud SQL, ElastiCache, Azure SQL, PostgreSQL and MySQL types), so those never reach this approval step through a pause. Remediation needs the cloud account connected with read + write access; on a read-only account, remediations are blocked server-side before any cloud call. For turning remediation on in the first place, see running one-click remediation.