Backups

Modulify snapshots your site's code as you work, and archives the files in its storage once a day, along with its database on a site on the newer database. There is no save button for code, no naming a code snapshot and no diff view, and going back is the only thing you do with one. A storage or database archive is different: you can take one by hand, download it, delete it and turn the daily one off for a site, but it cannot be restored. Chat and a connected AI client can do all of that except download, as Backups from chat and MCP describes.

Open the history

The Backups tab lives behind More in the tab strip. Click More, then Backups in the list on the left.

Inside it sit three tabs. Code is the history of your site's files, Storage is the history of the files in your Storage bucket, and Database is the history of your site database. They are separate because they are backed up in different ways: code is snapshotted as you build, while storage and the database are archived once a day. While Storage or Database is open, Back up now sits at the right end of that same strip. It never appears on Code.

The Storage tab also opens from the Storage panel. Its Configuration sub-tab has a Backups section, and its View backups button lands straight on this tab, on the free plan too. The same section holds the Daily backups switch, and the Danger zone below it holds Delete all storage backups.

The Database tab opens from the CMS the same way. Its Settings sub-tab has a Backups section between Export and Danger zone, and its View backups button lands straight on the Database tab, on the free plan too. On a site on the older database that button is greyed out, and hovering it reads Backups need a site on the newer database. That section holds the database Daily backups switch, and the Danger zone below it holds Delete all database backups.

Before anything has been recorded, the Code panel reads No code backups with Code backups appear here as you build. If the history cannot be loaded you get Could not load code backups and Refresh the page to try again.

What creates a backup

A snapshot is taken automatically when:

• a chat message finishes and it changed files
• a batch of inline text edits is applied
• you restore an older backup
• changes still only in the preview are saved on their own, for example after a chat message is stopped or fails, when the editor opens again, or just before a publish
• your code is moved to your own GitHub, which records the point it moved

Apart from the point your code moves to your own GitHub, a snapshot is only taken when files actually changed. A chat message, a publish, a text edit or a restore that leaves your files exactly as they were does not create one.

Read an entry

Each row reads v12 by Sam, where the number counts up from the oldest snapshot, followed by a badge, the time it was taken, and the first seven characters of its commit.

The badge is Restore for a backup created by restoring, Text edit for a batch of inline text edits, Preview sync for changes saved from the preview on their own, Repository move for the point your code moved to your own GitHub, and Automatic for everything else. The list loads ten at a time and fetches more as you scroll.

Restore a backup

Open the three dots menu on a row and choose Restore.

Restoring puts every file back to how it was at that point, then reloads the preview against them. It also does two things that are easy to miss:

• The chat transcript is deleted for everyone in the project. The conversation does not survive a restore.
• Anything queued in chat is thrown away unsent.

Because of that you are asked to confirm whenever there is something to lose. If messages are queued the dialog reads Restore this code backup? and warns that restoring erases the chat transcript for everyone. If AI is generating right now, it reads Stop AI and restore this code backup?, the button says Stop and restore, and it stops the job and discards the changes it had not finished. With nothing queued and nothing running, the restore happens straight away.

When it lands you get a Code backup restored toast. Everyone else in the project sees the restore happen too.

Everyone with the File Explorer open sees the restored code as soon as the restore lands: open files reload with the restored version, and files the backup does not contain leave the tree and their tabs close. While a restore runs, restoring again answers Another code backup is already being restored for this site!, an inline text edit shows Could not save text with A code backup is being restored. Try your edit again when it finishes!, and a publish waits for the restore to finish. A restore started while a save is still running, such as the files of a chat message that just finished, waits for that save first. If the save is still running after 30 seconds, nothing is restored, the chat is left as it was, and the restore answers Your latest changes are still being saved. Try restoring again in a moment!

