mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-10-11 00:37:52 +02:00
Update Deployment-to-Kubernetes-and-Minikube.md
1 parent
02f3b09691
commit
152622e4fc
1 file changed
+60
@@ -257,6 +257,66 @@ section of the operator README.
|
||||
> dedicated workers for erasure coding and volume balancing. If you run an admin
|
||||
> server, the plugin is the richer option.
|
||||
|
||||
## Backup and restore
|
||||
|
||||
The Operator can back up a cluster's **filer metadata** as point-in-time
|
||||
snapshots and continuously **mirror file data** to cloud object storage or a
|
||||
PVC. Destinations, schedules, and mirrors are declared on the `Seaweed`
|
||||
resource under `spec.backup`; on-demand backups and restores are separate
|
||||
`SeaweedBackup` / `SeaweedRestore` resources. This maps to the underlying `weed`
|
||||
primitives: a metadata snapshot is a one-shot `fs.meta.save` (restored with
|
||||
`fs.meta.load`), so it is schedulable and retained; data replication is a
|
||||
continuous `weed filer.backup`, so it runs as an always-on mirror `Deployment`.
|
||||
|
||||
```yaml
|
||||
apiVersion: seaweed.seaweedfs.com/v1
|
||||
kind: Seaweed
|
||||
metadata:
|
||||
name: seaweed1
|
||||
spec:
|
||||
image: chrislusf/seaweedfs:latest
|
||||
master: { replicas: 1 }
|
||||
volume: { replicas: 1, requests: { storage: 10Gi } }
|
||||
filer: { replicas: 1 }
|
||||
backup:
|
||||
storages:
|
||||
s3-main: # an S3-compatible destination
|
||||
type: s3
|
||||
s3: { bucket: my-seaweedfs-backups, region: us-east-1 }
|
||||
credentialsSecret: s3-backup-creds # AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
|
||||
schedule: # cron-driven metadata snapshots
|
||||
- name: nightly
|
||||
schedule: "0 2 * * *"
|
||||
storageName: s3-main
|
||||
keep: 7 # retain the 7 most recent completed snapshots
|
||||
dataMirror: # continuous weed filer.backup to the sink
|
||||
- storageName: s3-main
|
||||
---
|
||||
apiVersion: seaweed.seaweedfs.com/v1
|
||||
kind: SeaweedBackup # an on-demand metadata snapshot
|
||||
metadata: { name: adhoc-1, namespace: default }
|
||||
spec:
|
||||
clusterName: seaweed1
|
||||
storageName: s3-main
|
||||
---
|
||||
apiVersion: seaweed.seaweedfs.com/v1
|
||||
kind: SeaweedRestore # restore a snapshot back into the cluster
|
||||
metadata: { name: restore-1, namespace: default }
|
||||
spec:
|
||||
clusterName: seaweed1
|
||||
backupName: adhoc-1
|
||||
```
|
||||
|
||||
A storage can target S3, Google Cloud Storage, Azure Blob, Backblaze B2, or a
|
||||
PersistentVolumeClaim (`type: filesystem`). The leader-elected scheduler creates
|
||||
a `SeaweedBackup` each time a cron fires and prunes completed snapshots beyond
|
||||
`keep`; restore reconstructs the filer namespace via `fs.meta.load`. When the
|
||||
referenced cluster has mTLS enabled, the backup/restore jobs and the mirror
|
||||
mount the same `security.toml`/TLS material. For the full field reference,
|
||||
storage credential keys, and the metadata-vs-data model, see the
|
||||
[Backup & Restore](https://github.com/seaweedfs/seaweedfs-operator/blob/master/BACKUP_SUPPORT.md)
|
||||
documentation in the operator repository.
|
||||
|
||||
# Recommended: Helm Deployment
|
||||
|
||||
The SeaweedFS Helm chart is the most flexible and maintained way to deploy SeaweedFS on Kubernetes.
|
||||
|
||||
Reference in new issue
Block a user