cwp db
shipped 1.0.0cwp db [flags]
cwp db groups the commands below and takes no action of its own; run it alone and it prints its help.
| Subcommand | What it does |
|---|---|
cwp db snapshot | Snapshot the local database (uploads are not included) |
cwp db restore | Restore the local database from a snapshot (uploads are not included) |
cwp db list | List this project’s snapshots, newest first (uploads are not included) |
cwp db rm | Remove one snapshot (uploads are not included) |
cwp db export | Export the local database to a file (uploads are not included) |
cwp db import | Import a SQL dump over the local database (uploads are not included) |
What it does
Local database snapshots on top of ddev snapshot, plus dump import and export.
Entirely local. No cwp db subcommand talks to a remote host. This is the
half of the safety model that has no backup of its own: the remote database has
its host’s backups, and your local one has whatever you took yourself.
Snapshots are database only. Uploads are not included — which is why every subcommand’s own description repeats it. Restoring brings back your Bricks layouts, not your media library.
restore and import are the two destructive
ones, and they are guarded like cwp pull: they ask before
replacing the local database, --yes skips the prompt, and they refuse with
exit 6 when cwp cannot prompt — under --json, or with no terminal. Picking a
snapshot from the interactive list is the confirmation; you are not asked twice
about the same decision.
Snapshot names may contain letters, digits, dot, underscore and hyphen. The name
becomes a file under .ddev/db_snapshots/, so anything else is refused rather
than passed on.
Example
cwp db snapshot before-migration
# ... experiment ...
cwp db restore before-migration
What it does not do
It does not snapshot or restore uploads, and it does not touch any remote.
There is no upward database push. cwp db is local, and moving a whole database
to a live site is a thing cwp does not do — see Safety.