Backup Restore Error - route unavailable post activation

[leemuljadi]

Found this error while restoring to a new VPS:

anyone got this issue before?

[james]

Hello @leemuljadi
The error you are experiencing route unavailable post activation would suggest your Cloudron is already setup.
Thus, a restore is not possible, because the Cloudron instance is already provisioned.

If you believe this is not the case, please ssh into your server and run the following command:

cloudron-support --send-diagnostics

and provide the output of that command here.

Thanks.

[leemuljadi]

Thanks @james , I found this
zsh: command not found: cloudron-support

can you suggest what is happening withs this issue and how to fix it?

[james]

@leemuljadi are you running this command as the root on the server itself?

[leemuljadi]

@james, yes, is there any installation needed for the command?

[james]

@leemuljadi
Please read the documentation about restoring Cloudron.
https://docs.cloudron.io/backups/#restore-cloudron

[leemuljadi]

@james it worked now, here is the result:
Generating Cloudron Support stats...Done
Uploading information...Done

Please email the following link to support@cloudron.io : https://paste.cloudron.io/busovomeqe

[james]

Thanks @leemuljadi I will now review it.

[leemuljadi]

@james, thanks please keep me posted

[james]

I found some erros.

du: cannot access '/home/yellowtent/appsdata/*': No such file or directory

That is a critical error.
But maybe expected.

From the box.log provided by https://paste.cloudron.io/busovomeqe I can see that your Cloudron is checking the DNS records and is failing.
From your last topic, I can gather that you are moving your instance to a new system but same IP.
This leads me to believe that you did not check the dry-run option when restoring and you did choose manual dns instead of some programatic one.

2025-05-27T05:45:05.622Z box:dns/waitfordns waitForDns: nameservers are ["ns3.nameserver.net.au","ns1.nameserver.net.au","ns2.nameserver.net.au"]
2025-05-27T05:45:05.623Z box:dns/waitfordns resolveIp: Checking A for my.teneight-test.com at 45.79.92.84
2025-05-27T05:45:05.804Z box:dns/waitfordns isChangeSynced: my.teneight-test.com (A) was resolved to 67.219.110.179 at NS ns3.nameserver.net.au (45.79.92.84). Expecting 45.76.157.117. Match false
2025-05-27T05:45:05.804Z box:dns/waitfordns resolveIp: Checking A for my.teneight-test.com at 2600:3c01::f03c:93ff:fed1:8135
2025-05-27T05:45:05.804Z box:dns/waitfordns resolveIp: No A. Checking CNAME for my.teneight-test.com at 2600:3c01::f03c:93ff:fed1:8135
2025-05-27T05:45:05.804Z box:dns/waitfordns isChangeSynced: NS ns3.nameserver.net.au (2600:3c01::f03c:93ff:fed1:8135) not resolving my.teneight-test.com (A): Error: queryCname ECONNREFUSED my.teneight-test.com. Ignoring
2025-05-27T05:45:05.804Z box:dns/waitfordns waitForDns: my.teneight-test.com at ns ns3.nameserver.net.au: not done 
2025-05-27T05:45:05.805Z box:provision restoreTask: error. BoxError: DNS A Record of my.teneight-test.com is not synced yet: ETRYAGAIN at Object.waitForLocations (/home/yellowtent/box/src/dns.js:206:30) at async restoreTask (/home/yellowtent/box/src/provision.js:195:13) { reason: 'DNS Error', details: {} }

This check would have been skipped if dry-run was selected in the restore process.

Since Cloudron is now stuck in waiting for the DNS, it can not start the restore process and is not creating the /home/yellowtent/appsdata/ folder.

---

Suggested solution

Please start from zero.
Restore your Cloudron and make doubly so sure that dry-run is selected, and you have set up your DNS overrides in the hosts file as described in the post before and the documentation.

[leemuljadi]

@james I did try out the dry-run, before but since it's was not working before and deleted the previous server (45.79.92.84) and spin another server (45.76.157.117), but the old server (67.219.110.179) still there. What should I do in this case?

[james]

Reset the new server to start from 0.
Follow the steps provided in the documentation.
https://docs.cloudron.io/backups/#restore-cloudron

[leemuljadi]

@james that's what I did before, I restore it to the new server and got that "route unavailable post activation".
isn't it because the cloudron backup is stuck with that previous IP address of the server that been deleted?
and can I still access cloudron dashboard now? as one of the step is creating backup and backup config, so how do I do this if I cant access the dashboard?

[leemuljadi]

@james if I reinstall the server again and run using dry-run what IP address should I put in the /etc/hosts file?

[james]

@leemuljadi said in Backup Restore Error - route unavailable post activation:

if I reinstall the server again and run using dry-run what IP address should I put in the /etc/hosts file?

It is explained in detail in the dry-run documentation. https://docs.cloudron.io/backups/#dry-run

---

@leemuljadi said in Backup Restore Error - route unavailable post activation:

I restore it to the new server and got that "route unavailable post activation"

This can not happen with a fresh setup of Cloudron if you follow the documentation.
Do not use any Cloudron Image from Vultr.
You need to set up a fresh Ubuntu 24 server and Cloudron by hand.

When the Ubuntu 24 setup is done, you install Cloudron with the exact version that your previous server had.

./cloudron-setup --version x.y.z

When the initial set up is done, you visit the new IP Address in the browser.
You start the restore process, and you will have to add all details by hand if you do not have a backup configuration saved from your previous attempts.
Be very certain you use the dry-run option. https://docs.cloudron.io/backups/#dry-run

You can now add your entry to the hosts file. NewIP my.teneight-test.com.
You should now be able to visit my.teneight-test.com in a private browser window, and it should go to your new IP and you should be able to log in into your new Cloudron instance.
You can always confirm that the new IP is used in the browser console network inspector.

[leemuljadi]

@james ok thanks I managed get it work using dry-run. so when should I change the DNS record in the domain registrar if using dry-run?

Previously what I have done:

1. set up a fresh Ubuntu 24 server and Cloudron by hand.
2. visit the new IP Address in the browser.
3. I used the backup config from 20 May 25, but then change the backup directory to the latest backup in 26 May 25 (this is the automatic backup, as I cannot open cloudron dashboard already) not using dry-run.
4. removed the local DNS record in the /etc/hosts file of the deleted VPS
5. changed the IP in the DNS record in the domain registrar to the new VPS IP
   Where did I go wrong?

and there is a folder in my storage bucket for backup named snapshot, what is this for? what is the difference with backup?

[james]

@leemuljadi said in Backup Restore Error - route unavailable post activation:

so when should I change the DNS record in the domain registrar if using dry-run?

When you have checked that all apps are restored successfully, you can make the switch.

@leemuljadi said in Backup Restore Error - route unavailable post activation:

I used the backup config from 20 May 25, but then change the backup directory to the latest backup in 26 May 25 (this is the automatic backup, as I cannot open cloudron dashboard already) not using dry-run.

@leemuljadi said in Backup Restore Error - route unavailable post activation:

Where did I go wrong?

@leemuljadi said in Backup Restore Error - route unavailable post activation:

not using dry-run.

@leemuljadi said in Backup Restore Error - route unavailable post activation:

and there is a folder in my storage bucket for backup named snapshot, what is this for? what is the difference with backup?

All explained in the Cloudron documentation. Please read it yourself.

[leemuljadi]

@james thanks for your help, all good now

[james]

Hello @leemuljadi
I am happy to hear this worked out as intended.
If there is anything we could improve in the documentation please let me know.