Restore¶

This page describes how to get data back from a backup. How backups are taken, and how to see which backups exist, is described in Backups.

There are three ways to restore, depending on the service and on what you need:

Self-service restore in the portal, for services that support it. Described on this page.
Direct access to your backups, if you want to extract a single file or a dump, or restore a copy outside Servala. See direct access to your backups.
Support, for everything else. Include the instance and, if you want a specific backup, its Name exactly as shown in the backups list. See Get Support for how to submit the request.

Self-service restore¶

Where a service supports it, organization administrators and owners can restore from a backup themselves, without opening a support request.

A restore creates a second instance

A restore never overwrites an existing instance and never changes its data. It creates a new instance next to the source, started from the source instance's backups. The source keeps running and keeps its data, and both instances are billed from that moment on. Switching over is yours to do, and so is deleting the instance you no longer need.

Who can restore¶

Only Administrators and Owners of the organization. Members see the Restore button disabled with a note asking them to contact an organization administrator.

Every restore is recorded in the organization audit log with who started it, which instance it came from, and which restore point was used.

Starting a restore¶

Open the instance you want to restore from, then either:

click Restore in the Backup Summary card, or
expand the Backups section and click Restore from here on a specific row. The row action preselects that backup as the restore point.

The Restore button appears only for services where self-service restore is available and where there is at least one backup to restore from. When a restore is not currently possible, the button is shown disabled together with the reason. The usual reasons are:

the instance is paused (resume it first),
the instance is still being provisioned and has nothing to restore from yet,
the organization has reached its maximum number of service instances, since a restore needs a free slot for the new instance,
the instance backs up into a backup bucket of your own, which the portal cannot restore from,
the backup list could not be read from the control plane at that moment.

The restored instance is always created in the same organization and the same zone as the source. There is no target to choose.

Choosing the restore point¶

How you pick a restore point depends on what the service can do. The portal shows the variant that applies to your service.

Point in time¶

For services that archive their changes continuously (databases with a write-ahead log, for example PostgreSQL), you choose between:

The latest available state (the default): everything up to the most recent point the archive covers.
A specific point in time: a date and time you enter yourself.

Any moment inside the retention period can be chosen, not only the moments at which a backup ran. This is what makes it possible to recover to the minute before an accidental DELETE.

The restore point is entered in UTC

The picker is labelled Point in time (UTC) and the value is read as UTC, not as your local time. The backups list shows timestamps in your local time zone, so convert before you type. Getting this wrong recovers to the wrong hour without any error.

The portal shows the oldest backup it knows about as "Backups available from … (UTC)" for orientation, but it cannot see how far the archive really reaches. A timestamp outside the covered window is accepted by the form, and the restored instance then comes up with unexpected data or fails to start. Check the window before you submit.

A named backup¶

For services whose backups are individual snapshots, you pick one entry from a dropdown of the backups that exist, labelled with their time and name. There is no "latest" option and no free point in time: the restore is started from exactly that backup, so it is only possible once at least one backup exists.

The restore form¶

Below the restore point, the form is a complete copy of the source instance's configuration, and every field can be changed before you submit. Starting from the source's configuration matters, because a restore into a smaller disk or a different version will fail the restore.

A few things to check before submitting:

The name. The display name defaults to the source's name with (restored) appended. Change it if you want something else.
The address. Fields that cannot be shared with the still-running source, such as the instance address (FQDN), are reset to their default. The restored instance gets its own address.
The version. Leave the major version as it is. The restore looks for the archive belonging to the version of the new instance, so changing it here surfaces much later as "no backups found" instead of as an error on the form.
The compute plan. The plan and service level of the source are preselected.

Where a service has something specific to say about its restores, the portal shows that note on the restore page.

After the restore¶

The restored instance provisions like any other instance, and its status card, pods, and events show the progress. There is no separate restore progress view.

Both instances show the relationship on their detail page in a Restore card:

the restored instance shows Restored from, with the source instance (linked), the restore point used (or "the latest available state"), and the next steps,
the source instance shows how many restores were created from it, each linked.

Once you delete the source instance, the restored instance keeps the name of its source and the restore point under Metadata.

Switching over¶

The portal does not switch your application over and does not touch the source instance. Once the restored instance is running:

Verify that the restored data is what you expected.
Point your application at the restored instance's own connection credentials. The address, the username, and the password are its own, so read them from its detail page rather than reusing the old ones.
Delete the instance you no longer need, to stop paying for it. See Manage Instances.

Do not delete the source instance before you have verified the restore: until then it is the only copy you know to be good.