Backups: let customers take and manage database backups in Studio

Start by reading Studio’s existing instance pages and its admin command channel, which the issue says can send commands to one instance. Then trace the instance operation route and how pages check Harper versions and admin permissions. Done means the page supports all five backup actions, shows job progress and errors, identifies the node for each backup, and explains storage limits and restore availability.

Problem

Harper 5.2+ can take checked, incremental backups of a database and manage them: list, verify, delete and prune. Studio has no screen for any of this, so a Fabric customer can only back up a database by typing raw commands into the Operations console.

What core already provides (harper)

• Commands, all admin-only:
  • create_backup takes a backup of one database. Backups are incremental, and file attachments (blobs) are included by default. It runs as a background job.
  • list_backups lists a database's backups, with id, size and time.
  • verify_backup checks a backup can be read. It runs as a background job.
  • delete_backup deletes one backup.
  • purge_backups keeps the newest N backups and deletes the rest.
• Engine: RocksDB only, which is Harper 5's default.
• Where backups live: on the node's own disk, under Harper's backup folder (storage.backupPath), one folder per database. On Fabric this is the same disk as the instance's data.
• Moving or removing a node: Fabric moves a node by building a new one that copies the data through replication, then deleting the old one (moveInstance.js). Backups aren't database data, so they aren't copied over, and they're deleted with the old node. The same goes for a node removed when a cluster scales down.
• Source: dataLayer/rocksdbBackup.ts, design notes, epic harper#2100.

What to build

• A Backups page for each instance, shown only on Harper 5.2+ and only to admin users.
• Pick a database, then:
  • Take a backup, and show its progress from the background job until it finishes or fails.
  • List its backups, with id, size and time.
  • Verify a backup, and show the result.
  • Delete a backup, with a confirmation.
  • Keep only the newest N backups, with a confirmation that names how many will be deleted.
• Send backup commands to one specific instance (/HDBInstance/:id/operation), not to the cluster. A cluster-level command goes to whichever member is first in the running list (Cluster.js#L400), so the next list could reach a different node and the backups would seem to vanish.
• On a cluster, say which node each backup lives on.
• Show Harper's own error message when a command is refused.
• Explain, on the page:
  • backups are stored on the node's own disk and use its storage
  • they don't protect against losing that node, and they're deleted if Fabric moves or removes the node
  • restoring isn't available in Studio yet

Acceptance criteria

• A customer can take, list, verify, delete and prune backups of a database from Studio, without the Operations console.
• Backups taken on a node keep showing in Studio for that node, whichever cluster member is running first.
• Non-admin users don't see the page.
• On Harper below 5.2, the page is hidden or explains that it needs 5.2.

Out of scope: restore

Core isn't ready for restore on Fabric:

• Released Harper versions refuse online restore of any database whose tables changed shape while Harper was running, for example an insert that added a new attribute. That covers most databases in use. The fix, harper#3201 (harper#3120), is merged for 5.4 and isn't being backported to 5.3.
• Harper refuses to restore a database a running app uses while Harper is running. It asks for the server to be stopped and the restore run from the command line, which Fabric customers can't do. Core's fix is still open: harper#2638 and epic harper#2632.
• Core's restore design refuses restore on any node with replication peers (harper#2632). So restoring a multi-node cluster needs its own design.

Downloading a backup (get_backup) is also out of scope.

Needs a decision

Backups stay on the node's own disk, so they don't survive losing, moving or removing the node, and Fabric doesn't take them on a schedule. Should Fabric store backups somewhere else, or schedule them? Neither is part of this issue.

Dependencies

No central-manager or host-manager work is needed for this screen. Studio already sends admin commands to a single instance through Fabric's command channel, and that requires "update" permission on the cluster in Fabric.