Closed gustabowill closed 2 months ago
I rebased this on top of master
to get rid of that black: format
commit, which was already handled before.
Note: I though about using debug or warning log level, but considering that, as I've seen, there's a change of this happening also during a backup, I think it's better to display it with an error level instead. Also, if by any chance the user runs this manually they should be able to see the failure reason immediately on the screen I think.
That makes sense!
After all, backup_info.error
field is filled with that information for later showing through barman show-backup
command.
This looks good. A test showing the functionality:
$ barman list-backup all
pg17 20240726T210201 - Fri Jul 26 19:02:02 2024 - Size: 35.4 MiB - WAL Size: 0 B - WAITING_FOR_WALS
pg17 20240726T210125 - Fri Jul 26 19:01:28 2024 - Size: 251.3 MiB - WAL Size: 32.0 MiB - WAITING_FOR_WALS
$ barman show-backup pg17 20240726T210125 | grep WAL
Status : WAITING_FOR_WALS
Disk usage : 219.3 MiB (251.3 MiB with WALs)
Begin WAL : 0000000100000005000000F1
End WAL : 0000000100000005000000F2
WAL number : 2
WAL information:
WAL rate : 303.79/hour
$ rm ~/barman_home/pg17/wals/0000000100000005/0000000100000005000000F1
$ barman check-backup pg17 20240726T210125
ERROR: This backup has been marked as FAILED due to the following reason: At least one WAL file is missing. The first missing WAL file is 0000000100000005000000F1
2024-07-26 21:03:59,624 [27471] barman.backup ERROR: This backup has been marked as FAILED due to the following reason: At least one WAL file is missing. The first missing WAL file is 0000000100000005000000F1
barman show-backup
command:$ barman show-backup pg17 20240726T210125
Backup 20240726T210125:
Server Name : pg17
System Id : 7382227563826631291
Status : FAILED
Error : At least one WAL file is missing. The first missing WAL file is 0000000100000005000000F1
The
check-backup
command can mark a backup as failed if it notices that some of its required WAL files are missing. This works correctly, however no output is provided, so the only way to check why the backup has been marked as failed is by executing ashow-backup
on the backup. This commit fixes this issue by outputting the reason as an error message in the CLI.Note: I though about using debug or warning log level, but considering that, as I've seen, there's a change of this happening also during a backup, I think it's better to display it with an error level instead. Also, if by any chance the user runs this manually they should be able to see the failure reason immediately on the screen I think.
References: BAR-213