Final snapshots before deleting

Deleting an instance or a managed database destroys data at your cloud provider. A final snapshot is a safety copy taken first: Sencai asks the provider for the snapshot, waits until it is complete, and only then deletes the resource. If the snapshot cannot be made, nothing is deleted.

This page covers what is snapshotted on each provider, what is not and why, how an organization can make the snapshot mandatory, what it costs, and how to restore from one.

Taking a snapshot when you delete

When you delete an instance or a managed database, the delete dialog offers a final snapshot. Tick it and confirm. The resource moves to Terminating and stays there while the provider works; large disks can take from minutes to hours. When the snapshot is complete Sencai deletes the resource and you get a notification in the platform. If the snapshot fails, you get a notification with the reason, the resource returns to the status it had before, and nothing is deleted.

Imported resources are treated exactly like resources created in Sencai.

Deleting through the API or an AI agent works the same way: pass final_snapshot=true on the delete request. Without it, no snapshot is taken unless your organization requires one (see the organization policy).

Caution

A snapshot you did not ask for is not taken. If you delete without ticking the box, the provider’s own deletion rules apply and the data is gone.

What is snapshotted

Instances

For an instance, Sencai snapshots the disks that would be destroyed together with it.

Provider	What is copied
AWS	Every EBS volume that is deleted on termination. Instance-store volumes cannot be snapshotted; the record says so.
Google Cloud	Every disk that is deleted together with the instance
Azure	The OS disk and every data disk, because deleting the instance deletes all of them
Hetzner	A snapshot image of the server
DigitalOcean	A droplet snapshot
Vultr	An instance snapshot
Linode	An image of each disk. The instance is shut down first so the disks are consistent. If a disk is larger than the provider’s image limit, the snapshot fails and nothing is deleted.
Scaleway	A snapshot of each volume. Local volumes need the server powered off first, so the server is stopped before the snapshot.
OVHcloud	An instance snapshot
UpCloud	A backup of each storage device. The backups are kept when the server is deleted.
Oracle Cloud	A full backup of the boot volume. Attached block volumes are not deleted with the instance, so they are not copied.

Managed databases

Provider and service	What happens
AWS RDS	The database is deleted with a final snapshot taken as part of the delete
AWS Aurora	A cluster snapshot is taken first, then the instance is deleted
Google Cloud SQL	The database is deleted with a final backup
Oracle MySQL HeatWave	The database system is deleted with a final backup

Two kinds of managed database are not snapshotted:

• Read replicas hold no data of their own, so deleting one never needs a snapshot and is never refused for lack of one.
• Azure databases, DigitalOcean, Linode, UpCloud, Vultr and OVHcloud databases cannot be snapshotted (for UpCloud this means managed databases only - UpCloud servers are snapshotted, see above). These providers delete a database’s backups together with the database, and they offer no way to make a backup that outlives it. The delete dialog tells you so, and if your organization requires snapshots, deleting these is refused.

Not yet verified on a real account

A snapshot method is only offered where it has been proven against a real provider account. For now these are reported as unavailable, with the reason “not verified on a real account”:

• IBM Cloud instances
• Oracle Cloud PostgreSQL databases
• Scaleway managed databases

What is not snapshotted, and why

• Object storage (buckets and containers). Sencai never deletes data from object storage. Every provider refuses to delete a bucket or container that still holds objects, and Sencai passes that refusal on to you. A delete can only remove an empty bucket, so there is nothing to snapshot. Empty it yourself first if you really want it gone.
• Volumes. Deleting a volume in Sencai removes only the record in Sencai. It does not delete the disk at your provider, so no data is lost.
• Load balancers. They hold no data, so nothing is destroyed that a snapshot could save.

The organization policy

An organization can require a final snapshot for every deletion of an instance or managed database. Open Settings → Deletion safety (/gravity/settings/deletion-safety) and switch on Require a final snapshot before deleting instances and databases. Only people who may update the organization (Admin and Owner by default) can change it, and every change is recorded in the audit log.

When the policy is on:

• the snapshot box in the delete dialog is ticked and cannot be cleared;
• a delete through the API or an AI agent that does not ask for a snapshot gets one anyway, and one that explicitly declines is refused;
• deleting a resource whose provider cannot be snapshotted is refused with a message saying why, and nothing is deleted.

The policy applies to deletions by members, API keys and AI agents. It does not apply to:

• the deletion of resources on Sencai accounts after a non-payment, which removes the data on purpose and keeps only a description of what was deleted;
• the short-lived runner machines that Sencai creates and removes for CI.

Where the snapshots live and what they cost

Snapshots are created in your own cloud account, next to the resource they came from, and your provider bills you for storing them. Sencai never deletes a snapshot in an account you connected yourself; remove them in the provider’s console when you no longer need them.

On a Sencai account the snapshot sits in the Sencai-managed account instead. Sencai keeps it for 30 days after it is complete and then deletes it. Take a copy at your provider or restore within that time if you need it longer.

Two details specific to AWS RDS: Sencai always keeps the database’s automated backups when it deletes the instance, with or without a final snapshot. They expire by themselves at the end of the retention period you configured on the database (at most 35 days), which makes even a delete without a snapshot recoverable for that long. They are billed in your account like any other backup.

Finding and restoring a snapshot

Open Final snapshots (/gravity/final-snapshots) in the left-hand menu. It lists one row per snapshot request, kept after the deleted resource itself is gone:

• what was deleted, with its provider and region;
• the state: requested, snapshotting, completed, failed, or not needed;
• the provider’s identifiers for each snapshot, with a copy button;
• who asked for it and when it completed, and its size;
• whether it still exists at the provider.

Each snapshot has a link that opens it in your provider’s console. Restoring is done there, with the provider’s own tools: Sencai does not restore a deleted resource itself.

The terminating instance or database also shows the latest snapshot state in a banner on its detail page while the delete is in progress.

The daily check

Once a day Sencai asks each provider whether your snapshots still exist and how large they are. This is read-only and also runs for protected cloud accounts. If someone deleted a snapshot at the provider, the row shows deleted at provider and the check time, so you find out before you need it rather than after.

What’s next

• Provision and manage instances - create, resize and delete instances
• Import existing infrastructure - bring resources you already run under Sencai
• Sencai accounts - how resources on accounts managed by Sencai are kept and removed
• Permissions in depth - who may change organization settings