Backups

Every running managed database is snapshotted daily and the last week is kept. You do not turn it on, and it costs nothing.

That is the whole of what happens automatically, so it is worth being exact about the rest.

Keeping them longer

A week covers the mistake you notice the same day. For the one you notice at month end, keep them longer:

Kept for	Costs
7 days	Free, on every database.
30 days	Per GB of the database, monthly.
90 days	Per GB, monthly.

Priced per GB because that is what the snapshots occupy: ninety days of a large database is a lot more to store than ninety days of a small one, and a single flat price would overcharge one and undercharge the other. The pricing page has the rates, and the database’s own page shows what its size works out to before you choose.

Set it on the database in the dashboard. Moving up charges the difference for the rest of the month and takes effect immediately. Moving back down charges nothing, refunds nothing, and deletes nothing on its own: the extra snapshots are trimmed over the following days as new ones are taken, so changing your mind twice in an afternoon costs you no history.

Growing the database grows this line too, since it is priced by size. That takes effect from your next month rather than being charged on the spot.

What is covered

Managed databases	Snapshotted daily, every engine.
Static sites	Not backed up. Your source folder is the copy.
An app’s /data storage	Not backed up.
An app’s filesystem	Nothing to back up; it is rebuilt every deploy.

Getting data back

Open the database in the dashboard, find the snapshot you want under Backups, and restore it. Snapshots are listed newest first with the size and the time each was taken.

Restoring replaces everything. The database ends up holding exactly what the snapshot held, and what was there a moment before is not saved first, so anything written since it was taken is gone. That is why the confirmation asks you to type the database name: it is the one action here that cannot be undone by doing it again.

There is no CLI command and nothing on the API a token can call. Putting older data over live data is a decision for a person reading a warning, not something an agent should reach on its own.

Holding your own copy

Still worth doing if the data matters, because a snapshot we keep for seven days is not an archive, and a copy on your own disk is the one nobody else has to be involved in.

From your own machine, with the database reachable from outside:

marina db create store --engine postgres --external
pg_dump "$(marina db url store)" > store.sql

marina db url prints the connection string and nothing else, so it composes.

From inside the app, which needs no external access at all:

marina run -- pg_dump "$DATABASE_URL" > /tmp/store.sql

For SQLite, dump through a libSQL client with your URL and token, on whatever schedule suits you.

What “daily” means for you

A snapshot is taken once a day, so the worst case is losing up to a day of writes. For a shop’s orders or a member list that is usually fine. For anything where an hour of data is expensive, take your own dumps more often; nothing here stops you.