Backup Command
Manage app database backups and app volume backups.
Backups are identified by app, service, and the declared resource. Domains are
routing addresses and are never a backup identity.
Declaring backup targets
A service declares its databases and volumes in the app manifest, and lists
which of them are backed up:
[services.api]
image = "registry.example.com/shop/api:1.4.2"
[[services.api.database]]
name = "orders"
type = "postgres"
schedule = "daily"
[[services.api.volume]]
name = "data"
path = "/var/lib/data"
[services.api.backup]
postgres = ["orders"]
volume = ["data"]
A declared database or volume that the service's backup declaration does not
reference is not a backup target.
Administrative bind mounts are never backup targets. [services.<name>.backup] accepts
only declared databases and volumes, and Gordon never archives an
operator-owned host path exposed through a bind.
gordon backups
Database backups are logical PostgreSQL backups made with pg_dump.
gordon backups <subcommand>
Subcommands:
list [app] - List stored backups, for every app or one app
run <app> --service <service> --database <database> - Run one declared
database backup now
status - Show stored backups plus declared targets that have no completed
backup yet
gordon backups volume
Volume backups are best-effort filesystem archives of the app's declared
volumes, uploaded to S3.
gordon backups volume <subcommand>
Subcommands:
list [app] - List completed volume backup archives
run <app> --service <service> --volume <volume> - Run one declared volume
backup now
status - Show completed archives plus current/recent in-memory job state
Volume archives are not application-consistent unless the application is
quiesced or stopped.
Selectors
--service and the resource flag (--database, --volume) select the target:
- both given: the target must exist, otherwise the command reports not found;
- one omitted: it is only allowed when exactly one compatible target remains;
- several candidates: the command reports the ambiguity and lists the safe
service/resource names.
Nothing is ever chosen by guessing.
Examples
# Database backups
gordon backups list
gordon backups list shop
gordon backups run shop --service api --database orders
gordon backups status
# Volume backups
gordon backups volume list
gordon backups volume list shop
gordon backups volume run shop --service api --volume data
gordon backups volume status
Scheduling
The installation backup schedule runs every declared database whose own
schedule matches the firing tier, and applies retention under the app name.
Volume declarations carry no schedule of their own: the installation volume
backup interval runs the declared volume targets.
JSON Output
Every list, run, and status command supports --json.
gordon backups volume list --json
Required Permissions
- Read operations (
list, status) require admin:status:read.
run requires admin:config:write.
source
1# Backup Command
2
3Manage app database backups and app volume backups.
4
5Backups are identified by app, service, and the declared resource. Domains are
6routing addresses and are never a backup identity.
7
8## Declaring backup targets
9
10A service declares its databases and volumes in the app manifest, and lists
11which of them are backed up:
12
13```toml
14[services.api]
15image = "registry.example.com/shop/api:1.4.2"
16
17[[services.api.database]]
18name = "orders"
19type = "postgres"
20schedule = "daily"
21
22[[services.api.volume]]
23name = "data"
24path = "/var/lib/data"
25
26[services.api.backup]
27postgres = ["orders"]
28volume = ["data"]
29```
30
31A declared database or volume that the service's backup declaration does not
32reference is not a backup target.
33
34Administrative bind mounts are never backup targets. `[services.<name>.backup]` accepts
35only declared databases and volumes, and Gordon never archives an
36operator-owned host path exposed through a bind.
37
38## gordon backups
39
40Database backups are logical PostgreSQL backups made with `pg_dump`.
41
42```bash
43gordon backups <subcommand>
44```
45
46Subcommands:
47
48- `list [app]` - List stored backups, for every app or one app
49- `run <app> --service <service> --database <database>` - Run one declared
50 database backup now
51- `status` - Show stored backups plus declared targets that have no completed
52 backup yet
53
54## gordon backups volume
55
56Volume backups are best-effort filesystem archives of the app's declared
57volumes, uploaded to S3.
58
59```bash
60gordon backups volume <subcommand>
61```
62
63Subcommands:
64
65- `list [app]` - List completed volume backup archives
66- `run <app> --service <service> --volume <volume>` - Run one declared volume
67 backup now
68- `status` - Show completed archives plus current/recent in-memory job state
69
70Volume archives are not application-consistent unless the application is
71quiesced or stopped.
72
73## Selectors
74
75`--service` and the resource flag (`--database`, `--volume`) select the target:
76
77- both given: the target must exist, otherwise the command reports not found;
78- one omitted: it is only allowed when exactly one compatible target remains;
79- several candidates: the command reports the ambiguity and lists the safe
80 `service/resource` names.
81
82Nothing is ever chosen by guessing.
83
84## Examples
85
86```bash
87# Database backups
88gordon backups list
89gordon backups list shop
90gordon backups run shop --service api --database orders
91gordon backups status
92
93# Volume backups
94gordon backups volume list
95gordon backups volume list shop
96gordon backups volume run shop --service api --volume data
97gordon backups volume status
98```
99
100## Scheduling
101
102The installation backup schedule runs every declared database whose own
103`schedule` matches the firing tier, and applies retention under the app name.
104Volume declarations carry no schedule of their own: the installation volume
105backup interval runs the declared volume targets.
106
107## JSON Output
108
109Every list, run, and status command supports `--json`.
110
111```bash
112gordon backups volume list --json
113```
114
115## Required Permissions
116
117- Read operations (`list`, `status`) require `admin:status:read`.
118- `run` requires `admin:config:write`.
119
120## Related
121
122- [CLI Commands](./index.md)
123- [Backups Configuration](../config/backups.md)
124- [Apps Configuration](../config/apps.md)