If the preview cannot be reloaded with the restored code, it shows Could not load your files with a Retry next to it, and nothing from the preview is saved until it reloads. Your restored code is already saved, so pressing Retry only reloads the preview. Once anyone reloads it successfully, the message clears for everyone in the project.

Restoring does not publish. Your live site keeps serving whatever you published last until you publish again.

Storage backups

The Storage tab is a separate history, for the files you and your site put in storage. It is a paid feature.

On any paid plan, a daily run archives every site without you asking, unless daily backups were turned off for that site. If one run cannot get through every site in time, the rest move to the next daily run, which starts with the sites that have waited longest. The archive is a single .zip of everything in the bucket at that moment, public and private files alike, and it is kept away from your storage so it never counts against what you are using.

Archives are private. They are never served from your storage CDN address or any other public link, and the only way to get one is the Download action described below.

A day where nothing in your storage changed is skipped rather than archived again, so a quiet site does not fill the list with identical copies. Adding, replacing or deleting a file is enough to make the next daily archive run.

Read an entry

Each row starts with who took it, the way a code backup does. A backup someone took by hand starts with that person's avatar and is titled with their first name, for example Backup by Sam, or Manual Backup when their name is not known. A daily archive starts with a calendar icon and is titled Daily Backup. A backup taken through chat or a connected AI client with a name of its own shows that name as its title instead.

The line under the title always starts with a type badge, Manual for a backup someone asked for and Daily for the automatic archive, followed by the date and time it was taken, how many files it holds and how big the archive is. Dates and times on a row read in your own timezone. The list loads ten at a time and fetches more as you scroll.

While an archive is being built a second badge, Archiving, sits next to the type badge, and the file count and size are left off, because they are not known until it finishes. The row refreshes on its own. If it could not be built that second badge reads Failed, the file count and size stay off, and the reason sits at the end of the line. The type badge never goes away, so a failed manual backup still reads Manual beside Failed.

Back up now

Back up now sits at the right end of the tab strip while the Storage tab is open. Choosing it asks Back up your storage now? first. The dialog says every file in your storage is archived into a backup you can download later and that your live files are untouched, then tells you what the backup costs from your allowance, for example This uses one of your 10 manual backups in the last 24 hours, so 6 will be left. When only one is left it reads This uses the last of your 10 manual backups, and the next one unlocks once your oldest one is a day old.

Confirm with Back up now. The row appears straight away as Archiving and fills in once the zip is built, so a large bucket does not leave you waiting on the button. Only one backup of a site runs at a time, so the button stays disabled while one is still being built, and hovering it reads A backup of this storage is already being archived.

The row appearing is not the files being read. Two archives are built at a time across the whole platform, so a backup can sit in line for a few minutes before it starts listing your bucket, and what it holds is your storage as it stands at that moment rather than at the moment you pressed the button. If you are backing up before a clear out, wait for the row to read its file count and size before you delete, move or change the visibility of anything, because a file that left in between is simply not in the zip.

You get ten manual backups per site in any twenty four hours. The button is disabled once they are spent, and hovering it reads You have used all 10 manual backups in the last 24 hours. A backup that fails does not spend one. Deleting a manual backup does not give its slot back either: it keeps counting against the ten until twenty four hours after it was taken, so the allowance only refills as that time passes.

On a free workspace the button is disabled with a Paid badge beside it, and hovering it reads Backing up your storage requires a paid plan. If your plan cannot be confirmed, it is disabled with We could not confirm your plan, so backups are unavailable right now. and no badge. The button is greyed out with no tooltip while the list is still loading, and if the list could not be loaded it stays greyed out with Backups could not be loaded, so a new one cannot start yet. It also waits with Wait for the backups to finish deleting. while Delete backups is still running for this site, and with Wait for the backup of another site to start. while a backup you started on another site is still being requested.

A backup needs something to archive, and it has to fit in one file. Back up now on an empty bucket leaves a Failed row reading There are no files in your storage to back up!, while the daily archive passes an empty site over quietly. A bucket holding more than 100 MB of files, measured before they are zipped, is too large for a single archive, and one holding more than 20,000 files and folders is too many to read in one pass. Both are refused outright rather than archived in part.

