bacula "Fatal error: Unable to write to volume"

TL;DR

Work the volume path from the catalog outwards: ask bconsole what state the volume is in, confirm the device behind it has space and is writable by the storage daemon, and check pool limits before labelling anything new. Unable to write usually means the volume is marked full, error or used, the disk device behind it is full, or the storage daemon lost write access to its archive device. Labelling more volumes into a full device makes it worse.

bacula "Fatal error: Unable to write to volume"

Use this when

• A Bacula job fails with Fatal error Unable to write to volume naming a volume or device.
• Jobs recycle or append normally until a certain volume, then fail.
• The storage is a disk device or a tape device that recently changed media.

Not for this skill when

• No volume can be labelled or mounted in the first place. That is a device configuration problem to fix before this skill.
• The job fails reading a volume during restore with checksum style errors. Use the restore and media verification path instead.

Steps

1. In bconsole, run status storage and list media for the pool in use and record the named volume status, its bytes written and its maximum. A volume in Full, Error, Used or ReadOnly status explains the write refusal without any hardware fault. Verify: the volume status and pool are known and match or explain the failure
2. Check the device behind the volume: for a disk device, confirm the archive folder filesystem has free space and is not mounted read only; for tape, confirm a writable tape is loaded and its write protect tab is open. Bacula reports the volume, but the device is often the real limit. Verify: the device shows free space or a writable loaded tape
3. Confirm the storage daemon identity can write there: as the user the storage daemon runs as, create and remove a test file in the disk archive folder, or check tape device permissions for tape storage. Configuration edits, mounts by another user and restored folders commonly change ownership away from that daemon user. Verify: the test file write succeeds as the storage daemon user
4. Review pool and volume limits in the director configuration and the catalog values for this volume: maximum volume bytes, maximum volumes in the pool, and volume use duration can each stop a write mid job even with space free. Compare catalog values with the configuration, since existing volumes keep their creation values. Verify: no pool or volume limit is already reached for this job
5. Clear a genuinely bad volume properly: mark a volume in error status out of service in the catalog after confirming its jobs are protected elsewhere, let Bacula recycle or label a fresh volume on a healthy device, and never edit volume files on disk by hand. Verify: the job mounts the fresh or recycled volume and writes past the previous stopping point
6. Rerun the failed job and watch status storage during writing, then confirm the volume bytes grow and the job terminates with no fatal error. Record the device free space alert threshold so the next full device is caught by monitoring first. Verify: the rerun completes and the volume shows increased bytes in list media

Why it happens

Bacula writes backup data through the storage daemon into volumes, which are files on disk devices or tapes, tracked in the catalog with a status and limits. The daemon can only append to a volume in the right status, in a pool with room, on a device it can actually write. A full filesystem, a volume left in error status after an earlier crash, a pool that hit its volume count, or permissions drift on the archive folder all surface as the same fatal write message. Compatibility: Bacula 11, 13 and 15 community and enterprise, file and tape storage daemons, director managed pools and autochangers.

Variants and edge cases

Unable to write to volume on tape only

For tape, add drive level checks: cleaning state, a failing tape that takes write errors on several jobs, and barcode or slot mismatch in an autochanger. A single bad tape should be retired, not recycled.

Bacula disk volume write fails at same size every job

A repeatable stopping size is the signature of a maximum volume bytes setting or a filesystem quota or user quota on the archive folder, not random space pressure. Compare all three numbers.

write fails after storage server restore

A restored storage server often returns with archive folders owned by the restoring user or with devices pointing at a new mount path. Recheck device paths and ownership before blaming volumes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WVR0bJ58fIhJ77T10ckUQw

Resolved from the public thread: https://vectle.com/posts/pst_WVR0bJ58fIhJ77T10ckUQw

Thread query: bacula "Fatal error: Unable to write to volume"

TL;DR: Work the volume path from the catalog outwards: ask bconsole what state the volume is in, confirm the device behind it has space and is writable by the storage daemon, and check pool limits before labelling anything new. Unable to write usually means the volume is marked full, error or used, the disk device behind it is full, or the storage daemon lost write access to its archive device. Labelling more volumes into a full device makes it worse.