Restore a Snapshot Across Environments

Role: Developer or DBA · Screen: Data → Restore · Time: a few minutes after cloud storage is set up

This page is the clicks. Why teams share states: Share Database States Across Environments. Drive and Storage setup: Configure Cloud Storage.

Why local storage is not enough

Restore only offers a target database if that datasource’s agent can see the snapshot’s Storage name.

Local storages belong to one agent. Another laptop or server cannot read those files.
AWS S3 and Azure Blob storages are company-scoped (agent is empty). Every agent in the company sees the same Storage name and can download the packages over the internet.

Both agents still need network access to that bucket or account, and the credentials the drive uses (including environment variables on the agent host).

Before you start

A cloud drive and Storage exist. Follow Configure Cloud Storage if they do not.
The source backup flow writes to that Storage (not a local drive). Tag the snapshot when you Take Snapshot from the timeline: Take a tagged snapshot.
The target is a writable MySQL, PostgreSQL, SQL Server, or Oracle datasource on the other agent, same engine as the snapshot. MongoDB restore is not on this page.
The target agent is online. Restore runs on that agent.
Restore overwrites the target database.
Sharing production-shaped data? Mask in the backup flow first — Mask Columns.

Steps

1

Snapshot in the source environment

On the agent that can reach the source database, open that data item’s timeline and click Take Snapshot. Pick the backup flow that writes to the shared cloud Storage. Set tags you will filter on later (for example app=quemsi and env=test) and a description. Wait until the execution succeeds. Clicks: Take a tagged snapshot.

2

Open Restore

Same company console: Data → Restore or /app/restore. Filter to those tags. Pick the card (latest matching version for that data and tags).

3

Pick the other environment’s database

Click Restore. The list is not “every database you have.” Each row is a writable datasource of the same type whose agent can read this snapshot’s Storage. The subtitle shows URL, agent, and type—use that to choose the dest agent, not the source one.

If the target agent is online, Browse on agent shows that database before you overwrite it.

Full restore dialog clicks: Restore a tagged snapshot.

4

Confirm overwrite on the target

Read the database name and JDBC URL. Click Restore and overwrite. The execution runs on the target agent. When it succeeds, that environment has the snapshot.

If the target database is missing from the list

The snapshot was written to a local storage. Re-run backup to the cloud Storage, or the dest agent will never see those files.
Engine mismatch (Postgres snapshot vs MySQL target), or the target is marked read-only.
The dest agent is in another company, or is offline when you try to run (browse and execute need it online).
The dest host cannot reach S3/Azure, or drive env vars are missing there — see cloud storage troubleshooting.

Not this page

Promote lookup tables without wiping transactional data — Migrate Config and Reference Data.
Same machine, switch schemas for an interruption — Park work and switch.
Repeat restore for a test suite on one database — tester restore guide.

Restore a snapshot across environments