If an archive stops before it finishes, for example because the server restarted, it is marked Failed with The backup stopped before it finished! once it has been running for 30 minutes, by the next backup of that site or simply by opening the tab again, and the daily cleanup removes it once a day has passed since it started, so it never blocks new backups for long.

Turn daily storage backups off

Daily storage backups are on for every site, including sites created before the switch existed. To stop them for one site, open the Storage tab, switch to Configuration, and turn off Daily backups in the Backups section. The row reads Archive your storage every night. Turning this off stops only the nightly backup, so manual backups still work and existing archives stay. The switch flips at once and you get a Daily backups off toast.

Off means the daily run skips this site's storage and nothing else. Back up now keeps working, every archive already taken stays listed, downloadable and deletable, and archives keep ageing out on the schedule below. The site's database backups have a switch of their own and carry on as they were.

While daily backups are off, the Storage tab of Backups shows one line above the list, Daily backups are off for this site., followed by Turn them back on in Storage configuration., which takes you straight to the switch. Turn it back on and you get Daily backups on, and the next daily run picks the site up again.

On a free workspace the switch is disabled with a Paid badge, because there is no daily run to turn off, and the line above the list is not shown. Any member of the workspace can flip the switch.

Download a backup

Open the three dots menu on a row and choose Download. The archive downloads as a .zip named after your site and the moment it was taken, in UTC, for example my-site-storage-2026-03-04-05-06-07.zip. The row shows that moment in your own timezone, so the hour in the filename can differ from the hour on the row. Open it with whatever unzips files on your computer.

Download stays greyed out until a row is finished. On a row still being archived, hovering it reads Wait for the backup to finish before downloading it., and on a row that failed This backup has no archive to download., because neither has a zip to hand you. If the archive behind a finished row is gone, you are told The archive of this backup is no longer available! instead of getting a broken file.

The download goes through a signed link that stops working 15 minutes after you click Download, so a link copied out of your browser does not stay usable.

Inside the zip your files are split by visibility, so you can tell which side each file came from:

• public/ holds your public files
• private/ holds your private files

Each file keeps the path it had in storage below that folder, so images/logo.png on the public side is public/images/logo.png in the zip.

Alongside the two folders sits one extra file, __modulify-backup.json. That is an index Modulify writes: when the archive was taken, the default visibility of the top level, every file with its path in the zip, its path in storage, its visibility, its size and the time it last changed, and every folder that has its own default visibility. Empty folders are not in the zip itself, so the index is where a folder default is kept. Your own files always sit inside public/ or private/, so a file of yours with the same name never replaces the index. Leave it out when you upload the files again.

Browsing a backup inside Modulify is not built yet. Downloading is the only way to see what is inside one.

Get files back from a storage backup

There is no Restore for a storage backup. A row's menu holds Download and Delete and nothing else, the Restore on the Code tab puts back your site's source files without touching storage, and neither chat nor a connected MCP client can restore or download one.

To recover files you lost from storage, download an archive that still holds them, unzip it, and upload the files you need again from the Storage panel. The panel uploads files, not folders, so recreate a folder with New folder first and drop its files into it.

An uploaded file follows the default of the folder it lands in, not the side it was on in the archive, and the top level default is private unless you changed it from the Top level menu. Check the lock on every file you put back: use Make public on any file from public/ that landed private, and Make private on any file from private/ that landed public. A public file back at the path it had gets the address it had, so pages and CMS rows that linked it load it again.

Who can use backups

A backup holds your private files, so it is guarded like them. Every member of the workspace that owns the site can list and download its backups, exactly as they can open any file in its storage. Starting a backup also needs the workspace to be on a paid plan, and deleting one needs the Delete projects permission, so a member without it sees a row's Delete and the Delete backups button in the Danger zone greyed out with a tooltip rather than missing. Turning daily backups on or off needs only membership of the workspace. Anyone outside the workspace is turned away before Modulify even looks the backup up. See Members and roles.

