Back up and restore your database on BrewInTH

A website with a database holds something valuable: customer lists, orders, bookings, student scores. If the code is lost, an AI can write it again. Data your customers typed in is gone for good.

And data is lost more easily than people expect. Not because a machine breaks, but because of one wrong command: an AI runs a migration that drops a column, or a data-fix script misses its condition. This guide explains what is backed up on BrewInTH, how to switch database backups on, how to restore, and when to take a backup by hand.

In short
✅ Backups are the Backups add-on, ฿99 a month, covering every project in the account. Without it the platform keeps no copies of your database
✅ With it, each database is backed up automatically every day, keeping the latest 7, and Back up now works at any time
✅ You restore by yourself in the console; a safety copy of the current data is always taken first
✅ Backup files can be downloaded and kept elsewhere, and should be, regularly
✅ Take a manual backup every time before an AI changes table structure or edits data in bulk

What is there to back up on one site?

A site on BrewInTH has three kinds of things, and each goes back in a different way.

• The site's code. Every deploy is kept as a release. Go back from the Releases tab › Release history with Restore this release; nothing extra to buy. (Keep your source code on your own machine or in Git as well.)
• The database (PostgreSQL, MySQL, MariaDB, MongoDB). Rolling back the code does not roll back the data. That takes database backups, the main subject of this guide.
• Files in persistent storage (/data), such as pictures users upload. The same add-on backs this volume up every day.

Redis is temporary storage (a cache) and has no backups. The app should be able to rebuild what is in it; never keep important data in Redis alone.

What the Backups add-on gives you

Backups on BrewInTH are an add-on called Backups, ฿99 a month, available with any plan. One purchase covers every project in the account.

• Automatic daily database backups, keeping the latest 7; older ones are removed for you
• Manual backups at any time with Back up now, keeping the latest 5 manual ones
• Restore, download and delete backup files yourself in the console
• Daily backups of the app's /data volume

Without the add-on the platform keeps no copies of your database. You then need your own way of keeping copies, for example having the AI add an export button to the app's back office and downloading the file regularly.

If you bought the add-on and later let it lapse, the existing backup files stay downloadable and restorable, but no new ones are made.

Switching database backups on

1. In the console open Plans & billing, scroll to Add more resources and buy Backups (tick Renew automatically every month if you never want a gap).
2. Open the project, go to the Databases tab, choose the database, and scroll down to the Backups panel.
3. Check that Automatic daily backup (keeps 7) is ticked (it is on by default).
4. Click Back up now once, so there is a first copy right away instead of waiting for the daily run.

A moment later a new row appears in the table with the status Completed and a file size. The table shows the kind of each backup: Daily (made by the platform), Manual (made by you) and Before restore (made by the platform ahead of a restore).

Restoring a database

Use this when data has been damaged and you want to go back to a saved copy.

1. Databases tab › Backups panel: find the copy you want by its date and time.
2. Click Restore on that row.
3. Read the warning, type the database name to confirm, and click Restore now.
4. Wait for the job to finish, then open the site and check the data.

Know this before you click:

• All current data is replaced by the data as of that backup. Orders or members that arrived after that time will be gone.
• A safety copy of the current data is taken first (kind "Before restore", the latest 3 are kept). If you restored the wrong copy, you can still go back to the point just before you clicked.
• The app may be briefly unavailable during the restore. Pick a quiet hour.
• A restore does not change the code. If the current code needs a table or column the old copy lacks, roll the code back to a matching release or have the AI run its migration again.

Download backup files and keep them elsewhere

Backup files are stored on BrewInTH's servers. Click Download on any row to keep your own copy. The file type follows the database engine:

• PostgreSQL: a .pgdump file (opened with pg_restore)
• MySQL / MariaDB: a .sql.gz file (compressed SQL)
• MongoDB: a .mongo.jsonl.gz file (compressed JSON, one document per line)

Important data should never exist in one place only. Download a copy to your computer or your own cloud storage about once a month, or before any big change, and store it safely: the file contains all of your customers' data.

When to click "Back up now"

Daily backups cover the unexpected. At some moments, though, always take one by hand first:

• Before an AI changes table structure (a migration), especially dropping or renaming columns
• Before a bulk data script, such as repricing every product or removing duplicates
• Before importing data from a file or an old system
• Before deploying a version with many changes

Give your AI these rules up front:

Data rules for this project on BrewInTH
1. Before running a migration that drops or renames a table or column, or any command that
   changes data in bulk, stop and tell me. I will click "Back up now" in the console, then
   let you continue.
2. Never run migrate:fresh, DROP, TRUNCATE or any wiping command as a fix.
3. A migration must not lose existing data. If a column has to go, do it in two releases
   (stop using it first, drop it in a later one).
4. When done, tell me which tables changed and whether the existing data is intact.

When an AI has damaged the data: do this, in order

1. Stop the AI first. Do not let it "try a fix"; it may overwrite more.
2. Open the Backups panel and find the latest copy from before the incident.
3. Judge how much data arrived after that copy. If little, restore and re-enter it by hand. If a lot, have the AI explain what exactly is damaged first; sometimes a single table can be repaired.
4. Restore, then check the site.
5. If unsure, use Talk to support before restoring.

FAQ

Can the free plan buy Backups?

Yes. The Backups add-on is available with any plan, including the free one.

What time does the daily backup run?

Once a day per database, at least 24 hours after the previous copy; there is no fixed hour. The Last backup line in the Backups panel shows when the newest one was made. For a copy at an exact moment, click Back up now.

Can I restore only some tables?

The console's restore replaces the whole database. For a few tables only, download the backup file and have an AI working on your computer pull the rows you need out of the file and put them back.

Can I restore files in /data myself?

There is no restore button for /data in the console yet. To bring back files in persistent storage, use Talk to support.

Are backups kept after I delete the project?

No. A database's backup files are removed together with the project. Always download a copy before deleting.

Why is Redis not backed up?

Redis on BrewInTH is meant as a cache and job queue. Data that must last belongs in the primary database.

Summary

Code goes back through the release history; data needs backups. Switch on the Backups add-on and click Back up now once; from then on the platform backs up every day and keeps the latest 7. Take a manual backup every time before an AI touches table structure, download a copy to keep elsewhere regularly, and when you do restore, the platform saves the current data first.

Get the Backups add-on →

Related articles

• PostgreSQL, MySQL, MongoDB or Redis: which database should you pick?
• Deploy failed or site slow? Let AI read the logs and fix it