Cloudron Forum

@joseph

Thank you for this clear information.

@girish Thank you for this profound explanation. It's great that you are using Hardlinks. I guess, that's a real space and time saver. I did my first restores with Cloudron via the UI yesterday.

A) What does Cloudron internally use for the restore? Snapshot vs. Timestamp?

B) What could/should anyone use to restore without Cloudron? Snapshot vs. Timestamp?

This should be different, to make sense...

As far as understand, A) is Snapshot and B) is Timestamp. Right?

While using Updraft Plus for WordPress backups, I get this warning message:

Dumping routines: (tq5av_fn_realmedialibrary_childs, wp_fn_realmedialibrary_childs) - (Failed - Your WordPress database user doesn't have sufficient privileges to read these stored routines. To be able to backup the routines, you must be the user named as the routine DEFINER(s), have the SHOW_ROUTINE privilege (for MySQL 8.0.20+ users), have the SELECT privilege at the global level, or have the CREATE ROUTINE, ALTER ROUTINE, or EXECUTE privilege granted at a scope that includes the routines.)

I would like to enter one of these commands to the WordPress CLI (MySQL):

GRANT SELECT on . TO 'wp_database_user'@'localhost';

GRANT SHOW_ROUTINE ON . TO 'wp_database_user'@'localhost';

I get these error messages:

ERROR 1045 (28000): Access denied for user 'wp_database_user'@'%' (using password: YES)

ERROR 1227 (42000): Access denied; you need (at least one of) the GRANT OPTION privilege(s) for this operation

I understand, that I don't have the privileges, but I am logged in as root. What could I do? Is there another way to reach my goal?

I would like to know, why Cloudron has a snapshot folder in the backup and a folder for each daily backup. This seems to be redundant, but surely does make a lot of sense. But, how does it work? I searched the forums, but did not find a discussion about this. Maybe it's to obvious? Would love to understand this miracle...

Hello @james

I investigated further and it has been just a copy of my backup storage box (snapshot + data folders) in the folder /home/yellowtent/appsdata/$APPID. I deleted all the folders that do belong to the backup and not to the app. Of course, everything works smooth now. Thank you!

Hey @james, I did not yet act. Just one question: will the deletion of the mal app also delete the data in the docker directory?

Hello @james I am using a Hetzner Storage Box (SSHFS / rsync) and I did not download the backup information and import it into the restore process by error. I thought, that Cloudron will "know" the correct App to restore, but I learned, that this was not the case and can not be the case, because the kind of the app (WordPress) is not indicator enough for the right instance. There could be several WordPress Apps in the system, what I did not think about. It was a mistake, but maybe it could be prevented, that all data is downloaded when not providing the remote path. Maybe the restore process should not run without the remote path?

Hello @james, it has been my first restore in fact.

You have to enter the backup path:
/foldername/remote path and I just entered /foldername/

Hello @james

Great to hear, you'll use this information to improve Cloudron.

Will the deletion of the App also reduce space used in the folder of docker?

Please have a look into your eMails... I did send you a very short screen video (< 60 seconds), that I wasn't able to attach here.

I see three relevant choices:

A) Delete WordPress-App with all the data via UI of Cloudron and restore it from backup...
B) Delete Data selectively via CLI
C) Complete Server Restore (2 days ago)

What would you recommend me to do?

Hello @james

Thanks a lot for your attention to this issue. My Apps do count 23 GiB in total. So, my WordPress is only 2 GiB. I can tell you, that my WordPress has not been compromised. But, it happened, that I entered "/folder" as backup path in the restore dialogue without the full restore path to WordPress. Then, Cloudron did not restore the WordPress-App alone. It went trough all the apps I have, downloaded them... and kind of installed them somehow. The data is saved in /home/yellowtent/appsdata/APP-ID ... There I find several copies of my general backup:

