Backup & Restore overview
Backup on FPT Database Engine is built from four pieces, and they only protect data when all the ones you need are in place. The most common mistake is stopping after the first.
Backup on Kafka is deprecated and will be removed on 15 September 2026. Every backup and restore function keeps working until that date. On removal, all existing Kafka backup files are permanently deleted and can no longer be restored.
If you need to keep Kafka backup data, restore it to a new database cluster before the retirement date. No other engine is affected.
| Piece | What it does | On its own |
|---|---|---|
| Backup service | Reserves storage capacity and holds the policy every job uses | Backs up nothing |
| Backup job | The schedule that actually produces restore points | This is what creates recoverable data |
| PITR | Retains archived logs so you can recover to an exact moment | Needs a full backup job, and takes effect only after the next full backup |
| Restore | Creates a new database from a restore point or a moment in time | Never overwrites the original |
Enabling the backup service does not back anything up. Data is only protected once a backup job exists and has run at least once.
The order to set it up in
Each step blocks the next, and the console enforces most of it.
- Configure a notification recipient. Backup activation is blocked until at least one email or Telegram recipient exists. See Manage alert rules.
- Enable the backup service, setting the backup capacity for the whole database. See Manage Backup service.
- Create a full backup job. See Configure backup schedule.
- Enable PITR, if you need second-level recovery. See Enable & Disable PITR.
Steps 1 through 3 can also be done during provisioning, in the additional services step of Create a database.
Backup job types
| Type | Copies | Available on |
|---|---|---|
| Full | The whole database | Every supported engine. On Kafka, only until 15 September 2026. |
| Differential | Only what changed since the last full backup | PostgreSQL, MySQL, MariaDB, SQL Server |
A differential job depends on a full job. Retention is set per job, as a number of copies to keep.
Recovering
Both recovery paths create a new database rather than repairing the existing one, so budget quota for a second database and plan to repoint your application afterward.
| You need | Use | Available on |
|---|---|---|
| The state at a backup | Restore from backup | Every supported engine. On Kafka, only until 15 September 2026. |
| The state at an exact moment | Recover to point in time | PostgreSQL, MySQL, MariaDB |
Copies outside the platform
Backups live on isolated dedicated storage managed by FPT. If you also need a copy under your own control, whether for long-term retention, an off-site copy, or handing data to another system, push backup data to S3.
What it costs
Backup storage is billed separately from the database, and PITR adds to it because archived logs are retained alongside the backups. Both are worth estimating before you enable them, since capacity applies to every backup job on the database rather than per job.
Next steps
- Manage Backup service to start the setup
- Reporting overview to review backup activity across databases
- Features to check what your engine supports