Backups: let customers take and manage database backups in Studio

Aperta
  • Qualcosa non va?
#2,008 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
database, full-stack

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
5
Fork
4
Merge medio
1g 19h
PR unite (30g)
144

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/studio

Tutte le issue di HarperFast/studio

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.