Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do you use Velero? Let us know! #1327

Open
VMmore opened this issue Mar 28, 2019 · 9 comments

Comments

@VMmore
Copy link
Collaborator

commented Mar 28, 2019

This really isn't an issue, but we'd love to hear about your use of Velero so we thought we'd post this to find out more from you.

Please feel free to add a comment below and let us know.

@lledru

This comment has been minimized.

Copy link

commented Mar 28, 2019

Hi, we used to run ark for protecting our stateful production workloads for almost a year, now we finish migrating to velero. We are internal service provider and give our customers the capacity to self enroll to a backup policy. It simply rocks ! Thanks a lot ! As usual with heptio's work :)

@dharmab

This comment has been minimized.

Copy link

commented Mar 29, 2019

We're currently using it to back up Kubernetes objects in Azure and AWS. We're interested in using it as a migration tool to migrate workloads between clusters in different cloud accounts or even between self-managed and cloud-managed clusters.

@harshal-shah

This comment has been minimized.

Copy link

commented Mar 31, 2019

We use velero to gather hourly backups of all application resources of our clusters. We have also used it to perform critical migrations such as change of kubernetes networking plugin on a running production cluster or moving our production environment to eks. Both these cases were achieved without incurring any downtime.

@VMmore VMmore closed this Apr 1, 2019
@VMmore VMmore reopened this Apr 1, 2019
@agolomoodysaada

This comment has been minimized.

Copy link

commented Apr 16, 2019

We use it as our first line of disaster recovery for AKS and GKE clusters. We have additional manual cron backups using native mongodump for MongoDB and elasticsearch snapshots for Elasticsearch. We would love to use Velero for cross-cloud migrations as well. Having native Velero plugins for the currently manual cron jobs would be a great improvement.

@skriss

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

@agolomoodysaada would love to hear more about how you'd see the mongo & elastic backups integrating into velero. How are those run today? Do you use a sidecar, or exec into the workload pod, or something else?

@agolomoodysaada

This comment has been minimized.

Copy link

commented Apr 16, 2019

We're using ES Snapshot API and Mongodump containers using Kubernetes Cronjob objects. Both are backed by Google Cloud Storage and Azure Blob Storage. The cronjob talks to ES Snapshot API and ES handles the rest against its corresponding blob storage. Mongodump container pipes the dump stdout from a mongo secondary pod into a remote gzip file. But it would be really awesome if Velero had a plugin for each of those datastores that could track the progress of these backups and leverage those during the restore events using builtin Velero hooks for example.

Today's alternative is to rely on Restic, but unfortunately it still feels too manual and complicated to setup (adding annotations for each volume and so on).

I imagine an API like the following

# elasticsearch
velero plugin install elasticsearch
velero plugin elasticsearch add my-es-cluster "http://my-es-cluster.my-es-namespace:9200"

# mongodump
velero plugin install mongodb
velero plugin mongodb add my-mongo-cluster "mongodb://USERNAME:PASSWORD@my-mongo-cluster.my-mongo-namespace:27017/production?readPreference=secondaryPreferred"

# velero backup and restore
velero schedule create <SCHEDULE NAME> --schedule "0 7 * * *"
velero restore create --from-backup <SCHEDULE NAME>-<TIMESTAMP>

UPDATE:

We would much prefer to rely on restic + hooks if the experience was easier. For example, I want to be able to kubectl apply -f myresticselectors.yaml and Velero would automatically backup all volumes based on those selectors. For example, we can create the following

kind: VeleroResticResource
spec:
  volumes: my-data # defaults to all volumes
  selector:
    "statefulset.kubernetes.io/pod-name": "mongodb-replicaset-0"
    "release": "mongodb"
  pre-backup-hook: "mongo --eval 'rs.stepDown(); db.fsyncLock()'"
  post-backup-hook: "mongo --eval 'db.fsyncUnlock()'"
@agolomoodysaada

This comment has been minimized.

Copy link

commented Apr 24, 2019

@skriss let me know if my comment should be its own Github issue as a feature request

@tillepille

This comment has been minimized.

Copy link

commented May 20, 2019

We are using it experimentally to backup our Cert Manager so we can retain our LE generated Certificates when tearing down a dev-cluster.
There is no workload yet but we will probably back it up, too. All into an s3 bucket.

I discovered some pitfalls with velero but read more at #1508

@VMmore VMmore self-assigned this Jul 23, 2019
@skriss

This comment has been minimized.

Copy link
Member

commented Sep 25, 2019

@VMmore do you want to leave this open, or can we close it given it hasn't seen any activity in several months?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.