https://github.com/niki-on-github/volsync-webui
A web-based management interface for VolSync replication and backup operations on Kubernetes.
https://github.com/niki-on-github/volsync-webui
Last synced: about 1 month ago
JSON representation
A web-based management interface for VolSync replication and backup operations on Kubernetes.
- Host: GitHub
- URL: https://github.com/niki-on-github/volsync-webui
- Owner: niki-on-github
- Created: 2026-05-11T17:01:09.000Z (2 months ago)
- Default Branch: main
- Last Pushed: 2026-05-11T19:03:47.000Z (2 months ago)
- Last Synced: 2026-05-11T19:08:45.974Z (2 months ago)
- Language: Rust
- Size: 43.9 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Agents: AGENTS.md
Awesome Lists containing this project
README
# VolSync WebUI
A web-based management interface for VolSync replication and backup operations on Kubernetes.
> [!WARNING]
> The code was specificaly designed for my k8s setup. It is not a universal tool that covers every situation. If you would like to use this project, please review the conditions carefully or create a fork with the necessary modifications.
## Features
- **Dashboard Table**: View all ReplicationSources in a sortable table with status, last backup time, duration, and result
- **Detail Panel**: Click a row to see snapshot history, backup status, and restore controls
- **Backup Operations**: Trigger manual backups for individual apps
- **Restore Operations**: Restore from any available snapshot timestamp via the detail panel
- **Auto-Refresh**: Periodically updates the app list with configurable interval (default: 1 hour, no-overlap guard)
- **Manual Refresh**: Refresh button in header to fetch latest data on demand
## Deployment
A example deployment of this repository is in the `./example/` direcotry.
### Kubernetes
The container expects to run inside a Kubernetes cluster with access to the Kubernetes API.
Apply the RBAC configuration from the section below, then deploy the container:
```bash
# Create the ClusterRole and ClusterRoleBinding (see RBAC section below)
kubectl apply -f - < ← VolSync writes directly into app PVC
5. PATCH RD: restoreAsOf= (if provided)
6. Nullify status.lastManualSync ← triggers VolSync restore
7. Poll until restore completes
8. PATCH RD revert: restore original values ← reverts copyMethod, destinationPVC, restoreAsOf
9. Scale ALL deployments back to original replicas ← pre-scales before Flux wakes up
10. Unsuspend HelmRelease ← Flux sees no drift
11. Unsuspend Kustomization (best-effort) ← resumes GitOps reconciliation
```
The restore supports **multiple deployments per app** — all deployments matching `app.kubernetes.io/instance={base_app}` are scaled down and restored independently with their original replica counts.
### Storage Backend Compatibility
| Backend | Compatible | Notes |
|---------|-----------|-------|
| OpenEBS ZFS LocalPV | Yes | `copyMethod: Direct` writes directly into the app PVC, avoiding ZFS snapshot dependency issues |
| CSI drivers with working VolumePopulators | Yes | Works without snapshots |
| Any storage that supports PVC cloning | Yes | Direct method avoids cloning altogether |
**Important for ZFS users**: VolSync's default `copyMethod: Snapshot` creates a temporary PVC, restores data into it, takes a VolumeSnapshot, then deletes the temporary PVC. With OpenEBS ZFS, deleting the temp PVC destroys the ZFS dataset and its snapshots, making the snapshot unusable. `copyMethod: Direct` avoids this by writing directly into the application PVC.
### Error Handling
- If any step before the poll fails, the operation returns an error. The PVC and deployments are unchanged (restore was not triggered).
- If the restore poll fails (VolSync error or timeout), the ReplicationDestination spec still has `copyMethod: Direct` set. A subsequent retry will overwrite it. You can also trigger a HelmRelease reconciliation via Flux to reset the spec.
- If the RD revert fails after a successful restore, the data is already written to the PVC, but the ReplicationDestination spec may need manual cleanup (e.g., remove `copyMethod: Direct` and `destinationPVC`).
### Flux Kustomization Support
If your application is managed by a Flux Kustomization (e.g., in the `flux-system` namespace), set `VOLSYNC_KUSTOMIZATION_NAMESPACE` to the namespace where the Kustomization lives (default: `flux-system`). The restore will suspend the Kustomization to prevent GitOps reconciliation during the restore, then unsuspend it afterward.
The Kustomization name must match the base app name (e.g., app `gitea-backup` → base name `gitea` → Kustomization `gitea`).
### API Group Configuration
The default `VOLSYNC_API_GROUP=volsync.backube` matches modern VolSync installations. For older clusters still using the legacy API group, set:
```yaml
env:
- name: VOLSYNC_API_GROUP
value: "replication.storage.io"
```
## Kubernetes Compatibility
- Tested with Kubernetes 1.25+
- Uses `volsync.backube/v1alpha1` for VolSync CRDs (configurable via `VOLSYNC_API_GROUP`)
- Uses `helm.toolkit.fluxcd.io/v2` for HelmRelease (required for restore; backups work without it)
## Security Considerations
1. **ServiceAccount**: Runs with a dedicated SA, not default
2. **ClusterRole**: Requires broad read access — restrict in production
3. **No TLS**: Backend runs HTTP; TLS should be handled by ingress/controller
4. **No Authentication**: Currently no auth — expose via auth proxy (e.g., OAuth2 proxy) in production
5. **Secret Access**: Reads the actual secret name from `spec.restic.repository` on each ReplicationSource at snapshot time, so it always uses the correct credentials regardless of naming convention
## Developer Documentation
see `./docs`
## License
MIT