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.

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

warning

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.

1. Configure a notification recipient. Backup activation is blocked until at least one email or Telegram recipient exists. See Manage alert rules.
2. Enable the backup service, setting the backup capacity for the whole database. See Manage Backup service.
3. Create a full backup job. See Configure backup schedule.
4. 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
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
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