31/10/2026 · คู่มือ, Backup, Storage

Back up and restore /bw-data on BrewInTH: keep your users' files safe

Cover in Thai and English: "Back up and restore /bw-data, so your users' files are never lost" in Thai, with the English title below, a hard-drive icon, a restore-arrow icon and Manee

Files your app writes to /bw-data, like uploads and SQLite, have no trash once deleted. Turn on daily backups, keep a .tgz copy and restore safely.

Your site lets customers attach payment slips, lets members upload photos, or keeps everything in an SQLite file. Those files live on the persistent storage at /bw-data, so a new release does not wipe them. But if a new version of the code deletes the wrong folder, a clean-up script removes too much, or an AI runs a command that overwrites them, what disappears is not in the Files tab's trash, and it is not in your database backups either.

Since 18 October 2026 BrewInTH has a Volume backups (/bw-data) panel: it backs up the whole storage, lets you download a copy, and restores it from the console. This guide covers what gets backed up and when, whether you need to buy anything, and how to restore without losing the files that arrived after the backup.

In short
💾 The Volume backups (/bw-data) panel is on the App settings tab of any project with persistent storage switched on
✅ The Backups add-on (฿99 a month) backs up every day (keeps 7) and unlocks Back up now (keeps 5)
🛟 Without the add-on, the platform still takes a copy before a restore, before data files are replaced and before the storage shrinks
📦 A backup is a .tgz of the whole storage: download it anytime; it does not count against your package
↩️ A restore replaces every file with the chosen backup; the app stops briefly, and the current files are always kept first

How /bw-data differs from the rest of your project

Each part of a BrewInTH project has its own way back:

Code and uploaded files go back through the release history, and files deleted on the Files tab can be restored from its trash (restore deleted files from the trash).
Databases (PostgreSQL, MySQL, MariaDB and MongoDB) have their own backups on the Databases tab (back up and restore a database).
Files your app writes to /bw-data, such as user uploads, slips, PDFs and SQLite files, are in neither of those. When the app deletes a file there, it is gone at once. The way back is a backup of the persistent storage.

The panel exists only for app projects (not static sites) with persistent storage switched on. If yours is not on yet, start with how to turn on persistent storage (/bw-data).

Where backups come from

Open the project, go to the App settings tab and scroll past the Persistent storage (/bw-data) panel to Volume backups (/bw-data). The Kind column says where each backup came from:

Daily: the platform takes one a day (about 24 hours after the latest backup) and keeps the last 7. Needs the Backups add-on.
Manual: the ones you take with Back up now; the last 5 are kept. Needs the Backups add-on.
Before data files were replaced: when you tick Use the data files of this archive instead of the site's on the Upload & go live page, the whole storage is backed up first and the new release waits for it. Keeps 3 (how the Upload & go live page works).
Before restore: the current files are kept before every restore. Keeps 3.
Before shrinking: choosing a smaller persistent storage size takes a backup before the files move. It stays until you delete it. At the time of writing the table shows this kind as pre_shrink.

The last three happen even without the add-on. Backups beyond those numbers drop off the table, but their files move to the server's trash rather than being destroyed straight away.

Turn on daily backups and take your own

Go to Plans & billing › Add more resources › the Backups card (฿99 a month) and press Subscribe (renews automatically, cancel anytime), or untick Renew automatically every month and press Buy one period. The add-on covers every project in the account, and its databases too.
Back in the Volume backups (/bw-data) panel, Automatic daily backup (keeps 7) is already ticked. Untick it for any project that does not need it.
Press Back up now for a first backup straight away. The new row goes from Queued to Running to Completed, with its size, and Last backup next to the button shows the time.

The app keeps running while a backup is taken; the site does not stop. One job runs at a time per project: press the button while one is still going and you are told a backup or restore is already running, so give it a moment.

The total size of your backups is on the Usage tab under Backups. Backups do not count against your package's storage, which counts only uploaded files, files on persistent storage and the data in your databases.

If the add-on runs out, daily backups stop and Back up now greys out, but the backups you have can still be downloaded and restored.

Download a copy to keep elsewhere

Press Download on a Completed row for a file named like brew-ab12c-bw-data-2026-10-31-07-00-00.tgz: the project code shown under the project's name, then the backup's date and time in Thai time. It holds everything that was on the persistent storage at that moment:

Files your app wrote straight to /bw-data sit at the top level, for example uploads/ or app.db.
App folders the platform keeps on the storage, such as the uploads/ or data/ folders the Upload & go live page sets up, are under app/, for example app/uploads/.

