borgbackup / borgbackup/borg

Make it easier to figure out why borg terminated with warning status

Open
#8,954 5 comments 5 reactions 0 assignees View on GitHub
question
Dominant language
Python
Stars
13.7k
Forks
875
Avg merge
11h 15m
Merged PRs (30d)
192

Description

## User story

I have used the script from [this section](https://borgbackup.readthedocs.io/en/stable/quickstart.html#automating-backups) of the documentation to create a backup.

At the end, I got an information that

```
terminating with warning status, rc 1
```

Unfortunately borg included no information about what the warnings were next to this line of output.

So I opened the log file and searched for "warning". then "Warning". Both only turned up files that happened to have that in the filename, because the logs include every file that is getting inserted into the backups.

So I searched the documentation for "warning" and got a bunch of irrelevant results. Somehow, I ended up finding the "Return codes" section of the documentation, and found this description for return code 1:

> generic warning (operation reached its normal end, but there were warnings -- you should check the log, logged as WARNING)

So I grepped my logs for `WARNING`, and once again found only mentions of files that have WARNING in their filename.

In a fit of desperation, I typed

```
$ rg -v '^[AM] ' ~/backup.log
```

and this made it possible for me to find out that

```
/home/mei/backup.log: file changed while we backed it up
```

## Suggested resolution

There are many things which would have made this a much less infuriating experience. The following come to mind:

- together with the summary about the size of the archive, time taken and so on, include aggregate statistics on what warnings occurred, e.g.

terminating with warning status, rc 1:
2 files changed while we backed them up

- make sure to include the severity of the log message in each line of output
- some kind of facility to put only the more important information in the log files, while having the "current status" type of information go to the terminal only (though this could probably also be built on top of borg within a shell script given a well-defined log output format)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.