@shan Why not keep using the method you have with larger number?

Managing backups like we mange mailboxes does sound like a good idea, and can have checkboxes for daily, full, etc. per app, and more.

@d19dotca I can't believe I missed that. Literally read right past it. Thank you!

Hello guys, everything is back online (thanks to Cloudron’s out-of-this-world backup feature).

I am grateful for all your help.

@perler Wow, that is a very good catch!
The kind of; "huh, why have I not thought about this one before, yet it seems obvious"... As you say it, the idea comes from an instant need once in front of a specific situation which requires a solution that no one seems to have a previous need.

And while reading how you describe it, in pops in mind like; "yeah, that would be master piece to be able to restore the files only, in an app as Nextcloud". So true.

There could be others apps as well, but at first thought NC is the very first candidate for such desirable feature, because of the very nature of the app which holds files, and potentially team communications and email boxes as well. And this is where we can see that restoring the whole pack at once, especially for a well active NC app, could produce unexpected outcomes. Depending of course on how the app is used inside an organization.

I don't think it would be a required feature for all apps. But then, if it's easier to implement as a general backup feature then why not. I would vote for this.

Thanks for the heads-up.

@girish done

There is a bug in the current release that the code crashes when trying to send a notification if a backup failed. This is fixed . I think in the coming releases we can explore more notification options but atleast now you should get an email.

@girish said in Backup size:

👍 Thanks, I deleted files in the Nextcloud recycle bin. Now, after a reboot, Cloudron System Info shows 4.3 GB for the Nextcloud instance. (I had to delete the nginx config of a stopped app to get the system to reboot.) Thanks, I'll keep both folders. I have no particular goal to remove Discourse or its backups. I measured /var/backups size by adding up the three separate folders that FileZilla showed me, but I now understand that some files are hardlinks. And the Backup data shows only 4.87 GB now, so my disk is small enough for me to move on. Thank you!

@scooke I went to each individual app and pointed to the fileshare with the full path "/media/fileshare/2020-07-01-0500/app_backup.tar.gz.enc" and restored those backups.

As for the second part, Azure adds the following "actimeo=30" switch to the cifs share that goes in your /etc/fstab file that causes the connection to time out if the backup takes too long. Once that is removed, reboot the server and the new backups will complete without issues.

The doc actually says "The Backup Cleaner checks if entries in the database exist in the storage backend and removes stale entries from the database automatically." I will fix the progress message to match this.

@girish Ah I didn't see this until too late, sorry. I had tried to start over to a degree by destroying the current backup disk and mounting a new disk instead then clearing out the backups history and seeing if that starts working better for me. So far so good, but if the issue comes back I'll certainly send the email out and enable remote support, as I agree there seems like some odd issue for sure.

So I tried mounting the folder from the Synology NAS and then the storagebox again and everything is working fine. I have misnamed the remote directory. Sorry for the unnecessary topic.

@MichaelF This is showing the backup size in your current backup configuration. So, you have to go to the folder where you have configured your backups. Are you not able to clean up existing backups using the clean backups button? You can temporarily change the retention policy to one day to make it remove it all the old stuff past one day.

@girish Ah, thank you. Found them. That freed up 22GB for me 😅

Good point. I checked the services and some of them are yellow (without error, but stalled in loading). I've restarted one app that uses mongodb and now the backup works. But it's very close to the memory limit. If this happens again, I'll increase the memory assigned.

Thanks for pointing it out.

@jagadeesh-s2104 Clean backup is a good idea. Thank you!

This is super helpful. I’m hoping we see something like this as a feature baked in though. Like multiple backup sources with different schedules

@scooke I tried "cleaning" but didn't make a difference.
Will keep an eye on it.

@gobenizzle This only means that the backup task was "interrupted" when a backup was in progress. The code assumes that if a backup got arbitrary interrupted (i.e not via the stop button), it is because the box code crashed. That assumption is true most of the time but you probably ran out of disk space and rebooted etc which killed the backup task.

Nothing to worry. If you trigger a new backup, it will go away.

@WaffleUncle So you are using the Import button in the app section, correct - https://docs.cloudron.io/backups/#import-app-backup ?

In your case, it looks like your backups were in the file system and not external. If that is the case, you have to fill up the 'Import Backup' dialog manually:

Upload the backup app_client.xxx.tar.gz to somewhere in the server like /tmp/app_client.xxx.tar.gz.

In the import UI, Choose Filesystem

Put the path as /tmp/app_client.xxx.tar.gz

It should import now.

To add to what @BrutalBirdie said, Cloudron is designed for hosting apps (and not databases as such). This means that you can't create databases separately and there is no UI to create/delete databases. It's designed for hosting your app which needs a database. The database is provisioned and updated as needed transparently as part of the app install/update/uninstall process. Very similar to heroku.

Just wanted to point that out, because Cloudron is not a classic style server management panel where one can manage "databases".

This was indeed a bug. Fixed in https://git.cloudron.io/cloudron/box/-/commit/2434e813836e7837162c1798794d04655227d9cf . Thanks a lot @avatar1024 . It will be part of 7.1.2

I have clarified the text a bit more now.

@wisemetalhead whoops, I somehow missed this question. Not sure why the backup listing disappeared, I think we will have to investigate what happened using the logs.

But since the backups itself are still there, you can use the CLI tool's cloudron import to restore (if needed).

For future reference i managed to clear it up by using a slightly modified version of Girish's search command. It seems like the length limit applies to path length not just the filename length

find . -type f -print|awk '{print length($0), $0}' | sort -n

Went into the web interface and deleted / renamed files longer than 156 bytes and finally cleared trashbin/versioned files

(wipes all deleted / old versions of files - careful):

sudo -u www-data php -f /app/code/occ versions:cleanup sudo -u www-data php -f /app/code/occ trashbin:cleanup

@robi @girish agreed it would be awesome if there was an automated way to handle this in the future

@joesitsolutions said in Restoring app from backup?:

I have the .zip file. Cannot figure out why I keep getting "backupFolder path is protected"

You can only create backups to specific paths on the server. Many of the paths are "protected" to make sure that the folders won't get overwritten by updates or are used by the system. This is just a hardcoded list of paths:

const PROTECTED_PREFIXES = [ '/boot/', '/usr/', '/bin/', '/lib/', '/root/', '/var/lib/', paths.baseDir() ];

(the baseDir above is /home/yellowtent/). You cannot create backups in subdirectories of the above paths.

I understand you are using restore here though and not backup 🙂 The restore logic uses the same validation logic for paths and you have copied the backup to under /home/yellowtent/. Instead, copy the backup in some path like /mnt/backups/ or /srv/backups/ and try to restore, that should work.

@girish Thank's a lot 👏👏

@scooke
@murgero

I am working on get my FreeNAS NFS mount working for the backups, but that seems to be a bit difficult to get the permissions working.

If you have experience with NFS, you might have an answer on my problem here...

https://forum.cloudron.io/topic/5927/cloudron-backups-on-truenas-nfs-mount/3?_=1636891033300

However thanks!

@girish awesome, glad to know it was a bug. Should take away the OVH object storage concern. 🙂