Key idea
A snapshot captures a service at one moment: its settings. Take one before a risky change, schedule one daily, and restore it to put the service back as it was, in the same environment or another.
Everything here is on the service's Backups tab. The console calls each snapshot a backup; they're the same thing.
Take one now
Choose Back up now. A row appears in the list marked PENDING, and turns COMPLETED when the snapshot is ready. Take one before a change to the service you might want to undo.
Put it on a schedule
Open the schedule
On the Backups tab, choose the settings icon (Schedule settings).
You should seeA Backup schedule dialog.
Turn on automatic backups
Switch on Automatic backups, then pick Daily at 2 AM from Quick presets, or type a Cron expression.
You should seeBackups run on the schedule below.
Save
Choose Save.
You should seeThe tab shows the schedule above the list.
A cron expression has five fields: minute, hour, day of the month, month, day of the week, in UTC. 0 2 * * * means 02:00 UTC every day. Pick a quiet hour for your users, which in UTC may not be 2 AM. A daily schedule means you can lose up to a day of changes (lesson 6.8.1); if that's too much, choose Every hour.
Restore
On a COMPLETED row, choose Restore. The Restore backup dialog warns that the service's settings will be restored and the service redeployed. Pick an option under Restore to:
| Restore to | Where it lands | Use it to |
|---|---|---|
| Same service and environment | Replaces the service you're on | Undo a bad change |
| Same service, different environment | This service, in another environment of this project | Copy production data into staging to reproduce a bug |
| New service | A new service, in the project and environment you choose | Look at old data without touching the live service |
Choose Restore. The service redeploys; the history icon (View logs) opens Restore logs, which show its progress.
A snapshot can't be restored in its first two minutes; wait, then try again.
What a snapshot doesn't hold
It covers the service's settings. A SphereFiles volume isn't in it: keep your own copies of its files (lab 6.8.4). A database isn't in it either: SphereDB restores its own to any moment in the last 7 days, and at another provider you restore with its backups (lesson 6.8.1), to the same moment if the two must agree. Files kept on the spherelet's own filesystem aren't in it either; they were never meant to last.
Check yourself