Cloudron Forum

I would say lets close this here. I do not see any failed cleanup jobs even multiple jobs try todo the same.

Restic: https://restic.net Supported repos out of the box: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html Other repos when combining restic with rclone: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#other-services-via-rclone A starting point: https://docs.cloudron.io/guides/community/restic-rclone/

Closing this issue for now. Please report back when Cloudron 9 is released and this is still an issue.

There is currently no generic way to do this from Cloudron side. Depending on your backup storage you are using, you probably can download directly from there.

It looks like the problem is indeed gone with 8.1 Thank you!

I just had the issue while attempting to migrate to a new Cloudron restore, at the step of restoring a full backup and this despite following exactly the steps in Cloudron guide for restoring backups. I quickly solved it through: Reviewing unbound service status shows everything looked ok I had a doubt about the private key password being good, as the backup configuration didn't clarify that in the UI. I just put my private key password again, and attempted the restore button, this time it works. So it's good to mention maybe in the guide that the private key password should be double checked even if using a preexisting backup configuration generated from the previous Cloudron instance.

You should be able to download the whole task logs from the logviewer, which should give you more context which app was currently backed up.

Closed due to inactivity

@cocam123 whoops, you are right! I forgot there is an option in the UI for this The exact checkbox text is Remote file system supports chown

Awesome, I couldn't get NFS to mount, so just set the tarball option instead, thanks.

@daixiwen ah ok. I would ignore the errors. It's normal for upstream services to go down once in a while... I just checked https://status.backblaze.com/ and unfortunately no history of uptime here. But it says "Backblaze performs regular maintenance every Thursday from 11:30 am to 1:30 p.m. Pacific Time with the aim to consistently improve our systems and services. "

Just today I got a notification about an erroneous backup of the server where I have Nextcloud installed (150GB size) and I backup once a week.. I should add that the previous backups were successful. The provider is Backblaze B2. Oct 06 01:02:32 box:storage/s3 Upload progress: {"loaded":1073741824,"part":2,"key":"102/snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7.tar.gz.enc"} Jan 01 01:24:00 node:events:496 [no timestamp] throw er; // Unhandled 'error' event [no timestamp] ^ [no timestamp] [no timestamp] write EPIPE [no timestamp] at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) [no timestamp] 'error' event on TLSSocket instance at: [no timestamp] at emitErrorNT (node:internal/streams/destroy:169:8) [no timestamp] at emitErrorCloseNT (node:internal/streams/destroy:128:3) [no timestamp] at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { [no timestamp] errno: -32, [no timestamp] code: 'EPIPE', [no timestamp] syscall: 'write' [no timestamp] } [no timestamp] [no timestamp] v20.12.2 Oct 06 01:02:32 box:shell backup-snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7: /usr/bin/sudo -S -E --close-from=4 /home/yellowtent/box/src/scripts/backupupload.js snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7 tgz {"localRoot":"/home/yellowtent/appsdata/50d07945-bf1b-4345-8e8c-c146e86c12a7","layout":[]} errored BoxError: backup-snapshot/app_50d07945-bf1b-4345-8e8c-c146e86c12a7 exited with code 1 signal null [no timestamp] at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:122:19) [no timestamp] at ChildProcess.emit (node:events:518:28) [no timestamp] at ChildProcess.emit (node:domain:488:12) [no timestamp] at ChildProcess._handle.onexit (node:internal/child_process:294:12) { [no timestamp] reason: 'Shell Error', [no timestamp] details: {}, [no timestamp] code: 1, [no timestamp] signal: null [no timestamp] } Oct 06 01:02:32 box:taskworker Task took 152.05 seconds Oct 06 01:02:32 box:tasks setCompleted - 2443: {"result":null,"error":{"stack":"BoxError: Backuptask crashed\n at runBackupUpload (/home/yellowtent/box/src/backuptask.js:164:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async uploadAppSnapshot (/home/yellowtent/box/src/backuptask.js:361:5)\n at async backupAppWithTag (/home/yellowtent/box/src/backuptask.js:383:5)\n at async fullBackup (/home/yellowtent/box/src/backuptask.js:504:29)","name":"BoxError","reason":"Internal Error","details":{},"message":"Backuptask crashed"}} Oct 06 01:02:32 box:tasks update 2443: {"percent":100,"result":null,"error":{"stack":"BoxError: Backuptask crashed\n at runBackupUpload (/home/yellowtent/box/src/backuptask.js:164:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async uploadAppSnapshot (/home/yellowtent/box/src/backuptask.js:361:5)\n at async backupAppWithTag (/home/yellowtent/box/src/backuptask.js:383:5)\n at async fullBackup (/home/yellowtent/box/src/backuptask.js:504:29)","name":"BoxError","reason":"Internal Error","details":{},"message":"Backuptask crashed"}} [no timestamp] Backuptask crashed [no timestamp] at runBackupUpload (/home/yellowtent/box/src/backuptask.js:164:15) [no timestamp] at process.processTicksAndRejections (node:internal/process/task_queues:95:5) [no timestamp] at async uploadAppSnapshot (/home/yellowtent/box/src/backuptask.js:361:5) [no timestamp] at async backupAppWithTag (/home/yellowtent/box/src/backuptask.js:383:5) [no timestamp] at async fullBackup (/home/yellowtent/box/src/backuptask.js:504:29) On other servers the backups are successful.

Yeah, I guessed the same after reading the debianforum wiki Results after running it a couple of times: sudo hdparm -t /dev/sdb1 /dev/sdb1: Timing buffered disk reads: 192 MB in 3.00 seconds = 63.92 MB/sec Timing buffered disk reads: 200 MB in 3.00 seconds = 66.58 MB/sec Timing buffered disk reads: 224 MB in 3.01 seconds = 74.44 MB/sec Timing buffered disk reads: 236 MB in 3.01 seconds = 78.31 MB/sec Timing buffered disk reads: 248 MB in 3.01 seconds = 82.33 MB/sec Timing buffered disk reads: 234 MB in 3.01 seconds = 77.69 MB/sec

Switching to hetzner feels good enough for now . Full backup takes 30min for 21 apps. I've cancelled contabo storage service. Hope this stays so snappy for the long run

The multi-part copy was just hanging. If someone hits the same issue, you can just apply this one liner https://git.cloudron.io/platform/box/-/commit/b4d58f0609b1c252fa44799eccbbd9c691c7c2ac . The file is /home/yellowtent/box/src/storage/s3.js

@girish Ok, great! Thank you very much for the information. I really appreciate your time. Thanks again!

Wonderful. Thank you @Joseph, that change to the endpoint URL did the trick. The configuration saved successfully.

@joseph said in Keep Getting Backuptask crashed: If one of you can reach out to support@cloudron.io , maybe we can debug on your server as to what the issue is. Was a solution found, or can this topic be closed for now?

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade: I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out. DNS=8.8.8.8 1.1.1.1 After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon ! In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.