Cloudron Forum

Note to self: Use an external drive that has twice the disk space needed by the apps as a temporary mount point to restore to! Because it will need to download a copy of the whole backup, then unpack and finally bin the download. D'oh! Step 1: Find a disk with sufficient space to restore to (apps space x 2) Step 2: Mount the disk and symlink to the original location in the backup file Step 3: Restore and then reset the storage location (or point it to where ever your new mount point is). Got it all working now. Perhaps it's time to invest in a bigger SSD for my home server

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

@3246 said in Restore Error - Cannot access 'error' before initialization: Do I always have to use the backup config (I did manage to change the path manually to point it to the latest backup after uploading the restore file)? No you don't need the backup file. https://docs.cloudron.io/backups/#restore-cloudron did you try to completely remove the mount and the configure it new?

@mehdi this was indeed a bug in the restore code path. the setupToken, as you guessed, should be sent in the top level object and not as part of the backupConfig . Fixed 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).

@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 Well, it was incredibly satisfying to see these important apps, which I use the most, get restored first. Would it be difficult to "rank" apps by usage, which could then be used for Install by Restores, or Migrations? Anyway, it worked out super well for me. Thank you!

@girish That'd be awesome, thanks Girish. I'll hope it's ready for this week though for everyone and that should fix it.

@jordanurbs thanks! I will look into making this automatic. https://git.cloudron.io/cloudron/box/-/issues/800

Thanks a bunch @girish worked like a charm

@girish HAH nevermind. Its me being a Linux noob... turns out I mounted the drive itself not the partition. The files are there.

@christiaan I submitted a new image to the marketplace. Will leave a note here when it gets approved. Sometimes it's immediate and sometimes it takes 2-3 days.

@girish right, I figured that out! Thank you! I am downloading that 10gb data now.. wuih! You are saviour!

@scooke Thank you. Good tip. I shall use this.

@girish easy enough!

@mehdi This my friend is a good point, thank you for pulling me out of the tunnel. lol

Thanks guys! Yeah it's a weird issue for sure and likely very rare, so it's probably not a big deal. If it helps for reproducing it, here's a few notes: 27 apps installed at the time of backup/restore Backup & Restore used tgz format with OVH Object Storage in BHS region Backup from a LunaNode m.8 model in Toronto region Restored onto OVH b2-7 model (though since upgraded to b2-15) in BHS3 region LunaNode instance (source) was running Ubuntu 18.04 at backup time, and OVH instance (target) was running Ubuntu 20.04 at the time of restore. When I restored, I very nearly ran out of disk space on the included disk, leaving only ~ 1.5 GB of space remaining. When restoring initially, it failed to restore because of the issue I reported earlier, though doubtful this is a root cause. Immediately moved the boxdata to external disk afterwards though, so plenty of space free soon after the restore was done once I moved boxdata off (20 GB in emails alone so it takes up a lot of space). Hopefully those notes above help in some small way. No worries though if you can't reproduce it, I imagine it's a very rare scenario and could have even been completely unique to me somehow. Hopefully others can chime in though if they experienced anything similar where cron wouldn't run at all (whether a restore involved or not, as I'm still not 100% certain it had to do with the restore though I presume it did).

@girish That's awesome, thanks Girish! Glad I wasn't crazy hahaha

@girish ah alright, was moving some LAMP 7.2 and 7.3 to 7.4., clone does not work in that scenario

@yusf OK, thanks, when you find time, feel free to reach on the support mailbox.