Windows 11 and macOS open a .tgz with a double-click; 7-Zip or tar -xzf yourfile.tgz work too.

Backups live on BrewInTH's servers. Important data should never exist in one place only, so download a copy to your computer or cloud storage about once a month, and keep it safe: it holds every file your users ever sent.

Restore the whole storage from a backup

In the table, find the row from a time when your files were all there. Its status must be Completed. Press Restore.
The box Restore the volume from this backup? shows the backup's time. Type the project's name under Type the project name to confirm, then press Restore now.
The platform keeps the current files as a Before restore backup first. The site still works meanwhile.
Then the app stops, every file on the persistent storage is removed, the chosen backup is unpacked in their place, and the app starts again by itself. Visitors cannot open the site during this step, and the more files there are, the longer it takes, so restore at a quiet time.
When it is done, a message says the restore has finished and names the Before restore backup that was kept.

Picked the wrong one? Press Restore on the Before restore row from the moment you first pressed it, and the storage goes back to how it was.

Two things to think about first

Files added after the backup's time disappear from the site. A restore empties the storage before unpacking; it does not merge the two sets. Restore yesterday's backup and the photos customers uploaded today are no longer on the site. They are still in the Before restore backup, so you can download it and pick them out.

The database does not go back with it. If your app keeps file names in its database, say a table of slips pointing at uploads/slip-123.jpg, restoring only the files can leave rows pointing at files that no longer exist, or files no row uses. To take both back, also restore the database from a backup close to the same time on the Databases tab. Their daily backups are not taken together, so before a big change press Back up now in both places, one right after the other.

When you only need a few files back

The console's restore replaces the whole storage. If only a few files went missing and many new ones arrived since, do not restore everything: download the older backup, take the files you need, and send them back through your app's admin page. If the app has no such page, ask your AI for one, for example:

This app keeps user uploads under /bw-data/uploads.
Build an admin-only page for uploading files back into that folder.
It may write only under /bw-data/uploads, never outside it.
If a file with the same name exists, ask before overwriting it.

SQLite apps: watch out for an incomplete copy

Backups are taken while the app runs. If someone saves data at the very moment the database file is being read, the .db file in that backup may be incomplete. SQLite's own documentation warns against copying a database file while it is being written, and recommends VACUUM INTO, which makes a correct copy even of a database in use.

The safe route is to have your app make its own copy on the persistent storage; the platform's backups then carry a complete copy along. Give this to the AI that looks after your code:

This app uses the SQLite file /bw-data/app.db (change it to the app's real file).
Add a daily copy made from inside the app's own process with VACUUM INTO,
written to /bw-data/backups/app-YYYY-MM-DD.db, deleting copies older than 7 days.
Do not do it from another container or a schedule: another container cannot see the file locks the app holds.

Those copies are files on the persistent storage, so they count against your package; a few are enough. And before big work, such as moving data or changing the table structure, press Back up now while the site is quiet.

A backup plan that works

The platform takes care of the daily backups and of copies before the changes it knows about. What is left to you is backing up before big work it cannot foresee, such as an AI running a script that moves files; keeping a copy outside BrewInTH; and unpacking a backup now and then to check it really works. A backup you have never opened is not one you can rely on.

FAQ

Can I back up without the Backups add-on?

Only the copies the platform takes before a restore, before data files are replaced and before the storage shrinks. Daily backups and Back up now need the add-on. Without it, ask your AI to add a download button to your app's admin page and download your files regularly yourself.

Does the site stop during a backup?

No. Backups are taken while the app runs; only a restore stops the app, briefly.

I deleted a backup by mistake. Now what?

The Delete button in the table acts at once, without asking again. The file moves to the server's trash rather than vanishing, so if you need it, talk to the BrewInTH team with the project's name and the backup's time.

Do static sites have this panel?

No. A static site does not write files of its own, so it has no persistent storage. Its files are the ones you uploaded, which the release history and the Files tab's trash already cover.

Why can't I back up or restore?

A greyed-out button with a note that backups are an add-on means the account has no Backups add-on. A message that a backup or restore is already running means waiting for that job to finish. A message that the machine running the project cannot take volume backups yet means it is time to tell the team.

Summary

The files your app writes to /bw-data are your users' real data, and nothing catches them when the app deletes them. Get the Backups add-on for daily backups, press Back up now before big changes, download a .tgz to keep outside BrewInTH, and before you press Restore, think of the files that arrived after that backup and of the database that may need to go back with it. The current files are always kept first, so a wrong restore can be undone.

Open your projects →