You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello there,
I just wanted to ask the question in the title.
In my opinion, the VolumeSnapshotAPI is useful over of SeaWeedFS, because the system is fault resilient, so you can trust the FS. But sometimes you need to start from a backup for some random reason (imagine your data are not corrupt or lost, but you literally broke a database), so having the CSI with VolumeSnapshotAPI capabilities, storing inside SeaWeedFS, but in another directory or whatever would be a great approach.
What do you think? Do you know a better approach to cover this type of cases in Kubernetes with SeaWeedFS?
(please, not Velero, that adds a lot of maintenance overhead sometimes)
Thank you!
The text was updated successfully, but these errors were encountered:
Hello there,
I just wanted to ask the question in the title.
In my opinion, the VolumeSnapshotAPI is useful over of SeaWeedFS, because the system is fault resilient, so you can trust the FS. But sometimes you need to start from a backup for some random reason (imagine your data are not corrupt or lost, but you literally broke a database), so having the CSI with VolumeSnapshotAPI capabilities, storing inside SeaWeedFS, but in another directory or whatever would be a great approach.
What do you think? Do you know a better approach to cover this type of cases in Kubernetes with SeaWeedFS?
(please, not Velero, that adds a lot of maintenance overhead sometimes)
Thank you!
The text was updated successfully, but these errors were encountered: