For Backy² Users

There is no direct migration path from backy² to Benji. If you want to migrate to Benji you’d have to start with a new installation.

The concepts and most of the command names and options stayed the same so Benji should feel familiar to backy² users. If you currently have any scripts deployed together with backy² they should require only a few changes to work with Benji. But if your scripts check for specific exit codes from backy² you’d have to adapt those because they have all changed with Benji. Also if you used backy²’s machine readable output, there’d be changes required as Benji uses JSON instead of CSV.

Here’s a list of the new features that differentiate Benji from backy²:

  • Encryption support (AES-256, GCM mode)

  • Compression support (zstandard)

  • Automatic metadata export to data backend for backup purposes

  • Support for Backblaze’s B2 Cloud Storage as a storage backend

  • Support for multiple storage backends

  • Variable block size for efficient support of LVM and Ceph in one installation of Benji

  • More compact metadata storage, the database backend now uses significantly less disk space

  • Database based locking to make it possible to have multiple instances on different hosts or in different containers

  • New scrubbing mode based on metadata, object existence and length

  • Randomly sampled batch scrubbing of versions

  • Simple yet flexible retention policy enforcement

  • Migration from boto to boto3 with better compatibility for other S3 implementations (Google Storage for example)

  • Kubernetes integration with a Helm chart

  • blake2b with 32 byte digest as default hash function

  • Optional read caching of blocks

  • Configuration file format changed to YAML

  • Machine readable output is JSON instead of CSV

  • More commands support machine readable output

  • Import/export format is JSON instead of CSV

  • Replacement of the original tags with labels (key-value pairs)

  • Flexible filter specification for listings, scrubs and other operations

There also have been quite a few changes under the hood:

  • Migration from classic threads and queues to concurrent.futures

  • Use Ceph provided Python bindings

  • Some refactoring and rewriting to share more code

  • Update to database transaction handling

  • Update to exit code handling, exit codes have changed

  • SQLAlchemy based database backend is the only supported backend now

  • Configuration file validation