Delete a backup

Open the three dots menu on a row and choose Delete. It asks Delete this storage backup? and warns that the archive is removed for good. A row still being built keeps its Delete greyed out, and hovering it reads Wait for the backup to finish before deleting it., because its archive is still being written, so delete it once it has finished or failed. If an archive cannot be reached it stays in the list rather than disappearing from it, and Delete on that row says Something went wrong while deleting your storage backup! If the row was already removed by someone else, by chat, by a connected AI client or by the daily cleanup, you get Nothing to delete with This archive was already gone, so the list is up to date. and the row leaves the list.

There is no delete all button in the list. To clear the whole history at once, open the Storage tab, switch to Configuration, and press Delete backups on the Delete all storage backups row under Danger zone. It asks Delete every storage backup?, warns that every finished archive for the site is removed for good while a backup still being archived is kept, and deletes on Delete all. You get Backups deleted when it is done, Nothing to delete when the site held no finished archive, and Some backups are still there when some archives could not be reached, which names how many of them are still in the list. The button works on the free plan too, so archives taken while on a paid plan can still be cleared, and it waits with a tooltip while the backups of another site are still being deleted.

How long they are kept

Archives are thinned as they age, so a year of daily backups never grows without limit:

• every daily archive from the last week
• one archive a week back to eight weeks ago
• one archive a month back to a year ago

Anything older than a year is removed, and backups you made yourself are never thinned early, only removed once they pass a year. The one archive this thinning never removes is the newest finished one of a site, however old it gets, so a site you stop changing keeps its last archive instead of ending up with none.

A backup that failed is the exception to all of that. It is cleared from the list by the first daily cleanup after a day has passed since it was attempted, whichever kind it was, so read the reason beside it while it is there.

When the plan changes

Backups are a paid feature, so going from a paid plan to Free stops new ones. The daily run passes the site over, Back up now is disabled with a Paid badge beside it in the tab strip, and the Daily backups switch in Storage configuration is disabled with a Paid badge of its own.

The archives already taken are not deleted. You can still download and delete them, and they keep ageing out on the same schedule. Go back to a paid plan and the next daily run picks the site up again, unless daily backups were turned off for it.

Database backups

The Database tab is a third history, for the tables and rows in your site database. It is a paid feature, and it covers sites on the newer database only.

On any paid plan, a daily run backs up the database of every site on the newer database without you asking, unless daily backups were turned off for that site. It starts early in the morning, UTC. If one run cannot get through every site in time, the rest move to the next daily run, which starts with the sites that have waited longest. The backup is a single .zip holding the whole database as it was at one moment: every table and every row, along with its indexes, triggers and views. It is kept away from your storage, so it never counts against what you are using.

Backups are private. They are never served from your storage CDN address or any other public link, and the only way to get one is the Download action described below.

A day where nothing in your database changed is skipped rather than backed up again, so a quiet site does not fill the list with identical copies. Any write to the database is enough to make the next daily backup run, whether it comes from the CMS, from your site or from chat.

Which sites have database backups

The Database tab is on every site, but only a site on the newer database can be backed up. On a site on the older database, Back up now is greyed out with no Paid badge, whatever the plan, and hovering it reads Backups need a site on the newer database., an empty list reads No database backups with Backups cover sites on the newer database., and the daily run passes the site over.

A site on the newer database that has no database yet reads No database with Ask chat to create a database first., and hovering Back up now reads Create a database before backing it up. Ask chat for a database first, as Site databases describes. In both cases any backup taken earlier stays in the list, and you can still download or delete it.

There is nothing to work out on your side: whenever Back up now is greyed out because of your site or your plan, hovering it names the reason.

Read a database backup

