Backups & Restore¶

Servala automatically backs up your service instances where the service supports it. This page describes how backups work in general. Backup schedules, retention, and recovery capabilities can differ per service. See the relevant page in the Service Catalog for service-specific details.

How backups work¶

Automated schedule: backups are taken automatically on a regular schedule, without any action required from you.
Retention: backups are kept for a defined retention period that depends on the service and offering.
Point-in-time recovery: some services (for example databases) support point-in-time recovery in addition to scheduled backups.

Viewing your backups in the portal¶

For services where backup information is available, the instance detail page shows which backups exist and when they were taken. Where a service does not expose this information, the backup sections are not shown at all: backups still run as described above.

Backup Summary card¶

The Backup Summary card sits in the upper area of the instance detail page and answers the question "did a backup run, and when":

Last backup: when the most recent backup finished, shown in your browser's local time zone. For services that do not report a finish time, the start time is shown instead. Where the service reports a state, a status badge is shown next to it (for example completed in green or failed in red).
Schedule: when backups run, written out in plain language (for example "Daily at 23:30 UTC"). Backup schedules are expressed in UTC, while backup timestamps are shown in your local time zone.
Retention: how long backups are kept.
Available backups: how many backups currently exist.

Two states are worth calling out:

No backups yet: the instance exists but no backup has completed so far. This is normal shortly after provisioning.
Backup information is currently unavailable: the portal could not read the backup data at that moment. Use the refresh button in the card header to try again, and contact support if it persists.

Backups list¶

Expand the Backups section on the instance detail page for the full list, newest first.

The columns depend on what the service reports:

Name: the identifier of the backup. Note it down exactly as shown when you ask support for a restore: for several services this name is the handle the restore needs.
Type: whether the backup was taken by the schedule (Scheduled) or triggered manually (Manual).
Started and Finished: the start and end time, in your local time zone.
Duration: how long the backup took.
Status: the state the service reports for the backup.

Services that use more than one backup mechanism (for example one for file storage and one for the database) show a separate table per mechanism, each with its own schedule and retention.

Restoring from a backup¶

Contact support if you need to restore an instance from a backup. 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.

If you prefer to work with the backup data yourself, for example to extract a single file or to restore a copy on your own infrastructure, use direct access to your backups.

Direct access to your backups¶

Each instance stores its backups in a dedicated object storage bucket that belongs to that instance alone. For services where this is enabled, the portal can hand you the credentials for that bucket, so that you can browse, download, and restore backups with standard tooling. No backup data flows through the portal: you connect to the object storage directly.

This is intended for exit and compliance scenarios, for extracting individual files or dumps, and for restoring a copy outside Servala.

Where to find it¶

Expand the Backups section on the instance detail page. Below the backups list, a Direct backup access panel appears for each backup source of the instance (services with more than one source, such as Nextcloud with its files and its database, show one panel each). The panel always shows the non-sensitive connection details:

Endpoint: the URL of the object storage.
Bucket: the name of the bucket holding the backups.
Server name (PostgreSQL only): the archive prefix inside the bucket, tied to the current PostgreSQL major version.

The credentials themselves are masked until you reveal them. Click Reveal credentials, read the confirmation dialog, and confirm. The panel then shows the credential values with copy buttons and a Commands block that already contains them, ready to paste into a terminal.

Who can reveal credentials¶

Every organization member sees the panel, but only Administrators and Owners of the organization can reveal the credentials. Members see a note asking them to contact an organization administrator instead.

Each reveal is recorded in the organization audit log with the requester, the instance, and the time. The first time credentials of an instance are revealed, all organization owners receive a notification email. If an owner receives such a notification unexpectedly, they should contact support to have the credentials replaced.

What the credentials can do¶

The credentials allow full access to the bucket. Anyone holding them can permanently delete every backup of the instance. Support cannot recover deleted or tampered backups. Treat these credentials like a root password.

Further points to keep in mind:

Credentials are static. They are not tied to your user account, they do not expire, and the portal cannot revoke them. Removing a member from the organization does not take away credentials they have already seen. Contact support to have them replaced after offboarding or a suspected leak.
Credentials outlive the instance. The bucket is retained for the configured retention period after backups are disabled or the instance is deleted, and the credentials keep working until then.
Data leaves the bucket unencrypted. The restic repository is encrypted at rest, but whatever you dump or restore locally is plain data. Protect it accordingly.

Working with K8up backups (restic)¶

Some services are backed up with K8up, which stores a restic repository in the bucket. You need the restic command line tool. The panel reveals three values: the Access Key ID, the Secret Access Key, and the Repository Password that decrypts the repository.

The commands block sets the environment and lists the available operations:

export AWS_ACCESS_KEY_ID='<access key>'
export AWS_SECRET_ACCESS_KEY='<secret key>'
export RESTIC_PASSWORD='<repository password>'
export RESTIC_REPOSITORY='s3:<endpoint>/<bucket>'

restic --no-lock snapshots                            # list backups
restic --no-lock ls <snapshot-id>                     # list files in one backup
restic --no-lock dump <snapshot-id> <path> > <file>   # extract one file
restic --no-lock restore <snapshot-id> --target /tmp/restore

The snapshot IDs correspond to the entries in the backups list.

Always pass --no-lock: it keeps restic from writing lock files into the bucket.

Working with PostgreSQL backups¶

PostgreSQL uses a different backup format (physical base backups plus a write-ahead log archive) and different tooling. See Direct backup access on the PostgreSQL page.