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

added command to list all available snapshots to original post

@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. 🙂

@savity I can't reproduce this. Do you see any error on the minio side?

@jdaviescoates Awesome, thanks -- I missed that.

@nebulon : interesting about Nextcloud
I used to have 4 x Nextcloud instances in my Cloudron server (different projects). 3 of them about 10Gb of files (other smaller).
My backups were working but slow.
Even after switching to 'better' VPS provider.
So after testing Seafile for a while, I have moved 2 of the Nextcloud instances over to a single Seafile VPS (with different libraries for segregation). The other 2 Nextcloud instances will follow.

I have nothing against Nextcloud and been very happy for it for long time. But if it is really only being used for file collaboration and device syncing, and you don't actually NEED the extra facilities it provides, my personal view is that Seafile is a better solution.

So would be awesome to get Seafile onto Cloudron.
But I'm quite happy running it on a separate VPS.

@girish I haven't done the steps you suggested yet, I just reverted back to my Scaleway backups. But I will try again shortly. Thanks for checking in.

@timconsidine said in Moving Cloudron to new server : stop apps?:

that I didn't set the PTR record in the new VPS provider until I started the migration

I ran into exactly this problem the last time as well 😄

To conclude this, it was a memory issue. The instance as a whole was a bit overcommited.

If the backup task is idle, it won't consume any memory. Also Cloudron does not reserve memory based on the limits set, neither for backup nor for apps. The limit is just to avoid rouge apps or the backup task to bring kill other apps.

@leggias hm getting a SIGSEGV is odd here. If you like you can enable remote SSH support and send us a mail to support@cloudron.io mentioning your dashboard domain. Then we can take a direct look at your setup to get down to the issue.

@fbartels said in Backup Preference: Snapshot vs S3?:

Hi @jordanurbs,

the viability of snapshots for backup has for example been discussed in https://forum.cloudron.io/topic/4161/disc-snapshots?_=1628139201934.

Yes, and to quote what @nebulon pointed out there:

@nebulon said in Disc snapshots:

Disk snapshots or VPS snapshots don't work well with Cloudron, since backups are per-app and not per-server on Cloudron. This is to be able to rollback/restore individual apps without interfering with the system or other apps running on it.

Still for a secondary fallback backup solution this can still be recommended.

That's what I do. I do Cloudron backups to a Hetzner Storage Box, plus pay Hetzner for their automated backups, plus occasionally do a snapshot too.

Although really I ought to backup to another provider too, to avoid the potential issues @girish once had with DO.

I'll probably choose another eco VPS provider to do that at some point https://ud.coop/ecovps

@michaelf I put some notes on how to read the logs at https://docs.cloudron.io/backups/#cleanup-backups and also replied to your support ticket. Do you see any backups in linode object storage that are not listed in the logs? Otherwise, the logs do look fine to me.

@robi there is a already bunch of "workarounds" for rsync. Empty directories, executable bit of files cannot be stored in most object storage. So, there is fsmetadata.json file that stores this information outside of the files. When restoring, we use that file to restore back the state. I guess we can extend that file to also save and restore timestamps.

If anyone wants this leave a note and I can look into it in the future.

@rmdes I ended up setting up a local backup for Cloudron and use RClone to handle the backup. I've used RClone for years with no issue, and since going this route, no issues with my Cloudron backup.

Thanks a bunch @girish worked like a charm

@girish Ahhh I see. Thankfully right now backups only take 3-4 hours. I'm hoping once I'm at gigabit I can speed that up. My network is definitely a bottleneck rn.

@mazarian that's correct, the permission is the thing I fixed in 6.3.5. Glad it's working now and thanks for reporting back!