A database backup row reads exactly like a storage one. A backup someone took by hand starts with that person's avatar and is titled with their first name, for example Backup by Sam, or Manual Backup when their name is not known. A daily backup starts with a calendar icon and is titled Daily Backup. A backup taken through chat or a connected AI client with a name of its own shows that name as its title instead.

The line under the title always starts with a type badge, Manual or Daily, followed by the date and time it was taken, how many tables and rows it holds and how big the archive is. Dates and times on a row read in your own timezone. The list loads ten at a time and fetches more as you scroll.

The table count includes the hidden tables the CMS keeps for field settings and multi reference fields, so it can be higher than the number of collections in the CMS sidebar.

While a backup is being made a second badge, Exporting, sits next to the type badge, and the counts and size are left off, because they are not known until it finishes. The row refreshes on its own. If it could not be made that second badge reads Failed, the counts and size stay off, and the reason sits at the end of the line. The type badge stays either way.

Back up your database now

Back up now sits at the right end of the tab strip while the Database tab is open. Choosing it asks Back up your database now? first. The dialog says every table in your database is exported into a backup you can download later and that your live data is untouched, then tells you what the backup costs from your allowance, in the same words as a storage backup, for example This uses one of your 10 manual backups in the last 24 hours, so 6 will be left.

Confirm with Back up now. The row appears at once as Exporting and fills in when the backup is finished. A backup you ask for is always made, even when nothing has changed since the last one. Only one backup of a site's database runs at a time, so the button stays disabled while one is still exporting, and hovering it reads A backup of this database is already being exported.

One database is exported at a time across the whole platform, so the row can sit as Exporting for a while before the copy itself starts, and what it holds is your data as it stands at that moment rather than at the moment you pressed the button. Wait for the row to show its table and row counts before you clear a collection you meant that backup to hold.

You get ten manual database backups per site in any twenty four hours, counted separately from your storage backups. The button is disabled once they are spent, and hovering it reads You have used all 10 manual backups in the last 24 hours. A backup that fails does not spend one. Deleting a manual backup does not give its slot back either: it keeps counting against the ten until twenty four hours after it was taken.

On a free workspace the button is disabled with a Paid badge beside it, and hovering it reads Backing up your database requires a paid plan. The badge is only shown on a site that could otherwise be backed up, so a site on the older database or with no database gets its own reason instead. If your plan cannot be confirmed, it is disabled with We could not confirm your plan, so database backups are unavailable right now. and no badge. The button is greyed out with no tooltip while the list is still loading, and if the list could not be loaded it stays greyed out with Backups could not be loaded, so a new one cannot start yet. It also waits with Wait for the backups to finish deleting. while Delete backups is still running for this site, and with Wait for the backup of another site to start. while a backup you started on another site is still being requested.

If a backup stops before it finishes, for example because the server restarted, it is marked Failed with The backup stopped before it finished! once it has been running for 30 minutes, by the next backup of that site or simply by opening the tab again, and the daily cleanup removes it once a day has passed since it started.

Turn daily database backups off

Daily database backups are on for every site, including sites created before the switch existed, and they are set apart from daily storage backups. To stop them for one site, open the CMS tab, switch to Settings, and turn off Daily backups in the Backups section. The row reads Archive your database every night. Turning this off stops only the nightly backup, so manual backups still work and existing archives stay. The switch flips at once and you get a Daily backups off toast.

Off means the daily run skips this site's database and nothing else. Back up now keeps working, every backup already taken stays listed, downloadable and deletable, and backups keep ageing out on the usual schedule. Daily storage backups carry on as they were.

While daily backups are off, the Database tab of Backups shows one line above the list, Daily backups are off for this site., followed by Turn them back on in CMS settings., which takes you straight to the switch. Turn it back on and you get Daily backups on, and the next daily run picks the site up again.

