Backups and restore
Every project is backed up each day, encrypted, in another place. Restore it all, a database or the files, take a database back to a minute, or download a ZIP.
Updated 17 Oct 20266 min read
Every project is backed up 5 days a week, without you doing anything: its databases and the files its apps and sites keep. Backups are encrypted before they leave the server, and kept in another place, away from your project's location, for 7 days. Open your project's Backups tab to see them, back up now, restore, or download one.
What's in a backup
| Part | What's kept |
|---|---|
| MySQL, MariaDB and PostgreSQL | A consistent copy of each database, own or shared, made with its own dump tool |
| Valkey | A Valkey used for queues, from its disk. A cache isn't backed up: it keeps nothing to save. |
| Apps | The files an app keeps between deploys, like Laravel's storage folder |
| WordPress and PHP sites | All the site's files |
Your code isn't in it: every version of it is already kept on the app's Code card, and built again from there. Your apps' variables aren't in a download either.
When it runs
5 days a week, on days and at an hour of your project's own. The Backups tab shows the Next backup.
Back up now, on the Backups tab, up to 3 times an hour.
Before a risky change: a database's import or update, and a restore, waits for a fresh backup first. These show as Before a change.
Only what changed since the last backup is sent, and data that's the same is stored once, so backups stay small.
Now and then a backup place is off for a while. Your backup is then kept on your project's own server, the Backups tab says Waiting to be sent, and it's sent on and removed from the server as soon as the place is back. You can't restore it until then; every backup before it restores as usual.
How long they're kept
Each backup is kept 7 days, and the newest one is always kept, however old. While an account is suspended its projects aren't backed up, and the backups they have are kept 30 days.
When a project is deleted, its backups are emptied 7 days after it's gone.
Where they're kept, and how safe
Encrypted on the server, before anything leaves it, with a key of your project's own.
In another place: never only in the location your project runs in.
Locked: a server can add a backup but can't delete or change one, even if someone breaks into it. Old backups are removed only by our cleanup, by the rules above.
Checked: every backup is checked once it's stored. One that fails its check shows Failed its check, can't be restored or downloaded, and a fresh backup runs at once. Each week we also restore a sample of projects' backups in full, in a sandbox, to be sure they work. The Backups tab shows each backup's check and the Last restore test.
If your project is marked to keep its data in one country, in the project's Settings, its backups stay in that country too. If we have no backup place there yet, the Backups tab says so, and we're told.
Restore a backup
Only the account's owners can restore.
Open the project's Backups tab, and choose Restore next to a backup.
Under What to restore, choose Everything, Only a database (then Which database), or Only files.
Under Where to restore it, choose Into your project (it shows its name, like Into duka), or Into a new environment.
Choose Restore.
Into your project: how things are now is backed up first, so you can come back to it. Then the apps' files and the databases are put back as they were. Into a new environment: we make a new environment beside production and restore into it, so you can look before you switch. Your project stays as it is. Open it from Environments. See Environments and previews.
The page follows each step live: Backing up how it is now, Restoring, then Checking that it works. You're told by email and under the bell when it's done. One restore runs at a time in a project. If a restore doesn't finish, the project is as it was, and the backup of how it was is in the list.
Take a database back to a minute
Your own MySQL, MariaDB and PostgreSQL can go back to any minute of the last 7 days, not only to a backup. They send their changes every 5 minutes, so a mistake at 10:42 costs minutes, not a day.
On the Backups tab, under Back to a minute, choose the Database.
Pick The minute, between the times it shows.
Choose Restore to this minute.
How it is now is backed up first. Its users keep today's passwords. It starts a few minutes after a database's first backup. A shared MySQL and a Valkey can be restored from a backup instead.
Download a backup
Only the account's owners can download.
Choose Download next to a backup.
It's packed as one ZIP file, under Downloads. When it shows Ready, choose Download ZIP.
The ZIP holds files/<app>/… for each app's files and databases/<name>.sql for each database, so it opens anywhere, without us. It's ready for 24 hours. You can download 3 backups a day, of up to 5 GB.
Your backups in your own Google Drive
We recommend it: your backups are then yours, in your own Google Drive, as well as safe with us until they get there. Once a project copies to your Drive, its backups are made by that plan and sent to your Drive, and we don't keep them ourselves after that. A backup before a risky change, like a restore or a database update, is still kept with us for 7 days.
Under Your own copy, an owner of the account can choose Connect Google Drive. We ask Google only for the files Tanzahost makes, never the rest of your Drive. Then set how often (Every day or Every week, at an hour in UTC), What to copy (Files, Databases or both), how many Copies to keep (1 to 60), and a Password for the ZIP of at least 10 characters.
Each copy is a ZIP encrypted with AES-256 with your password before it leaves our server, so 7-Zip, WinZip or Keka open it. It goes in your Drive's Tanzahost Backups folder, and the oldest go once there are more than you keep. Nobody can recover a lost password, us included. To restore from a copy, choose it, type its password, and restore it like any backup. Disconnecting stops the copies; the ones in your Drive stay there.
What it costs
reading today's pricesBackups tab shows the Space used and what it costs a month.
When backups aren't set up
If the Backups tab says Backups aren't set up yet, there's no backup place to keep them in yet. They start by themselves, every day, as soon as there is. Until then, keep your own copy of anything you can't lose: export a database or download your files from the file manager.
Example: Asha's bad import
At 10:42, Asha runs a query on duka's MySQL that sets every price to zero. Last night's backup would bring the prices back, but lose the morning's orders. So on the Backups tab she uses Back to a minute: she picks mysql and 10:41, and chooses Restore to this minute. Her prices are back, with every order up to 10:41, and the backup taken first holds the database as it was after the mistake, in case she needs anything from it.