Running into issues restoring an app from old Cloudron instance to new Cloudron instance
-
Hello,
I am running 4.2.6, and I have tried to migrate to a new provider. So I followed the documentation and restored everything to the new server in the new providers data centre. It works, however two apps fail to restore and that's maybe expected because it seems to do a DNS check (even though it's set to manual for these two domains) and the DNS is handled by another person so I can't make the change myself. So in other words, at this point, I had all my apps running fine, but two were in error state and due to the DNS not pointing to the new IP address.
I asked one of the providers to switch the IP for me, and once it did the app was still in error state so I hit the Repair option as it was basically the only option, and it would then move past the DNS error but then return a "Backup not found" error. This doesn't make sense, it was part of the same backup every other app came from. These two apps are automatically backed up.
Just trying to determine why this might happen. Trying to figure this out before migrating the last one over so I don't have to rebuild the whole thing manually as I ended up having to do with the first one today since I needed them up and running quickly.
First backup / restore experience, and generally went well with one exception (for two apps). I'm assuming the same thing will happen with the remaining one, though maybe it'll be fine after I hit repair, but worried about it not finding the backup again. The backup was just created yesterday, it still exists, it is unclear why it doesn't have it.
-
@d19dotca For the apps that are failing to restore, switch the DNS of the domains to no-op. Doing that will completely disable any DNS checks (as opposed to manual, which still tries to verify that the DNS is in sync). But I see that this tip is not useful anymore because you managed to get past this step.
When you migrated, did you change the prefix or bucket name or something else by any chance? Can you confirm that the backup itself exists in your backup provider (you can get the backup id by clicking the 'copy backup' icon in the left of the backup name in the UI)?
-
@d19dotca For the apps that are failing to restore, switch the DNS of the domains to no-op. Doing that will completely disable any DNS checks (as opposed to manual, which still tries to verify that the DNS is in sync). But I see that this tip is not useful anymore because you managed to get past this step.
When you migrated, did you change the prefix or bucket name or something else by any chance? Can you confirm that the backup itself exists in your backup provider (you can get the backup id by clicking the 'copy backup' icon in the left of the backup name in the UI)?
@girish Ah okay, I see. Out of curiosity, why does it do it when it's set to manual? I would expect it to restore the files and operate regardless of DNS resolution, particularly in the case where the domain DNS is set to "manual". Is there a reason it behaves the way it does right now? I don't quite understand why it would care about the DNS state for the app when I asked it to restore itself.
By the way, in case it matters, the process I followed was in your documentation for migrating the entire server (in my case from DigitalOcean to OVH), not just a single app. And everything worked perfectly except for the two apps that are associated with the domain DNS setup of "manual".
I have one app remaining that needs to have the external DNS entries updated to the new server IP. I'm afraid of running into the same problem as before. I have a workaround but ideally I'd like to try and figure out why this happened, if possible. Would you suggest that I change the remaining one to "no-op" as you suggested? In that case, do you think that once the DNS is updated that I can then run the repair and it should succeed? I guess if it doesn't, I can try to get the extra logs like you suggested which may help too. This is more a learning experience than anything, so just trying to get the process nailed down.
-
@d19dotca For the apps that are failing to restore, switch the DNS of the domains to no-op. Doing that will completely disable any DNS checks (as opposed to manual, which still tries to verify that the DNS is in sync). But I see that this tip is not useful anymore because you managed to get past this step.
When you migrated, did you change the prefix or bucket name or something else by any chance? Can you confirm that the backup itself exists in your backup provider (you can get the backup id by clicking the 'copy backup' icon in the left of the backup name in the UI)?
@girish I went ahead and changed the domain DNS to "no-op" and repaired it. It moved past the DNS thing but I ran into the same error as before. Here is the logs if it helps. I noticed the dates all seem random, unsure why that is but assuming it isn't related.
How can I get past this? Is there a way to pick a different backup? It seems I can't from the UI at this time, can only use CLI but I didn't have the best luck with that when I tested it earlier today for the first incident.
Jan 01 00:00:00 'Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc' }
Oct 17 03:38:43 box:backups tarExtract: input stream error. { BackupsError: Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc
Jan 01 00:00:00 at S3ReadStream.<anonymous> (/home/yellowtent/box/src/storage/s3.js:134:34)
Jan 01 00:00:00 at S3ReadStream.emit (events.js:189:13)
Jan 01 00:00:00 at S3ReadStream.EventEmitter.emit (domain.js:441:20)
Jan 01 00:00:00 at process.nextTick (/home/yellowtent/box/node_modules/s3-block-read-stream/lib/readstream.js:49:37)
Jan 01 00:00:00 at process._tickCallback (internal/process/next_tick.js:61:11)
Jan 01 00:00:00 name: 'BackupsError',
Jan 01 00:00:00 reason: 'not found',
Jan 01 00:00:00 message:
Jan 01 00:00:00 'Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc' }
Oct 17 03:39:03 box:backups tarExtract: input stream error. { BackupsError: Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc
Jan 01 00:00:00 at S3ReadStream.<anonymous> (/home/yellowtent/box/src/storage/s3.js:134:34)
Jan 01 00:00:00 at S3ReadStream.emit (events.js:189:13)
Jan 01 00:00:00 at S3ReadStream.EventEmitter.emit (domain.js:441:20)
Jan 01 00:00:00 at process.nextTick (/home/yellowtent/box/node_modules/s3-block-read-stream/lib/readstream.js:49:37)
Jan 01 00:00:00 at process._tickCallback (internal/process/next_tick.js:61:11)
Jan 01 00:00:00 name: 'BackupsError',
Jan 01 00:00:00 reason: 'not found',
Jan 01 00:00:00 message:
Jan 01 00:00:00 'Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc' }
Oct 17 03:39:03 box:backups restoreApp: time: 82.216
Oct 17 03:39:03 box:apptask www.<domain-replaced> error installing app: BackupsError: Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc
Oct 17 03:39:03 box:apptask www.<domain-replaced> updating app with values: {"installationState":"error","error":{"message":"Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc","reason":"Unknown Error","taskId":"1032","installationState":"pending_restore"}}
Oct 17 03:39:03 box:tasks setCompleted - 1032: {"result":null,"error":{"stack":"BackupsError: Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc\n at PassThrough.<anonymous> (/home/yellowtent/box/src/backups.js:508:19)\n at PassThrough.emit (events.js:194:15)\n at PassThrough.EventEmitter.emit (domain.js:441:20)\n at S3ReadStream.<anonymous> (/home/yellowtent/box/src/storage/s3.js:134:20)\n at S3ReadStream.emit (events.js:189:13)\n at S3ReadStream.EventEmitter.emit (domain.js:441:20)\n at process.nextTick (/home/yellowtent/box/node_modules/s3-block-read-stream/lib/readstream.js:49:37)\n at process._tickCallback (internal/process/next_tick.js:61:11)","name":"BackupsError","reason":"external error","message":"Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc"}}
Oct 17 03:39:03 box:tasks 1032: {"percent":100,"result":null,"error":{"stack":"BackupsError: Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc\n at PassThrough.<anonymous> (/home/yellowtent/box/src/backups.js:508:19)\n at PassThrough.emit (events.js:194:15)\n at PassThrough.EventEmitter.emit (domain.js:441:20)\n at S3ReadStream.<anonymous> (/home/yellowtent/box/src/storage/s3.js:134:20)\n at S3ReadStream.emit (events.js:189:13)\n at S3ReadStream.EventEmitter.emit (domain.js:441:20)\n at process.nextTick (/home/yellowtent/box/node_modules/s3-block-read-stream/lib/readstream.js:49:37)\n at process._tickCallback (internal/process/next_tick.js:61:11)","name":"BackupsError","reason":"external error","message":"Backup not found: 2019-10-15-010001-045/app_b858c18c-0e10-464a-b83b-0e6c2abb2b74_2019-10-15-012040-165_v2.6.4.tar.gz.enc"}} -
@d19dotca For the apps that are failing to restore, switch the DNS of the domains to no-op. Doing that will completely disable any DNS checks (as opposed to manual, which still tries to verify that the DNS is in sync). But I see that this tip is not useful anymore because you managed to get past this step.
When you migrated, did you change the prefix or bucket name or something else by any chance? Can you confirm that the backup itself exists in your backup provider (you can get the backup id by clicking the 'copy backup' icon in the left of the backup name in the UI)?
@girish So I found out how to restore from a backup using the CLI and that worked for me for the second app. It's still weird to me that it went to "Backup not found" when all other backups were fine and it was done by the one action on restoring the entire server. It makes me think there's a defect there somewhere, but it may be difficult to reproduce.