On a free workspace the switch is disabled with a Paid badge. On a site on the older database it is disabled with no badge, and hovering it reads Backups need a site on the newer database. Any member of the workspace can flip the switch.

Your database pauses while it is backed up

A backup copies the whole database in one piece, and the database does not answer queries while that copy is being made. For a small database this is over almost at once, but a request your site sends in that moment can be slow or fail, so take a manual backup of a busy site at a quiet time. An export that runs for longer than six minutes is stopped, and the backup is marked Failed with Exporting your database took too long, so this backup was stopped!

What cannot be backed up

Some databases are refused outright rather than backed up in part:

• An empty database. Back up now leaves a Failed row reading Your database has no tables to back up!, while the daily run passes an empty database over quietly. The table the CMS keeps for field settings does not count as a table on its own.
• A database that is too large. A database larger than 100 MB is too large for a single archive, and so is one whose exported SQL comes to more than 150 MB. Both fail with Your database is too large to back up as a single archive!
• A database with a full text search table. Such a table cannot be exported, so every backup of that database fails with Your database has a full text search table, which cannot be backed up! until the table is removed. Chat does not create one unless you ask for full text search, and even then it first tells you that doing so stops your database backups and waits for you to confirm.

When the daily run meets a database that is too large or holds a full text search table, it leaves a Failed row with the reason, so you can see why the site has no recent backup.

Download a database backup

Open the three dots menu on a row and choose Download. The backup downloads as a .zip named after your site and the moment it was taken, in UTC, for example my-site-database-2026-03-04-05-06-07.zip. The row shows that moment in your own timezone, so the hour in the filename can differ from the hour on the row.

Download stays greyed out until a row is finished. On a row still being exported, hovering it reads Wait for the database export to finish before downloading it., and on a row that failed This backup has no database archive to download., because neither has an archive to hand you. If the archive behind a finished row is gone, you are told The archive of this backup is no longer available! instead of getting a broken file.

The download goes through a signed link that stops working 15 minutes after you click Download, so a link copied out of your browser does not stay usable.

What is inside a database backup

The zip holds two files:

• database.sql is your database as a plain text SQL file written for SQLite. It creates each table and inserts every row, one statement per row, then creates your indexes, triggers and views. Open it in any text editor to read or search it, or load it into a SQLite tool, such as the sqlite3 command line tool, to query it. It is not written for Postgres, so it cannot be imported into a Postgres database as it is.
• __modulify-backup.json is an index Modulify writes: when the backup was taken, how big the database and database.sql are, how many tables and rows it holds, the row count of every table, and the identifiers Modulify uses to recognise the database and the moment it was copied.

Browsing a backup inside Modulify is not built yet. Downloading is the only way to see what is inside one.

Get data back from a database backup

There is no Restore for a database backup. A row's menu holds Download and Delete and nothing else, the Restore on the Code tab puts back your site's source files without touching the database, and neither chat nor a connected MCP client can restore or download one.

To get rows back, download a backup that still holds them, find them in database.sql, and add them again. You can enter them one at a time in the CMS, where each new row gets a new id, so links from other collections to the old row have to be picked again. Or paste the rows into chat and ask for them to be added back, which can keep their original ids.

Who can use database backups

A database backup holds every row of your database, so it is guarded like the database itself. Every member of the workspace that owns the site can list and download its database backups. Starting a backup also needs the workspace to be on a paid plan, and deleting one needs the Delete projects permission, so a member without it sees a row's Delete and the Delete backups button in the Danger zone greyed out with a tooltip rather than missing. Turning daily backups on or off needs only membership of the workspace. Anyone outside the workspace is turned away before Modulify even looks the backup up. See Members and roles.

Delete a database backup

