Backups: let customers take and manage database backups in Studio

Đang mở
  • Có gì không ổn?
#2,008 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@dawsontoth đang làm issue này rồi.

Từ ngày 9/11/2026.

  • #2079 của @dawsontoth — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
database, full-stack

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
5
Fork
4
Merge trung bình
1 ngày 19 giờ
Pull request đã merge (30 ngày)
144

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của HarperFast/studio

Tất cả issue của HarperFast/studio

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.