How does storage.backups_volume work?

The documentation implies that I can use a volume in a storage pool as the backup destination [1] [2]

My current setup is a ZFS pool with a dataset created for Incus, during incus admin init, on: shuttle/incus, and /var/lib/incus stored on a dataset on: shuttle/var/lib/incus. As listed in the documentation, I set storage.backups_volume to a custom volume created on the Incus storage pool.

When trying to backup with incus export test, it only outputs the backup artifact in the curent working directory of where I invoked the command, the directory symlinked at /var/lib/incus/backups lists two empty directories: instances and custom

I have attempted to replicate this with a storage pool using the dir driver but the same behaviour is exhibited.

If it is relevant, the system root is a Btrfs partition, and the system is running Fedora 42 Server (I have tested the same with a Debian 12 installation to no avail)

[1] How to manage storage volumes - Incus documentation

[2] API extensions - Incus documentation

EDIT: added another source I used trying to understand the functionality

incus export does:

  • Backup creation
  • Backup download
  • Backup deletion

The backup creation step writes to the storage.backups_volume, the download step downloads to your current directory.

So I assume then that the intended usage of storage.backups_volume is for temporary scratch space to build artifacts on other volumes for more disk constrained Incus instances?

And for systems that uses that backup API to create actual long lived backups.

Because our CLI only uses it for ephemeral backups that are being downloaded doesn’t mean that every API user will use that API in the same way.

1 Like