Cloudron Forum

@james said: This is the only issue I see in the log. So no clues as to why the integrity checker failed on my Jellyfin too?

@Dummyzam I think you can set the prefix to /mnt/OnlyZpol/CloudronBackup . That will make cp use absolute paths.

Hello @davejgreen @davejgreen said: Is migration of users and email boxes only possible by using the "looking to restore" button for restoring full Cloudron backups? Yes. @davejgreen said: And is that button only available when you first install Cloudron? Yes. @davejgreen said: We have a second server up and running with a newer version of Ubuntu and Cloudron and were thinking about importing each app individually (after backing it up from the old Cloudron onto a backup site hosted on the new Cloudron), but I'm not sure if there's a way to import the users and email boxes? If not, I guess this approach will not work for us, we'd have to use a third site for a full backup. This is not recommended. The new server should be installed with the exact Cloudron version you are currently using. Otherwise you wont even be able to restore the system backup. @davejgreen said: Do we need to purchase another one for the new Cloudron instance? No. Once migrated simply write a mail to support@cloudron.io and inform us and we will switch the licence to the new server. To minimize downtime use the dry-run backup restore option: https://docs.cloudron.io/backups#dry-run-restore This way, you can restore the whole system, without changing DNS records and can validate each app / step manually. The old server stays up and running, serving all the apps, mail, chat etc. After a review of the migration, when ready to switch permanently, go to Domains view and click Sync DNS.

@girish said: @sansguidon might be best to wait for the next release which should be out shortly. This bug is only in rsync and not in tgz. With the manual patch it did work . I'm not sure to understand your advice anyway, for me the backups are a very critical part of if not the most important of Cloudron, so they should not be skipped, and my understanding is that with rsync blocked my backups are local and no copy exists outside of my server, if I'm not mistaken? This seems risky enough and a sufficient motivation to take immediate action, or please correct me if I misunderstood.

I changed nothing, but it is working today. I imagine what is happening is that the upstream storage drops connections occasionally and cloudron simply passes that on to the user instead of having a retry loop in the background. So, I still believe this functionality would benefit from being more robust, as before it would manage 20-50MB per go before drop, and if the thing was in a retry loop it would be able to get the archive out by just resuming downloads. I realise it is annoying having to deal with people who insist on unreliable storage... but it is what we have.

fixed - after increasing redis memory it works now (will keep an eye on it from now on). Thank you very much! Good day today as I learned something new

I have fixed this for the upcoming release

In the end I used S3 compatible option to set this up successfully. IDK why I could not get the Scaleway option to work. Thanks all for your help & input

https://git.cloudron.io/platform/box/-/commit/5ba8a054501139410fccbd7258ed9097590bc50e

@james Uptime Kuma on a different instance. We had no significant downtimes since last week. Yet, sometimes the backup task gets aborted.

Will do, James. I have not been able to recreate the held lock issue. I was starting/stopping jobs a fair bit at one point, and can't... be precise about where in the backup cycle those cancellations happened that a cleanup might not have happened. I will watch for it in the future. When I said there was no RAM pressure, I meant that was true for the server. However, my jobs all had 1GB of RAM. Your suggestion clued me in; because that value must be set after you setup the backup job, I had never noticed it before... or, not realized how critical it might be. I have bumped them all to 6GB of RAM, and so far, I've been seeing backup successes. Barring the question below, I'd say we could close this issue. The lesson learned is that I need to provide my backup tasks more RAM. Because I have some RAM to spare, I'm going aggressive, and giving things 6GB. I did not attempt to settle on a smaller amount, for anyone who comes along after--- I just gave the tasks a limit that I considered to be "a lot" in this context. I still see some things like the errors below. The backup completes successfully, but I'm unclear why there would be errors like these sprinkled throughout the backup. Is the relative path full/snapshot/app_... actually correct? Or, should that be a full path (e.g. the base path I provided at setup time along with the relative path)? In the command that succeeds, it is a full path. Feb 13 16:11:00 box:shell filesystem: ssh -o "StrictHostKeyChecking no" -i /tmp/identity_file_d82bc09e-a419-4d60-84bf-95d631fd0ebb -p 22 user@nas.lan cp -aRl full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1 full/2026-02-13-210356-064/app_git.jadud.com_v1.37.4 errored BoxError: ssh exited with code 1 signal null Feb 13 16:11:00 at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:82:23) Feb 13 16:11:00 at ChildProcess.emit (node:events:519:28) Feb 13 16:11:00 at maybeClose (node:internal/child_process:1101:16) Feb 13 16:11:00 at ChildProcess._handle.onexit (node:internal/child_process:304:5) { Feb 13 16:11:00 reason: 'Shell Error', Feb 13 16:11:00 details: {}, Feb 13 16:11:00 stdout: <Buffer >, Feb 13 16:11:00 stdoutString: '', Feb 13 16:11:00 stdoutLineCount: 0, Feb 13 16:11:00 stderr: <Buffer 63 70 3a 20 63 61 6e 6e 6f 74 20 73 74 61 74 20 27 66 75 6c 6c 2f 73 6e 61 70 73 68 6f 74 2f 61 70 70 5f 63 37 34 65 66 63 63 66 2d 64 32 37 33 2d 34 ... 50 more bytes>, Feb 13 16:11:00 stderrString: "cp: cannot stat 'full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1': No such file or directory\n", Feb 13 16:11:00 stderrLineCount: 1, Feb 13 16:11:00 code: 1, Feb 13 16:11:00 signal: null, Feb 13 16:11:00 timedOut: false, Feb 13 16:11:00 terminated: false Feb 13 16:11:00 } Feb 13 16:11:00 box:storage/filesystem SSH remote copy failed, trying sshfs copy Feb 13 16:11:00 box:shell filesystem: cp -aRl /mnt/managedbackups/1ec6c6b4-7566-4369-b2ce-466968b00d5d/full/snapshot/app_c74efccf-d273-46c9-8afe-3fd427bb78c1 /mnt/managedbackups/1ec6c6b4-7566-4369-b2ce-466968b00d5d/full/2026-02-13-210356-064/app_git.jadud.com_v1.37.4 Feb 13 16:11:07 box:backuptask copy: copied successfully to 2026-02-13-210356-064/app_git.jadud.com_v1.37.4. Took 7.889 seconds

There is also a Logs dropdown button in the backups view which opens the corresponding log file in the logsviewer, from there the full logs can also be downloaded, avoiding the need to ssh into the server.

Hello @jadudm Always happy to help.

Yes, you have to adjust the schedule manually to not overlap. Otherwise, if a single app is backing up to multiple sites in parallel, they will get serialized internally (with the lock).

Hello @miednr Yes, for stopped apps a new backup will not be created since nothing has changed. See: https://docs.cloudron.io/backups#retention-policy For installed apps and box backups, the latest backup is always retained regardless of the policy. This ensures at least one backup remains preserved even if all backups fall outside the retention policy. This also preserves the latest backup of stopped apps when not referenced by any box backup. Did you know you can also archive apps? https://docs.cloudron.io/apps#archive

@girish Thank you, after upgrading to Cloudron version 9.0.17 (latest), everything started working again.

I solved my problem by updating Cloudron to version 9.0.17. There’s no longer any need to run a backup before a manual app update.

@tecbox thanks for the update!

@difficult222 I have replied to your ticket.

@jdaviescoates yes, there was a sshfs backup bug and I think 9.0.14 and 9.0.15 had fixed for exactly this. Unfortunately, Cloudron has no way to "force update" a bugged release.