Add volume snapshot and backup/restore support #130

New issue

Open

opened 2026-09-15 06:55:35 +00:00 by a73x · 0 comments

a73x commented

2026-09-15 06:55:35 +00:00

Owner

Acceptance criteria

Define the initial snapshot/backup mechanism and distinguish same-host snapshots from backups stored outside the source host.
Specify stopped-VM, crash-consistent or application-consistent capture guarantees and any guest coordination required.
Define tenant ownership, authorization, retention, deletion and capacity accounting.
Restore into a new claim without overwriting the source; verify integrity and define placement/size constraints.
Make partial/failed backups and interrupted restores observable and safely retryable.
Demonstrate restoring known data from an off-host backup when the source volume is unavailable.

References: docs/volumes.md; internal/agent/reconcile/volumes.go; internal/server/store/volumes.go. Start with a documented design and bounded first implementation.

Volume data lives in one sparse raw file on its assigned host. It survives VM deletion, but the current volume API provides no snapshot or backup/restore workflow for recovering from host-disk loss or accidental data changes. ## Acceptance criteria - Define the initial snapshot/backup mechanism and distinguish same-host snapshots from backups stored outside the source host. - Specify stopped-VM, crash-consistent or application-consistent capture guarantees and any guest coordination required. - Define tenant ownership, authorization, retention, deletion and capacity accounting. - Restore into a new claim without overwriting the source; verify integrity and define placement/size constraints. - Make partial/failed backups and interrupted restores observable and safely retryable. - Demonstrate restoring known data from an off-host backup when the source volume is unavailable. References: docs/volumes.md; internal/agent/reconcile/volumes.go; internal/server/store/volumes.go. Start with a documented design and bounded first implementation.