Backups: let customers take and manage database backups in Studio

オープン
  • 何か問題がありますか？
#2,008 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@dawsontoth がすでに取り組んでいます。

2026年11月9日 から。

  • #2079 @dawsontoth による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
database, full-stack

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
5
フォーク
4
平均マージ
1日 19時間
マージ済み PR（30日）
144

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

HarperFast/studio のほかの issue

HarperFast/studio の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。