I terminated the wrong instance on Oracle Cloud Infrastructure last week. Not a test box — the Alpine Linux Ampere A1 VM I'd spent an afternoon getting exactly right, with a custom image import, cloud-init wired for SSH key injection, and a handful of small config decisions I hadn't written down anywhere. One click in the console, one confirmation dialog I read too quickly, and it was gone.
Or so I thought. This is the writeup of what actually happens when you terminate an OCI instance, why the boot volume usually survives it, and how I got the box back without rebuilding from scratch.
The instance is not the disk
The thing that saved me is a distinction OCI is quietly good about: the compute instance and its boot volume are separate resources. Terminating an instance destroys the compute side — the vCPU and memory allocation, the running kernel, the network attachment — but by default it does not delete the underlying boot volume unless you explicitly tick "permanently delete the attached boot volume" in the termination dialog.
I hadn't ticked it. I just hadn't realized that mattered until I went looking for the volume afterward and found it sitting in the Block Storage console, detached, intact, and quietly waiting for something to attach it to.
The recovery: spin up a new shell, swap the disk in
The fix ended up being a boot volume swap rather than a restore from backup, which was faster and didn't need a snapshot to exist:
- Launch a new compute instance on the same shape (Ampere A1, in my case) using any throwaway boot volume — this is just a shell to attach the real disk to.
- Once it's running, detach that throwaway boot volume.
- Attach my original, surviving boot volume to the new instance as its boot volume.
- Boot the instance against the original volume.
The part that actually needed care was making sure the new instance's launch options matched what the original volume expected. Ampere A1 shapes are ARM-based and use UEFI boot with paravirtualized network and disk drivers — if the new shell instance was configured with a mismatched firmware or driver mode, the swapped-in volume would either fail to boot or come up without networking. I made sure the replacement instance used the same UEFI boot mode and paravirtualized attachment type as the original, and the volume came up clean.
Cloud-init didn't need to run again
One pleasant surprise: because cloud-init had already run once on that boot volume — injecting my SSH key, setting the hostname, writing the initial network config — none of that needed to happen again. The volume already had a working /home, working authorized_keys, and all the packages I'd installed. The new instance shell was just a body for the disk to live in.
The instance is disposable. The volume is where the actual server lives.
What I'm doing differently now
A few habits changed after this:
- I take a manual boot volume backup before any change I'd call "structural" — not for every reboot, just before the ones I'd hate to redo.
- I read the termination confirmation dialog in full, every time, regardless of how many times I've clicked through it before.
- I keep a short README next to each instance's notes describing exactly what shape, image, and boot options it needs, so a swap like this doesn't involve guesswork under stress.
None of this is exotic. It's the kind of thing you only build the habit around after it costs you an afternoon.