Barman 2.7 repairs failure handling in PostgreSQL backups

Parallel backup copying needs a reliable way to report that a worker has failed. Barman 2.7 fixes a case where the reporting mechanism itself failed, leaving the backup manager in an internal state that required manual intervention. The distinction matters because a failed copy is an expected operational possibility. Losing the ability to finish handling that failure turns it into a separate administrative problem.

The March 21 announcement describes the consequence directly. An unrecoverable parallel-copy error could require terminating the Barman process with SIGTERM and manually cleaning up the running backup in PostgreSQL. The release fixes that path, along with geographic redundancy and UTF-8 input and output handling.

I regard backup management as part of the database's operational behavior. PostgreSQL's transaction guarantees are valuable, but an external backup program must still handle its own processes and partial work correctly. A maintenance release that reduces ambiguity after a failed backup deserves attention even when it introduces no new backup method.

A worker exception must reach its parent

The versioned Barman changelog identifies the parallel-copy repair as making the CommandMaxRetryExceeded exception serializable. The exception could originate in one of the parallel worker subprocesses. If it could not be serialized, reporting the original error failed.

This explains the relationship between the copy failure and the damaged internal state described in the announcement. A worker and its parent do not share an ordinary in-process exception path. The information describing the failure has to cross the process boundary in a representation that the receiving side can reconstruct.

Retries do not remove that requirement. An exception indicating that retries have been exhausted is particularly important to deliver because the operation has reached the end of its automatic recovery policy. The coordinating process needs that outcome to stop treating the work as an operation that can still complete.

The fix therefore concerns a concrete contract inside the backup tool. A worker can encounter an unrecoverable command failure, and its parent must receive a usable account of that failure. Adding workers improves copying concurrency only if completion and failure both remain observable to the coordinator.

The announcement does not claim that 2.7 makes every copy failure recoverable. Its claim is narrower and more useful. The program can handle this failure without the additional corruption of its internal state that previously forced an administrator to intervene in both Barman and PostgreSQL.

One unreachable server should not stop later maintenance

Geographic redundancy introduces another boundary, this time between Barman installations. The changelog describes the earlier implementation as asynchronous copying over SSH, with support for cascading backups. The primary_ssh_command setting can apply to a whole Barman instance or to an individual server definition.

That scope matters when a scheduled maintenance command handles several servers. Before the 2.7 repair, an unhandled exception while processing one server terminated barman cron. Maintenance operations for subsequent servers did not run. A network failure during synchronization could therefore affect work beyond the server whose connection failed.

The updated behavior logs the exception and continues with the remaining servers. This preserves the failure as an observable event while limiting its effect on unrelated work. The changelog also records a clearer error message for failures to connect to the primary server and avoids propagating the associated synchronization exception unnecessarily.

My preference is for this kind of separation in administrative tools. A server whose backup source is unreachable still needs an error report. Other servers should retain their opportunity to perform maintenance, especially when the command has enough information to keep processing their independent definitions.

The release also changes the first synchronization to ignore history, backup and partial files. The announcement identifies that as a geographic-redundancy fix. It should not be read as general advice to delete those file types from an archive, since the documented change concerns their treatment during the first synchronization.

Error text is part of the execution path

UTF-8 handling can appear peripheral beside backup copying, but failure reporting depends on handling actual command output. The changelog records repairs for non-ASCII error messages and for output containing non-ASCII characters. An administrative program can encounter such text while reporting the result of an external command.

An encoding error during error handling can obscure the condition that the operator needs to understand. This is structurally similar to the worker-exception problem, although the representation boundary differs. Both fixes preserve information about an operation when that information passes through another part of the program.

There is also a backup-validation repair for PostgreSQL versions older than 9.2. The changelog includes it among the changes prepared for 2.7. That gives operators of older installations another reason to distinguish the release's actual fixes from its short announcement, whose main emphasis is parallel copying and geographic redundancy.

Barman manages remote backups for multiple PostgreSQL servers and assists with recovery. Its scope therefore includes state outside the database process, including worker subprocesses and connections to other backup installations. Version 2.7 repairs how failures move through those components. The release announcement recommends upgrading at the earliest opportunity and specifies a simple package upgrade, with the parallel-copy fix removing a documented need for manual process termination and database backup cleanup.