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