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