Backup failing systematically

AmbroiseUnly

Backup failed 02/14/2024

Backup failed: Task 291 timed out.

2024-02-13T22:00:01.479Z box:taskworker Starting task 291. Logs are at /home/yellowtent/platformdata/logs/tasks/291.log
2024-02-13T22:00:01.528Z box:tasks update 291: {"percent":1,"message":"Backing up n8n.unly.org (1/6)"}
2024-02-13T22:00:01.558Z box:tasks update 291: {"percent":12.11111111111111,"message":"Snapshotting app n8n.unly.org"}
2024-02-13T22:00:01.597Z box:services Backing up postgresql
2024-02-13T22:00:01.597Z box:services backupAddons
2024-02-13T22:00:01.597Z box:services backupAddons: backing up ["localstorage","postgresql","sendmail"]
2024-02-13T22:00:03.152Z box:services pipeRequestToFile: connected with status code 200
2024-02-13T22:00:06.134Z box:backuptask snapshotApp: n8n.unly.org took 4.576 seconds
2024-02-13T22:00:06.134Z box:tasks update 291: {"percent":12.11111111111111,"message":"Uploading app snapshot n8n.unly.org"}
2024-02-13T22:00:06.136Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 spawn: /usr/bin/sudo -S -E --close-from=4 /home/yellowtent/box/src/scripts/backupupload.js snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 tgz {"localRoot":"/home/yellowtent/appsdata/264f46f6-7faf-4e0e-b923-f4fcde1b8d86","layout":[]}
2024-02-13T22:00:06.156Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): sudo: unable to resolve host cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01: Name or service not known
2024-02-13T22:00:07.070Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): 2024-02-13T22:00:07.068Z box:backupupload Backing up {"localRoot":"/home/yellowtent/appsdata/264f46f6-7faf-4e0e-b923-f4fcde1b8d86","layout":[]} to snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86
2024-02-13T22:00:07.135Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): 2024-02-13T22:00:07.134Z box:backuptask upload: path snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 format tgz dataLayout {"localRoot":"/home/yellowtent/appsdata/264f46f6-7faf-4e0e-b923-f4fcde1b8d86","layout":[]}
2024-02-13T22:00:07.407Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): 2024-02-13T22:00:07.407Z box:backuptask upload: mount point status is {"state":"active"}
2024-02-13T22:00:07.408Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): 2024-02-13T22:00:07.407Z box:backuptask checkPreconditions: getting disk usage of /home/yellowtent/appsdata/264f46f6-7faf-4e0e-b923-f4fcde1b8d86
2024-02-13T22:00:07.443Z box:backupformat/tgz upload: Uploading {"localRoot":"/home/yellowtent/appsdata/264f46f6-7faf-4e0e-b923-f4fcde1b8d86","layout":[]} to snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86
2024-02-13T22:00:07.444Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): 2024-02-13T22:00:07.443Z box:backuptask checkPreconditions: total required=299380279 available=undefined
2024-02-13T22:00:17.495Z box:tasks update 291: {"percent":12.11111111111111,"message":"Uploading backup 29M@3MBps (n8n.unly.org)"}
2024-02-13T22:00:27.498Z box:tasks update 291: {"percent":12.11111111111111,"message":"Uploading backup 30M@0MBps (n8n.unly.org)"}

...

2024-02-14T21:59:53.231Z box:tasks update 291: {"percent":12.11111111111111,"message":"Uploading backup 30M@0MBps (n8n.unly.org)"}

I guess 2024-02-13T22:00:06.156Z box:shell backup-snapshot/app_264f46f6-7faf-4e0e-b923-f4fcde1b8d86 (stderr): sudo: unable to resolve host cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01: Name or service not known might be the issue?

I'm not sure if I misconfigured something.

I did rename the Droplet instance in DigitalOcean, I didn't expect it to break the backups, though. (formerly cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01)

murgero

Can you post the contents of your hosts /etc/hosts file and if it's available the /etc/resolv.conf file as well (please read through both files for personal information first!)

AmbroiseUnly

Here is /etc/hosts:

root@cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01:~# cat /etc/hosts
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
#     /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 cloudron762onubuntu2204-s-1vcpu-2gb-70gb-intel-fra1-01 cloudron762onubuntu2204-s-1vcpu-2gb-70gb-intel-fra1-01
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

And /etc/resolv.conf:

root@cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.1

I got those from my DigitalOcean Droplet, by connecting to it directly, not using a Cloudron feature. Wasn't sure how to access those files.

I guess the issue is that the hostname doesn't match the server name. I'm not sure why. I did rename the DigitalOcean droplet (current name is cloudron-ubuntu2204-4vcpu-8gb-70gb-intel-fra1 on the UI), but I don't see how that should affect the "internal name of the instance" (cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01 not sure how to describe that)

cloudron762onubuntu2204-s-1vcpu-4gb-70gb-intel-fra1-01 (4gb
cloudron762onubuntu2204-s-1vcpu-2gb-70gb-intel-fra1-01 (2gb)

AmbroiseUnly

I restarted the DigitalOcean droplet and the name changed again to cloudron-ubuntu2204-4vcpu-8gb-70gb-intel-fra1

root@cloudron-ubuntu2204-4vcpu-8gb-70gb-intel-fra1:~# pwd
/root
root@cloudron-ubuntu2204-4vcpu-8gb-70gb-intel-fra1:~#

So, I guess renaming the instance in the UI does affect the server internal name, but only after a reboot of the Droplet itself.

nebulon

The hostname error is not the issue of the failing backup. Was that failure just a one-time failure or is it reproducible?

To set the hostname correctly, use the dashboard domain (my.domain.com) in the DigitalOcean interface to fix this warning.

girish

The warning is just sudo being sudo. See https://askubuntu.com/questions/59458/error-message-sudo-unable-to-resolve-host-none for a fix.

AmbroiseUnly

@nebulon said in Backup failing systematically:

The hostname error is not the issue of the failing backup. Was that failure just a one-time failure or is it reproducible?

It happens frequently, I'm not sure if it works sometimes or fail all the time.

I don't know if the backups listed above mean they succeeded, or not.
I guess some of them do work?

Here is what I have in AWS S3

Not sure how to tell if those backups might be corrupted, though.

girish

@AmbroiseUnly said in Backup failing systematically:

I don't know if the backups listed above mean they succeeded, or not.

Only the successful ones are listed. So, it looks like your backups are OK since they are just failing not too often.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

Backup failing systematically