Nightly backups, and snapshots you can roll back.
Every instance is archived nightly. Before a migration, a package upgrade, or a deployment you are not sure about, you can take a snapshot yourself and roll the server back to it if the change goes badly. Both come with the instance, and both restore from the dashboard without opening a ticket.
Two tools for two different bad days
A nightly archive covers the day that goes wrong on its own: a bad write, a deleted directory, a service that quietly corrupted its own state overnight. A snapshot covers the day you go wrong on purpose, when you are about to change something and want a way back. Different problems, so they are different tools.
Nightly backup archives
Every instance is archived nightly. There is no schedule to build, no agent to install, and no policy to write before the first archive exists, because the archive belongs to the instance rather than to a product sold beside it. Each one appears in the dashboard when it completes, which matters more than it sounds: a backup nobody can see is a backup nobody can confirm, and the usual way people find out theirs stopped running is the morning they need it. Here you open the list, look at what is there, and know instead of assuming. Anyone you have given the view permission can do the same without being able to change anything.
Snapshots on demand
A snapshot is a point you take yourself, at the moment you choose. Take one before a migration, before a package upgrade that touches something load bearing, or before a deployment you would describe as probably fine. If the change goes the way you hoped, delete the snapshot and carry on. If it does not, roll the server back to the point you took and try again knowing what you know now. Snapshots are discrete points rather than a continuous stream, so the habit worth building is taking one immediately before the thing you are unsure about, while the state you want back is still the state you have.
Most teams end up using both without thinking about it much. The nightly archive runs whether or not anyone remembers it exists, and the snapshot is the small piece of care taken before a change with a bad worst case. Neither is a tier upgrade, and neither is a separate product to shop for. Both come with the instance.
Restoring is something you do, not something you request
A restore is a control in the dashboard. You do not file a ticket, wait for someone on our side to read it, and then find a window that works for both of us. If you hold the permission, the control is there, and it behaves the same on a Tuesday afternoon as it does on a Sunday night.
Choosing the target is the part people skip. Restoring in place puts the server back the way it was, which is the right move when you already know what broke. Bringing the archive up separately gives you something to look at first, which is the right move when you are not certain the point you picked is clean, or when the instance you would be writing over is still serving traffic.
Then verify before you move traffic. Bring the services up, check the data you expect to be there, and point production at it once you have looked. Running the restore is the easy part. Knowing you restored the point you meant to is the part worth spending time on.
- Step onePick the recovery pointThe list keeps nightly archives and hand-taken snapshots apart, so you are choosing a point rather than guessing at one.
- Step twoChoose the targetRestore in place over the instance, or bring the archive up separately and look at it before anything depends on it.
- Step threeVerify, then move trafficStart the services, check that what you expected to be there is there, and point production at it once you have seen it for yourself.
Four separate permissions
Backups and snapshots are governed by four permissions rather than one. Seeing what exists is separate from acting on it, and acting on a snapshot is separate from acting on a nightly archive.
View backups
See the nightly archives that exist for your own servers. This is the permission most of a team should hold, because checking whether the archive from last night landed is something anyone on call may need to do at any hour, and doing it changes nothing.
Restore from backup
Write a nightly archive back to one of your servers. This is the destructive one. It replaces the instance as it stands right now, so it belongs with the people you would want making that call under pressure, and with nobody else by default.
View snapshots
See the points that have been taken on your own servers and what they were named. This is a read and nothing more: someone can confirm a snapshot is in place before a deploy goes out without holding the ability to take one, delete one, or roll a server back to it.
Manage snapshots
Take a snapshot, delete one you no longer need, and roll a server back to one. A developer holding this and nothing else can protect their own deployment without holding the ability to restore production over the top of itself.
The split is there because the four actions carry different consequences. Taking a snapshot before a deploy is routine and reversible. Writing an archive over a running production instance is neither. A permission model that bundles them hands the second one to everybody who needed the first, which is how an afternoon deploy turns into an incident that began as a precaution.
Every restore is a logged action attributable to a person, alongside the rest of the human actions and security events on the platform. When someone asks what happened to this server last night, the answer is a log entry with a name on it rather than a question in a group chat.
Who can do what
Permissions are granted per person, so the shape of a team maps onto them directly. Someone answering the question of whether the archive from last night exists gets the view permissions and stops there. The developer shipping the release gets snapshot management, so the precaution before a deploy is theirs to take and theirs to undo. Restoring from a backup stays with the smaller group who should be deciding to overwrite a production instance.
None of this needs a role we invented for the occasion. It is four permissions, granted to the people who need them, sitting in the same place as the rest of the access in your organization.
- Viewing backups for the people who need to confirm an archive exists
- Managing snapshots for the people shipping changes
- Restoring from backup for the smaller group who should decide to overwrite an instance
- Every restore attributable to the person who ran it
Where the copies live
On infrastructure we own and operate. Both of our facilities are in Des Moines, Iowa. US Central 001 carries production. US Central 002 is the recovery site, running the same hardware and the same network, so a failover does not change how your workload behaves. Both buildings carry redundant power and cooling, and both sit under the 99.5% uptime SLA that covers our cloud and dedicated services.
That is site redundancy, and site redundancy is what we call it. Two buildings in one metro is not geographic separation, and describing it that way would make for a nicer sentence than a true one. If your compliance position calls for a copy in another region, instances use standard exportable disk images: pull one down and keep it wherever that requirement points.
Questions we get asked
Do I need to turn backups on?
What is the difference between a nightly archive and a snapshot?
How long is a nightly archive kept?
Do I have to open a ticket to restore?
Can a developer take a snapshot without being able to restore production?
Who can see that a restore happened?
Where do the copies live?
Do backups and snapshots cost extra?
The rest of what this sits on
The instances these archives belong to, the monitoring that tells you something is wrong before you go looking for a recovery point, and the two buildings all of it runs in.
The worst time to learn your backup process is during an outage.
Bring up an instance that does not matter yet, break it on purpose, and walk through a restore with one of our engineers while nothing is at stake. You find out what the process asks of you, and how long your own verification takes, on a day when the answer costs nothing.