Open the three dots menu on a row and choose Delete. It asks Delete this database backup? and warns that the archive is removed for good. A row still exporting keeps its Delete greyed out, and hovering it reads Wait for the database export to finish before deleting it., so delete it once it has finished or failed. If an archive cannot be reached it stays in the list rather than disappearing from it, and Delete on that row says Something went wrong while deleting your database backup! If the row was already removed by someone else, by chat, by a connected AI client or by the daily cleanup, you get Nothing to delete with This database archive was already gone, so the list is up to date. and the row leaves the list.

To clear the whole history at once, open the CMS tab, switch to Settings, and press Delete backups on the Delete all database backups row under Danger zone. It asks Delete every database backup?, warns that every finished archive for the site is removed for good while a backup still being exported is kept, and deletes on Delete all. You get Backups deleted when it is done, Nothing to delete when the site held no finished backup, and Some backups are still there when some could not be reached, which names how many of them are still in the list. The button works on the free plan too, and it waits with a tooltip while the backups of another site are still being deleted. On a site on the older database it is greyed out with Backups need a site on the newer database., so a backup taken there earlier is deleted from its own row instead.

Clearing a collection or every collection from the CMS does not delete any backup, so a backup taken before the clear still holds the rows.

How long database backups are kept

Database backups age out exactly like storage backups:

• every daily backup from the last week
• one backup a week back to eight weeks ago
• one backup a month back to a year ago

Anything older than a year is removed, and backups you made yourself are never thinned early, only removed once they pass a year. The newest finished backup of a site is never removed, however old it gets. A backup that failed is cleared from the list by the first daily cleanup after a day has passed since it was attempted.

Database backups when the plan changes

Going from a paid plan to Free stops new database backups. The daily run passes the site over, Back up now is disabled with a Paid badge beside it in the tab strip, and the Daily backups switch in CMS settings is disabled with a Paid badge of its own.

The backups already taken are not deleted. You can still download and delete them, and they keep ageing out on the same schedule. Go back to a paid plan and the next daily run picks the site up again, unless daily backups were turned off for it.

Backups from chat and MCP

Storage and database backups can also be handled in plain words. Ask chat and it can:

• list a site's storage or database backups, with the state of each one and whether daily backups are on
• take a manual backup, which spends one of the same ten a site in twenty four hours as Back up now and needs the same paid plan
• delete one backup, or every backup of one kind, which needs the Delete projects permission
• turn daily backups on or off for the site, one kind at a time, except that the database switch is refused outright on a site on the older database, where there is no daily backup to stop

Chat asks you before it deletes any backup, and it never deletes backups to save space on its own. It never downloads a backup, never hands you a link to one and never restores one, because there is no restore: downloading stays in this tab. It cannot list or restore the Code history either, and points you to the Code tab when you ask about an earlier version.

A backup chat starts is reserved straight away and read a little later, exactly as Back up now is, so when you ask for one before a clear out, wait for chat to report the row ready before you let it delete or move anything.

A connected AI client has the same abilities through ten MCP tools, five for each kind: list_storage_backups, create_storage_backup, delete_storage_backup, clear_storage_backups and set_storage_backup_schedule, and list_database_backups, create_database_backup, delete_database_backup, clear_database_backups and set_database_backup_schedule. Listing needs the sites:read scope, taking a backup and turning daily backups on or off need sites:write, and deleting needs sites:delete, which is unticked by default. set_database_backup_schedule is refused on a site on the older database, the same as in chat. No tool downloads or restores a storage or database backup. See MCP tools.

The list follows changes made elsewhere

While the editor is open, a Storage or Database list you have already opened updates on its own when a backup is taken, finishes, fails or is deleted, whether you, a teammate, chat, a connected AI client, the daily run or the daily cleanup did it. There is nothing to refresh. The Daily backups switches follow a change made anywhere else the same way, so a switch flipped by a teammate, from chat or through a connected AI client moves for you too, and the line above the list appears or goes away with it.

Next

• Publish a site pushes a restored state live.
• Site chat explains the transcript that a restore clears.
• Storage covers the files these archives are taken from.
• Site databases covers the database the database backups are taken of.