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

Velero Restore of Namespace #1541

Open
astephanh opened this issue Dec 14, 2023 · 3 comments
Open

Velero Restore of Namespace #1541

astephanh opened this issue Dec 14, 2023 · 3 comments

Comments

@astephanh
Copy link

Hi,

What i don't understand for this approach is this: How can i restore a namespace including a arangodb operator + arangodeployment if every time an arangodeployment CR is created (in this case by the restore process) a new PVC is created?

In the case of velero i'll end up with 2 PVC, the old one and the new empty one. In case of a Cluster DR this really is not a good way to restore your data.

First thing - we are using ArangoDeployment, not Deployment. So all limitations known for apps/v1 Deployment does not affect ArangoDeployment. In our case names are constant for ArangoDeployment managed pods and in sync with generated ArangoDB cluster resource names. All operation for upgrade or pod recreation works because name will not change when pod will be recreated. 

In case when you remove ArangoDeployment CR and create new one - we do not want allow to bind PVC from different ArangoDeployment to newly created pods. Bootstrap of ArangoDB is complex procedure - so we cannot simply bind data from old ArangoDeployment because of different encryption keys. We know StatefulSet allow you to bind same PVC after StatefulSet recreation, but it would not work in our case.

So, unless you delete ArangoDeployment CR, data is persisted. It include upgrade, crash restore, machine restart. Upgrade of ArangoDeployment is just update of image in Spec section. 

Solution with StorageClass is example of case when you want to keep data when you remove ArangoDeployment CR by mistake. 

Best Regards,
Adam Janikowski.

Originally posted by @ajanikow in #503 (comment)

Best Regards
Stephan

PS: In my opinion, statefulsets are the way to go here.

@ajanikow
Copy link
Collaborator

Hello!

The problem with statefulsets is that we can't manage pods as separate pods (and manage the order of restarts, upgrades etc).

You can restore Namespace by creating a pre-filled ArangoDeployment or using https://github.com/arangodb/kube-arangodb/blob/master/docs/api/ArangoDeployment.V1.md#specsingleindexmethod in the Enterprise Edition

Best Regards,
Adam.

@nikita-vanyasin
Copy link
Contributor

@astephanh FYI: we have some instructions on manual restore of ArangoDeployment if you still have PVs: https://arangodb.github.io/kube-arangodb/docs/how-to/recovery.html

Best,
Nikita

@astephanh
Copy link
Author

astephanh commented Dec 15, 2023

Hi,

i tried to set this up using a single instance, but every time i put something in .status..members.single the deployment would terminate.

i understand, that using statefulsets is not an option here. but what about stable naming though?

instead of arango-server-sngl-2gytwvae-79baa1 maybe define an option to overwrite the name to something like arango-server-sngl-node1 with should then result in a stable pvc name. With this, the backup / restore would just work.

it may not be a good cluster solution but it would make things way easier for simple single-node installations.

Best Regards.
Stephan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants