Backup a nextcloud instance

[s4ndalHat]

Hello community,

Recently i have tested volsync for various use case for our internal tools running on Kubernetes clusters.
I have faced a problem when trying to backup a Nextcloud instance using volsync.

I have no CSI drive that can do snapshot on the cluster, so I used the copyMethod Direct mode.
But the volsync-src-data pod which take restic snapshot is running then terminating suddenly and re-create itself numerous times, and that makes the backup never success (it's been 15 hours running non-stop).

So, my bucket s3 was filled with numerous snapshots which is not completed...

Do you have any insight ?

Kubernetes version: 1.28
Volsync installed with helm chart 0.10.0
Data mover: restic copyMethod Direct

[tesshuflower]

@s4ndalHat hopefully it's possible to get a bit more information from the system or from the mover logs themselves to help narrow down what the issue is.

Some suggestions for things to try and capture:

• the replicationsource itself - are there errors being captured in the .status?
• logs from the volsync-src-data mover pod when it runs - any errors in there?
• From kubernetes, is there any information about the mover pods? Are they getting killed due to OOM or anything like that?
• There should be a job (named something like volsync-src-data) created which is the one that's starting the mover pods - Can you look at the status of this job and run a kubectl describe job <jobname> on it?

[s4ndalHat]

Hello @tesshuflower,
So, I decided to activate unlock just to test if thats the problem, I'm getting this error :

I'm trying to reproduce the source issue

[s4ndalHat]

[tesshuflower]

Not sure what's going on here, if you just run in debug mode and let it sit there, the actual script in the mover pod will be sitting there idle (waiting for you to remove the file /tmp/exit-debug-if-removed). So not sure what is killing the pod

[s4ndalHat]

And also, its not caused by some perf issue because at this state, the volsync pod doesn't consume anything in CPU and RAM

[tesshuflower]

Not sure what to say here, I assume you don't get any more details from the job as to what is killing the pod?

The mover pod in debug mode should only be exiting itself if someone removes the file in /tmp, but then you should not get a Killed exit status, it would exit with 0 and think the job finished successfully.

Can you recreate with other pods/jobs/deploys in your namespace?

[s4ndalHat]

It works fine on other namespace, or even other pods in the same namespace,

Its especially this pvc which contains user data that doesn't work