Restoring Link to this section

borg list /path/to/repo
borg list /path/to/repo::daily-2026-01-21 home/daniel
borg extract /path/to/repo::daily-2026-01-21 home/daniel/Documents

extract writes into the current directory and recreates the stored path — from /tmp/restore you get /tmp/restore/home/daniel/Documents, not an overwritten live tree. Listing a subpath confirms the path.

Finding a file Link to this section

borg list /path/to/repo::archive-name | grep savegame
borg list /path/to/repo::archive-name --pattern '**/*filename*'

Across every archive, slow on a large repo but thorough:

for a in $(borg list /path/to/repo); do
  echo "== $a =="
  borg list /path/to/repo::$a | grep filename
done

Borg has no queryable index: searches read archive listings, so --pattern beats piping through grep.

After a partial deletion Link to this section

An archive was deleted (borg delete repo::archive): only metadata goes; chunks survive if another archive references them. No undelete command, and the rest stay restorable.

Chunks were deleted — files removed from repo/data, or repository corruption. Whatever chunk is gone, the file needing it is gone. What helps:

borg check --repair /path/to/repo
borg mount /path/to/repo /mnt/borg

--repair reconstructs missing index files and salvages orphaned chunks, not conjure deleted ones; mounting extracts what is accessible. Carving raw chunk files needs external tooling, incomplete by nature.

Recovery is bounded by surviving chunks: an offsite copy is the only real answer, and prune deserves delete’s care.

Errno 5 during a manifest write Link to this section

File ".../borg/repository.py", line 1467, in get_write_fd
    self.close_segment()
...
OSError: [Errno 5] Input/output error

The traceback ends in fdatasync on a segment file during the manifest write — storage failing, not Borg: failing disk, full filesystem, vanished network mount, unreliable destination. Check its filesystem and write path (/mnt/server/... hints the mount); borg check shows whether the repository survived the truncation.

Silent early exits Link to this section

Borg killed leaves no error of its own; exit status and system log are the evidence:

  • OOM killer. dmesg | grep -i kill, and watch memory during the run — many small files are memory-hungry.
  • Timeout. A systemd service with TimeoutSec=, or a cron wrapper, stops it: systemctl cat borg-backup.service.
  • Disk full or quota. df -h, quota, borg create --progress to see where it stops.
  • Bad exclude files. An empty or malformed --exclude-from / --patterns-from leaves nothing to back up, so it finishes quickly and cleanly.
borg create -v --list ...

Verbose output separates “ran and found nothing” from “was stopped part way” better than the exit code.