How to restore Managed Valkey from a backup

Managed Valkey* backs up your services automatically. When you need data back, for example after keys were deleted or overwritten by mistake, you restore one of those backups. The restore creates a new service with the data as it was when the backup was taken. The original service keeps running unchanged, so you can check the restored data before you switch your application over.

This guide covers finding the right backup, restoring it in the Control Panel or with the UpCloud API, and moving your application to the restored service.

Before you start

You need:

• A Managed Valkey service with at least one backup. To create a service, see How to get started with Managed Valkey.
• For the API steps, an API token. To create one, see How to get started using the UpCloud API.
• To check the restored data, valkey-cli on a computer that can connect to the service. See Connect with valkey-cli.

How backups work

A backup holds the service's data as it was when the backup was taken. Anything written after that isn't in it, so a restore brings back the data up to that backup and nothing newer.

A new service gets its first backup shortly after it's created, and then one every 12 hours. For how long backups are kept, see Backups.

Restore the backup

Choose the newest backup that was taken before the data went wrong. A backup taken after that point already holds the deleted or changed data.

The service's Backups tab restores any of its backups, and creates the restored service in the same location and on the same plan as the original service:

1. Go to Databases, open the service and go to its Backups tab. The list shows each backup with the time it was taken, in UTC.
2. Click Clone from backups.
3. Under Backup, select the backup. Each backup's name includes the time it was taken, in UTC.
4. Enter a Service name and a Hostname prefix for the new service, or keep the suggested ones, and click Clone.

The new service opens in the Control Panel.

To restore into another location or onto another plan, use Clone service on the service's Settings tab instead. It always restores the latest backup, so use it when that's the backup you want, for example to move the service to another location. To restore an older backup into another location or onto another plan, use the API.

1. Open the service's Settings tab, and under Clone service, click Clone.
2. Select the Location, Plan and Nodes for the restored service. The form starts with the original service's settings, including its connection access and allowed IP addresses, so check those as well.
3. Enter a Service name and a Hostname prefix, and click Clone Managed Database.

If the original service is on an SDN Private Network and you select another location, the form changes the private connection to the Utility network. To keep the restored service on an SDN Private Network, click Attach private network, select a network in the new location and click Attach, before you click Clone Managed Database.

The new service opens in the Control Panel.

First, list the service's backups:

GET /1.3/database/<service-uuid>

The backups list in the response has one entry for each backup:

{
  "backups": [
    {
      "backup_name": "valkey-20261018T160351814571Z",
      "backup_time": "2026-10-18T16:03:52.162000Z",
      "data_size": 89
    }
  ]
}

• backup_name is the name you restore by.
• backup_time is when the backup was taken, in UTC.
• data_size is the size of the backup in bytes.

Then send a clone request for the original service, with the name of the backup in backup_name:

POST /1.3/database/<service-uuid>/clone

{
  "title": "<service-name>",
  "hostname_prefix": "<hostname-prefix>",
  "zone": "de-fra1",
  "plan": "2x2xCPU-4GB",
  "backup_name": "<backup-name>"
}

Set zone and plan for the restored service. They don't have to match the original service's, so you can restore into another location or onto another plan.

The restored service keeps the original service's SDN Private Networks. If the original isn't on one, you can attach the restored service to one by adding networks to the request, as when you create a service. To restore a service that's on an SDN Private Network into another location, add networks with an SDN Private Network in that location.

The response has the new service's UUID in uuid, but no connection details yet. The service is ready once GET /1.3/database/<new-service-uuid> returns "state": "running", and service_uri then holds its connection URI.

What the restored service has

• The data from the backup you chose, or from the latest backup if you use Clone service.
• The same users and passwords as the original service.
• The same properties, allowed IP addresses, termination protection setting and maintenance schedule as the original service.
• The same SDN Private Networks as the original service, unless you choose others in Clone service or list others in the API request.
• The original service's location and plan if you use Clone from backups, or the ones you choose in Clone service or set in the API request.
• A new hostname. Update your application's connection settings to use it.

Check the data and switch over

1. Wait until the restored service is Started in the Control Panel, or running in the API.

2. Connect to it with its own connection URI, from its Overview tab or its service_uri, and read back a key that you expect the backup to hold:

   valkey-cli -u 'rediss://default:<password>@<new-hostname>:<port>' GET <key>

3. Change your application's connection settings to the restored service's hostname.

4. When you no longer need the original service, delete it. See How to get started with Managed Valkey. If termination protection is on, turn it off first. The restored service has the same setting, so check it there too.

   After you delete a service, its backups can't be restored. The restored service gets backups of its own.

Troubleshooting

• Could not connect to Valkey at <new-hostname>:<port>: Name or service not known

  The restored service's hostname doesn't resolve yet. Try again until it connects.

• Resource already exists.

  The hostname prefix in the clone request is already in use, for example by the original service. Choose a different hostname_prefix.

• Network '<network-uuid>' not in the same zone as the service.

  The original service is on an SDN Private Network, and the clone request restores it into another location. Add networks with an SDN Private Network in that location.

Next steps

• Backups describes the backup schedule and how long backups are kept.
• High availability describes how standby nodes take over when a node fails.
• How to get started with Managed Valkey covers creating a service and connecting to it.

* Valkey and the Valkey logo are trademarks of LF Projects, LLC. Any rights therein are reserved to LF Projects, LLC. Any use by UpCloud is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Valkey and UpCloud. Other names may be trademarks of their respective owners.