# Backups & commands Your database is copied every night, you can put a copy back with one command, and you can run migrations against the running app. Add a database to a project and nesly starts copying it: once a day, without being asked, keeping as many nightly copies as your plan allows. You can take one yourself at any moment, put one back, or download the file and walk away with it. ## Three kinds of copy

Nightly	Taken automatically, once a day, for every project with a database. How many are kept is a plan allowance (see /docs/limits/).
Yours	Taken when you ask (nesly backup create, or the console). Never removed by retention — only by you.
Before a restore	Taken automatically the moment before a restore replaces your data, so restoring the wrong copy is survivable.

Retention only ever removes nightly copies. A copy you took, or one taken to protect a restore, stays until you delete it. ## From the terminal ``` nesly backup ls # newest first, with sizes nesly backup create # take one now, wait for it nesly backup restore bkp_… --yes # replace the data with that copy nesly backup download bkp_… # the archive, as a file nesly backup rm bkp_… --yes # delete a copy ``` The download restores anywhere with the standard tools, no account here required — a PostgreSQL custom-format archive for postgres, a standard `.bak` for mssql. ``` pg_restore --clean --if-exists -d postgres://…/mydb bkp_….dump ``` `backup restore` works for **mssql** the same as for postgres — safety copy first, then the archive replaces the database. One boundary worth knowing: both the mssql backup and restore paths currently carry a 256 MB archive limit, and the error names it instead of failing cryptically. ## Restoring A restore replaces everything in the database with what the copy holds. Before it runs, the current contents are copied — that copy's id is printed, and it is in the list like any other. If you restore the wrong one, restore that. Nothing else about the project changes: the same database, the same role, the same `DATABASE_URL`. Your application does not need to be redeployed, though a running instance may be holding stale data in memory. ## One-off commands A migration has to run somewhere. `nesly run` runs a command in the same image as your deployed application, with the same environment variables, so it reaches the same database: ``` nesly run -- npm run migrate nesly run -- ./bin/seed --dry-run nesly run --timeout 5m -- python manage.py migrate ``` Output streams back as it happens, and nesly exits with the command's own exit code — so this works as a step in a pipeline. The command runs in its own container: it does not disturb the instances serving your traffic, and it ends when the command ends. It is not interactive. Nothing is sent to the command's standard input, so an interactive shell (`psql`, a REPL) will not work — run scripts, not sessions. ## Who can do what - **Everyone on the team** can see the list of backups and download one — it is your data. - **Anyone who can deploy** can take a backup and run a command. - **Only an owner or admin** can restore or delete a copy: both destroy something that cannot be recovered from anywhere else. ## What this does not cover Backups are of the database, not of your files or your build output — your code lives in your repository and every deployment can be rolled back to. Point-in-time recovery (restoring to an arbitrary second rather than to a nightly copy) is not offered today, and this page will say so until it is. --- Canonical: https://nesly.net/docs/backups/ Every docs page has this markdown twin: replace the trailing slash with .md