NextCloud AIO borgbackup - daily backup

ℹ️ Support
1

Hi,
I installed NextCloud AIO successfully and everything is working fine, including starting the (borg)backup by manually pushing the button “create backup” at the interface or via the “docker exec …” command starting the daily-backup.sh of the master container.

But if I try to use the automatic, daily backup option and configure to start the daily backup at e.g. 04:00 in the night, then simply nothing happens!

How can I analyse what’s going wrong or how is that daily backup typically scheduled?

2

Hi, can you change that setting to a time in ca. 5min and check if it works? (You dont need to wait for 04:00 each time…) also the mastercontainer logs would be really helpful for debugging after testing that.

3

Btw, the chosen time will be in UTC so e.g. 15:11 should be in 5min.

4

strange - this backup (15:15 UTC) worked fine!
The time can be found inside the file daily_backup_time after configuring it via the interface, but I’m pretty sure, that also 04:00 was mentioned there in the past.

Which log file and where to find it will help to analyse the problem?
And what mechanism is used to start the borg Backup? (cron, but in which container/user and can I check via crontab?)

Anyway: Many thanks for your quick answer!

5

ok, seems there is a process running forever (bash cron.sh) waiting for changed on this file

if [ -f “/mnt/docker-aio-config/data/daily_backup_time” ]; then

If the file daily_backup_time does not exist, is does this:
export BACKUP_TIME=“04:00”
export DAILY_BACKUP=0
export LOCK_FILE_PRESENT=0

Most likely the file was then not there and therefore the daily backup switched of?

I set again 04:00, see the file existing there and I think it’s worth to check, if it now runs as expected on 04:00 UTC…

6

You can check the mastercontainer logs with sudo docker logs nextcloud-aio-mastercontainer

1 Like
7

Hmm, still no luck this night at 04:00. But it seems the backup was started - but then unfortunately failed.

The logs of the above command show this:

[Sat Jan 21 16:38:38.973430 2023] [core:notice] [pid 89] AH00094: Command line: 'apache2 -D FOREGROUND'
Deleting duplicate sessions
Daily backup script has started
Starting mastercontainer update...
(The script might get exited due to that. In order to update all the other containers correctly, you need to run this script with the same settings a second time.)
Waiting for watchtower to stop
Creating daily backup...
Starting and updating containers...
Waiting for the Nextcloud container to start
Sending backup notification...
Daily backup script has finished
Total reclaimed space: 0B
++ head -1 /mnt/docker-aio-config/data/daily_backup_time
+ BACKUP_TIME=04:00
+ export BACKUP_TIME
+ export DAILY_BACKUP=1
+ DAILY_BACKUP=1
++ sed -n 2p /mnt/docker-aio-config/data/daily_backup_time
+ '[' '' '!=' automaticUpdatesAreNotEnabled ']'
+ export AUTOMATIC_UPDATES=1
+ AUTOMATIC_UPDATES=1
+ set +x
Deleting duplicate sessions

and this time borg backup created this error log:

Performing backup...
Starting the backup...
Failed to create/acquire the lock /mnt/borgbackup/borg/lock (timeout).
Deleting the failed backup archive...
Failed to create/acquire the lock /mnt/borgbackup/borg/lock (timeout).
Backup failed!

Inside the backup data directory itself I can find this file:

-rw------- 1 root root      57 22. Jan 05:01 lock.roster

Any hints much appreciated :slight_smile:

8

Hm… That is strange. Can you try to remove the lock by running borg break-lock on the host or just removing the lock.roaster?

2 Likes
9

Thanks for your help! borg break-lock removed the lock-file!
Then tried a scheduled backup again on 14:08 UTC and this one succeeded, but mentioned, that the containers got an update (I was carefully watching the status during the backup).
Finally the logs show a successful backup and this time no lock file remains.

Maybe I saw a side effect of what is described here regarding the automatic update?

Entered now again 04:00 UTC for the next backup and will check what the results are tomorrow :slight_smile:

10

The mastercontainer should handle this correctly for you so you should not run into a problem with the backup. It is only important to know if you schedule backups externally using this endpoint.

11

Success! :slight_smile:
Backup executed on 04:00 UTC. Seems to work fine now. Many thanks for your continuous support, @szaimen ! :smiley:

1 Like
12

Thanks, @szaimen and @Struppie , I was getting the same error log. Your discussion pointed me to the solution. Backups running again!

1 Like