SOLVED How to downgrade server storage by separating storage in Cloudron?

[robi]

it's not as much about server disk usage as it is about backup size.

[girish]

yeah, as @robi said, as long as all your data will fit in a 50GB server, it's fine. Roughly, if you see the current df -h output of your server and if it's < 50GB, you are good.

[d19dotca]

Okay, I'll see if that works. If it doesn't though... is the recommend process to implement the steps from the Storage docs ahead of time before restore, and then presumably restore will automatically place it on the new external disk at that point because of the link to it?

[girish]

@d19dotca Yes, correct. you can symlink appsdata and boxdata to an external disk post installation but before starting the restore.

[d19dotca]

@girish Hi Girish. I tried this tonight, following the steps in the documentation, but every time I did this (I tried a few different times to make sure I was following the steps properly, it was really just copy & paste though so couldn't really go wrong unless missing a step or typo'ing the mount location), I got an error of /home/yellowtent/boxdata is not a valid path. Screenshot below.

When I restored again and then didn't setup the symlinks, it worked fine (or is currently working fine, hasn't finished restoring at this moment yet).

Either I'm doing something wrong, or those steps don't actually work in this scenario.

[girish]

@d19dotca Interesting, I cannot find that error message in our code. Did you happen to enter '/home/yellowtent/boxdata` anywhere in the form above? Also, what version of Cloudron is this? Maybe I am looking at the wrong place.

[d19dotca]

@girish

Latest version of Cloudron... 6.1.2.

There's no reference to /home/yellowtent/boxdata in the restore page, and it only came about after making the changes before restoring from the default directory on the Storage docs. I was able to still run the steps afterwards but just barely, had about 1.5 GB left on my server after import was completed, so it took a while to also move that data since there was barely any room for it to copy to while it proceeded with the change. All seems to be running fine now, just didn't work at the restore point.

[d19dotca]

@girish This still seems to be an issue. I tried it last night to see if I could reproduce it and sure enough I could. I think this is a bug, unless I'm doing something wrong?

Here's the steps I took (if you want to reproduce it):

1. Create new server
2. Connected via SSH and ran the following commands:
   sudo apt-get update
sudo fdisk /dev/sdb
sudo mkfs.ext4 /dev/sdb1
sudo mkdir /mnt/cloudron-boxdata
sudo mount /dev/sdb1 /mnt/cloudron-boxdata
sudo nano /etc/fstab
sudo wget https://cloudron.io/cloudron-setup
sudo chmod +x ./cloudron-setup
sudo ./cloudron-setup
   (reboot)
   sudo systemctl stop box
sudo systemctl stop docker
DATA_DIR="/mnt/cloudron-boxdata"
sudo mkdir -p "${DATA_DIR}"
sudo mv /home/yellowtent/boxdata "${DATA_DIR}"
sudo ln -s "${DATA_DIR}/boxdata" /home/yellowtent/boxdata
sudo systemctl start docker
sudo systemctl start box
   (reboot, though tried without rebooting here too)
3. Restore Cloudron from backup (in my case located on OVH Object Storage if that part matters at all). It will fail at this part, after a minute or two it will give the error from the screenshot in the comments above around "/home/yellowtent/boxdata is not a valid path"

Can someone please confirm if my steps are invalid or if there's truly a bug here?

[girish]

@d19dotca Strange, I cannot find this "is not a valid path" string anywhere in the code base. I am just trying this out now.

[d19dotca]

@girish Yeah I couldn't find it either, I looked too. Very strange. I have been able to reproduce it multiple times though so I'm hoping it'll be easy for you to reproduce too. If not though then perhaps my commands are wrong? They shouldn't be though, I copied them from the documentation for the steps to change the default directory, etc. I'll be interested to hear back when you've had a chance to test it, or if anyone else has ever run into this issue or sees the commands as incorrect or something. Thanks for looking into this! Right now it's kind of a blocker for me being able to setup new server instances and migrating the data from the previous server since the hard disks are too small for how much data I have currently, thus the need for that external disk on setup.

[girish]

@d19dotca thanks for your patience! I was able to reproduce it and have made a fix. The error was from the tar-fs node module that we use, it's unable to handle symlinks. Indeed, I knew about this earlier and we already resolve the symlink when restoring apps (i.e for the appdata) but not for the box. Fix is simple enough, it will be in next release.

[d19dotca]

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