21.2 GiB [##############################] /snapshot
21.2 GiB [############################# ] /2026-02-13-010000-590
21.2 GiB [############################# ] /2026-02-18-010000-559
21.2 GiB [############################# ] /2026-02-17-010000-635
21.2 GiB [############################# ] /2026-02-16-010000-682
21.2 GiB [############################# ] /2026-02-15-010000-589
21.2 GiB [############################# ] /2026-02-12-010000-697
21.2 GiB [############################# ] /2026-02-14-010000-616
20.9 GiB [############################# ] /2026-02-11-010000-627
20.9 GiB [############################# ] /2026-02-10-010000-615
20.8 GiB [############################# ] /2026-02-09-123024-982
17.0 GiB [######################## ] /2026-02-13-185621-628
17.0 GiB [######################## ] /2026-02-17-230004-017
...
..
.

Is it safe, to delete these files manually?

Okay, I can now see, that a WordPress-Instance, I installed yesterday, takes 279 GiB and additionally var/libs/docker/overlay2 takes 47 GiB and var/libs/docker/volumes takes 12 GiB. That all seem quite much. What could be the reason?

Yesterday, I did a restore of a WordPress-Instance to a new Instance of WordPress. It may be possible, that I was entering the wrong path first, and it did "restore" not only the WordPress-Instance, but also Ubuntu and all the other 18 apps to this container. Is this possible? The second try did help, so WordPress works, but the SSD seems to be quite full and my nightly backups did fail, too.

What could I do? Should I delete the whole container? Or may I "repair it" by deleting obsolete files?

Hello @james, I am investigating with ncdu now. Thank you!

It's 9.000.000 files (566 GiB) and still counting up. I guess, it could be because I am using sshfs (rsync) for saving backups to a Hetzner Storage Box. Does this backup method do save the backups additionally to the local drive? Rsync is synchronizing the data, but it seems that the full backup is also saved many times to the local ssd.

I hope the scan will finish soon, because my ssd seems to be quite full.

But, I see, that it's scanning the storage boxes now. But the issue remains. My ext4 is 4/5 full. But, my usual daily full backup is "only" 23 GiB.

My Ubuntu takes 309 GB, my Docker takes 47 GB. What could be the reason for that and what could/should I do about it? I do not save any backups in my /ext4.

Will plane come to Cloudron? I am also interested in using plane self-hosted.

Yes, I have three backup destinations. But, I see und understand that's not a good idea to do multiple backups at a time... My server is not on limits (CPU 5%, RAM 33%, Disk I/O and Network I/O are low). I think, it will run through, but it's slower than doing the backups one at a time. But the reason seems to be the "lock" of Apps by Cloudron Backup. Will not repeat that... But for now, I will let the system find it's way during the night.

I got an idea, but I am not sure...:

I have three backups of the whole system at the same time. Two are stuck on WordPress and the third is very slow progressing on the same WordPress. I guess, the "lock" means, that the other two backups wait for the third process to "unlock" their "lock" on that App. Is this true? I start to understand. But, why is this the default behavior?

That is a WordPress (Dev).

Thanks @james

Cloudron Version is 9.0.17 and the logs do have repeated entries like that:

Feb 07 20:30:16 box:locks Attempt 824 failed. Will retry: Locked by 652
Feb 07 20:30:26 box:locks Attempt 1 failed. Will retry: Locked by 652
Feb 07 20:30:26 box:locks Attempt 825 failed. Will retry: Locked by 652
Feb 07 20:30:36 box:locks Attempt 1 failed. Will retry: Locked by 652
Feb 07 20:30:36 box:locks Attempt 826 failed. Will retry: Locked by 652

Last lines before that are:
2026-02-07T17:12:37.003Z box:backuptask copy: copied backupinfo successfully to 2026-02-07-171219-870/app_xyz.domain.com_v1.0.1.backupinfo
2026-02-07T17:12:37.007Z box:backuptask fullBackup: app xyz.domain.com backup finished. Took 1.105 seconds
2026-02-07T17:12:37.011Z box:locks write: current locks: {"full_backup_task_XYZ":null,"app_backup_XYZ":"652","full_backup_task_XYZ":null}
2026-02-07T17:12:37.011Z box:locks release: app_backup_XYZ
2026-02-07T17:12:37.011Z box:tasks updating task 653 with: {"percent":39.095238095238095,"message":"Backing up domain.com (8/18). Waiting for lock"}

First I thought this was related to my storage, but it also happens with the local backup (SSD).

I am waiting for my backups to continue for some couple of hours now. They keep stuck on 39% each.

The info in cloudron is: "waiting for lock" and in the logs hundreds of lines like this one appear:

2026-02-07T17:39:03.085Z box:locks Attempt 159 failed. Will retry: Locked by 652

CPU 5%, RAM 33%, Disk I/O and Network I/O are low.

cloudron-support --troubleshoot is all OK.

What could be the reason? I tried searching the docs and the forum. I would understand the message "wait for unlock", but what kind of lock does cloudron mean?

BTW: I am using different targets, of course...