Backup and Restore

Table of Contents

1. Why backups matter
2. Enabling backups
3. The Database Back Up card
4. The backup list
5. Restoring
6. Cancelling the backup subscription
7. Beginner Pitfalls

---

1. Why backups matter

A running database is not a safe copy of your data. A mistaken DELETE without a WHERE, a bad migration, or a bug that corrupts rows is stored faithfully and instantly — the database did exactly what it was told. A backup is a snapshot from before the mistake that you can go back to.

Backups on Cloud+ are a separate, paid, recurring subscription on top of your plan, so they're opt-in.

2. Enabling backups

You can turn backups on at creation (the Back Up → Enable checkbox on the Database Information step) or later via EDIT on an existing database. Ticking Enable reveals backup tiers, each with a monthly price, shown as radio cards:

The tiers are Basic, Standard, Enterprise and Premium, and they differ in how often a backup runs and how long it is kept:

• Frequency — from every hour up to every 24 hours (Basic is daily).
• Retention — 1 month, 1 year, or 999 days (Basic keeps 7 days in the example below).

The cards show the exact schedule and price for each tier. These change over time, so read them on the card rather than from this page.

Each card describes what you get — Back Up (an automatic save of your database) and a Retention period (how long backups are kept).

When you click UPDATE after enabling a tier, a Subscribe to Database Backup dialog appears with the exact charge, for example:

Activating this feature applies a recurring fee of X KHR per month for Basic Plan.

Click SUBSCRIBE NOW to accept. A Backup Enabled Successfully message confirms it, and your balance in the header drops by the fee. Read the dialog before accepting: it's recurring, not one-off.

3. The Database Back Up card

Once subscribed, the detail page gains a Database Back Up card above Your Plan. It shows your tier (e.g. Basic), how often backups run (Daily), how long they're kept (e.g. 7 days), and the monthly Pricing. Click VIEW BACK UP to see the files.

4. The backup list

The page titled "<database-name> – Back up List" has a table:

Right after you subscribe the list is empty — "Looks like you don't have a Back Up list yet!" — because the first backup only appears after the first scheduled run. That's normal, so come back after the next cycle.

The .sql extension tells you what a backup is: a plain SQL script that recreates your data. The tiny 92 B size in the example is just a nearly empty test database.

5. Restoring

1. In the backup list, find the backup from before things went wrong (the timestamp in the name helps).
2. Click RESTORE. A Confirm Restore dialog shows the File Name, Date and Time, and Size.
3. Click RESTORE in the dialog to confirm.
4. Watch the Status column and open History to see how it went.

Restoring puts the database back to that point in time, so treat it as destructive: any data written after the backup was taken is not in that file and should be assumed gone. If you're unsure, first export what you can (with pg_dump, for PostgreSQL) from the current state.

6. Cancelling the backup subscription

Backups keep running, and keep billing, for as long as the subscription is active. When you enable backups on an existing database, the EDIT form shows a Subscription Detail note: "Your database is protected. Backups run automatically and will continue as long as your subscription stays active." with a Cancel Subscription link.

You can also cancel from the account's Subscriptions panel, which lists every Cloud+ plan you hold (Storage, Run App, Database, Database Back-Up, and so on) with its status, price, and billing period, for example 09/Oct/2026 – 08/Nov/2026. Click Cancel Subscription on the Database Back-Up row.

A Schedule Cancel Plan dialog explains what happens: your plan stays active until the end of the current billing cycle, then cancels automatically on that date, and you can reactivate any time before then. Click CONFIRM to schedule it (or CLOSE to back out).

So cancelling is scheduled, not immediate:

• The row's status changes from Active to Schedule Cancel, and its link becomes Cancel Schedule-Subscription.
• Backups keep running until the cycle ends, since you've already paid for it.
• The EDIT form changes to match: "Your database is still being backed up. Backups will continue until your subscription ends." Clicking Cancel Schedule-Subscription there (or on the Subscriptions row) undoes the scheduled cancellation, so the backup carries on without a gap.

Your existing backup files aren't mentioned in the dialog, so don't assume they stay available after the subscription ends. Download or restore anything you need before the cycle's end date.

7. Beginner Pitfalls

• Assuming backups exist because the database is "managed". They're opt-in and billed separately.
• Never testing a restore. A backup you haven't restored is only a hope. Restore one into a throwaway database now, while nothing is on fire.
• Ignoring the retention window. With 7 days of retention, a mistake you notice on day 9 can't be undone.
• Restoring over live data without thinking. Everything written since the backup is lost.
• Forgetting backups are a recurring cost. If you delete a practice database, also check that you aren't still subscribed to its backup.
• Reading "Cancel Schedule-Subscription" as another cancel button. It cancels the scheduled cancellation, which keeps the backup going.
• Expecting an immediate stop. Cancelling takes effect at the end of the billing cycle, not straight away.