Skip to main content

Documentation Index

Fetch the complete documentation index at: https://archie.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Every environment has its own backups. They come in two flavors — automatic pre-merge snapshots taken before each merge, and manual snapshots you take on demand. Either kind can be restored into any target, including a new environment that takes over the original’s name if it was deleted.

​
Backup types

TypeWhen it’s takenWhy it exists
Automatic pre-mergeRight before every merge runs, on the target environment.A safety net. If a merge succeeds but turns out to be a mistake, restore this snapshot to revert.
ManualWhenever you click Create backup in the Backups view (or call the API).Snapshot before a risky operation, or to capture a known-good state.
Both kinds are full backups — schema and data. There’s no incremental or schema-only mode.

​
What’s in a backup

ComponentIncluded
Database schemaYes — every table, column, index, relationship, enum, view.
Row dataYes — every row in every table.
RBAC roles and permissionsYes — they live in the database.
Auth provider configurationProvider records are included. Secrets aren’t restored — they’re re-encrypted with each environment’s key.
File storage provider configurationYes.
Custom API gateway routesYes.
Environment variablesYes.
Files in the storage backendNo — files live in the configured object store and are referenced by ID. The backup captures references, not blobs.

​
Taking a manual backup

1

Switch to the environment you want to back up

Use the environment switcher at the top of the project chrome.
2

Open Backups

From the switcher dropdown, open the Backups view.
3

Click Create backup

The backup runs as a background job. The status moves through pending → running → completed.
4

Optionally name the backup

Add a label like pre-stripe-migration or release-v2 to make the snapshot easy to find later.
The backup appears in the list with its type (Manual), the user who created it, the timestamp, and the size.

​
Restoring a backup

A restore reverts the entire environment — schema and data — to the snapshot point. It’s not a per-change undo.
1

Find the backup

In the Backups view, locate the entry to restore. Pre-merge backups are linked from the corresponding history entry.
2

Pick the target environment

By default, restoring puts the snapshot back in the same environment it was taken from. You can also restore into a different environment — including a new environment that takes over a deleted one’s name (see below).
3

Confirm

The platform locks the target, drops its current state, and replays the backup. The status transitions through restoring and back to active when complete.
A restore replaces the target environment’s contents. Anything written to the target after the backup was taken is gone. If you might need that recent data, take a fresh manual backup of the current state first.

​
Restoring to a deleted environment

A backup outlives its environment — even if you delete feature-x, its backups stick around through the retention window. To restore them, the platform recreates the environment as part of the restore:
1

Find the backup

Backups for deleted environments are still listed in the project’s Backups view, with their original environment name shown.
2

Restore

Click Restore. If no environment with that name currently exists, the platform recreates the environment as part of the operation. The new environment inherits the backup’s schema, data, and configuration.
3

Reconfigure secrets

Auth provider secrets and OAuth credentials are not in the backup — re-enter them in the recreated environment before exposing it.
This is the recovery path when a deleted environment turns out to have held a critical migration or test fixture you need back.

​
Pre-merge backups in the merge flow

Every merge automatically produces one pre-merge backup on the target. The backup ID is recorded in the history entry alongside the merge — you don’t have to hunt for it. Common pattern: after a merge into master, if a regression surfaces, open History → find the merge → follow the backupId to the Backups view → restore.

​
Retention

Backups are retained for a configurable window per project. Once a backup ages out, it’s pruned and can no longer be restored. Manual backups can be marked retain forever to opt them out of pruning — useful for capturing release-train snapshots that you want to keep indefinitely. If you need a long rollback window for a specific merge, promote its automatic pre-merge backup to a retained manual backup before the retention window expires.

​
Permissions

Creating, listing, and restoring backups is governed by Role-Based Access. Restore is destructive — typically restricted to admin or operator roles. Read access can be granted more widely if you want broader visibility into snapshots without the ability to restore.

​
FAQ

No. The backup captures the file storage provider configuration and the references records hold to files (file IDs, paths). The actual blobs stay in the configured object store. Treat your storage provider’s own snapshot/versioning as the source of truth for file content.
Backups are full — schema and data. For schema-only operations, use the diff and merge tools, or branch a new environment in System mode.
The target is locked while the restore runs. Reads continue from the existing data until the restore completes; mutations are rejected with the environment-locked error. Once complete, the target reflects the snapshot’s state and reopens for writes.
No. Backups are project-scoped — they reference project-specific identifiers (auth keys, project ID, RBAC role IDs) that don’t translate across projects. To clone a project, branch within it.
The target stays in error state with a failure reason recorded. The platform doesn’t automatically partial-restore — either the backup applies cleanly or the environment is left as it was, in error. Recovery is to run the restore again, or restore a different snapshot.