Unmounting volume leaves the "backup volume"
-
Aye! Thanks @girish for the help beyond cloudron topics! I thought cloudron would take over and ignored the info from Hetzner on this. I am smarter for the future! - However, it worked fine while the hard disk was mounted as a backup volume.
Even though the problem is solved, can you answer a question for me? - Where do I remove the disk as a backup volume? I could not find the option during my search for a solution
-
@kk_cloudron said in Unmounting volume leaves the "backup volume":
Where do I remove the disk as a backup volume? I could not find the option during my search for a solution
You have to set another backup location. For example, you can switch to
Filesystemand put the path as/var/backups(this is also the default after you install cloudron). -
@girish In preparation to move my Cloudron from Hetzner (where I have a mounted volume for backup) to another provider, it seems as if the proper change beforehand is to follow your guidance above: "switch to Filesystem and put the path as /var/backups (this is also the default after you install cloudron)". Is this correct?
-
@joseph Apologies for the confusion. My mistake. It was not the backups (which are already mapped to a S3-compatible service) but rather the disk where critical Cloudron data was stored. I was using a drive mapped to a Hetzner volume. Here is a screenshot:
What are the proper steps to move these folders back to the root folder (/) on the main disk (/dev/sda1)?
The new server I am migrating to will have a much larger disk and no external volume.
-
@crazybrad how did you move boxdata, platformdata into the other drive (/dev/sdb) ? By using symlinks? The approach stated here - https://docs.cloudron.io/storage/#default-data-directory ?
-
@joseph Yes. My appsdata and boxdata folders are symlinked to the external mount point. If you could help provide the correct sequence of commands to stop the Cloudron, copy the folders back to the default location, and restart the Cloudron, I would be very grateful. I get the general idea of what is needed, but I don't want to make a mistake and break my installation. Of course the first step is an extra complete backup!
-
@crazybrad one more question... why are you moving them back (given that you seem to migrate to a new server anyway) ? It's not needed to move them back to migrate, the backups contain all the data. You can just restore with the latest backup to the new server and then if everything is good , you can delete the server and this mounted drive, no?
-
@joseph Interesting. Hadn't considered that. Can you please provide a link to the recommended procedure? Would I start by adding another Cloudron to my account (say a free version), restore the backup, and then move the paid license to the newly created Cloudron?
-
@crazybrad like this https://docs.cloudron.io/backups/#move-cloudron-to-another-server . Do a full backup. Then just restore that backup to another server. The data, dns, license and everything will automatically move . When migrating, you can just power off your old server, don't delete it yet! This also make sure 100% that you are actually accessing the new server and not your old one. Only when you are happy that the data is fully well migrated, should you delete the old server.
-
@ joseph I think I've got it. In checking my DNS, all of my domains are managed at Porkbun, one of the integrated domain/DNS providers. Does that mean that upon restoring the backup, the new Cloudron will detect the change in IP address of the server and request updates @ Porkbun using the API credentials enrolled in my Cloudron?
-
@crazybrad personally what I do is to use the "dry run" feature which enables you to do a full restore on the new server and check everything is working there before updating the the DNS see https://docs.cloudron.io/backups/#dry-run
Also NOTE: (unless the UI has been updated to make it harder to miss since I last did it) be sure not to miss the little "looking to restore" link at the bottom when setting up the first domain for a new Cloudron install (I've done that before and then had to start all over again).
-
@ joseph Thank you. I will try this process. @jdaviescoates Much appreciated tip about "dry run". I will combine your collective wisdom and go forth and conquer!
-
@joseph Completed the migration to the new server, but I ran into several errors restoring apps. Roughly 70% of the apps were in an error state, with a message similar to this one for Listmonk: Docker Error: Unable to pull image cloudron/app.listmonk.cloudronapp:202411131609490000. Please check the network or if the image needs authentication. statusCode: 500
The event log shows a successful attempt to restore again: App was restored from version 1.9.0 to version 1.9.0 using backup at 2024-12-14-150347-189/app_
but multiple attempts at this have failed.
In all but two apps (Listmonk and Mail), retrying (with an occasional app restart) has gotten this to work for each app. Services have plenty of resources. The server is large. I am unable to try Recovery Mode for this app as the error state locks me out of that option (and the restarting option as well).(Rebooted the server. Mail restored next time, but ListMonk took ~ 2 more times to work)TwoOne questions:(1) How can I resolve this?(2)- Why did this happen in the first place?I followed the backup, restore, dry run, sync DNS, update certificates process and all seemed to work fine.
-
@crazybrad said in Unmounting volume leaves the "backup volume":
Listmonk: Docker Error: Unable to pull image cloudron/app.listmonk.cloudronapp:202411131609490000. Please check the network or if the image needs authentication. statusCode: 500
This is the ipv6 rate limit issue which many are hitting. dockerhub seems to pushed some bad implementation of rate limits and it's wholesale cutting off network providers from accessing dockerhub. We have a workaround in place now for the new release.
