| .github/workflows | ||
| .vscode | ||
| docs | ||
| examples | ||
| src | ||
| .gitignore | ||
| .rustfmt.toml | ||
| builder.sh | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
Description
Simple and handy btrfs snapshoting tool. Supports unattended snapshots, tracking, restoring, automatic cleanup and more. Backed with SQLite.
Documentation
See the docs folder.
Features
- Allows you to specify the origin and destination of snapshots at will of the user.
- Track snapshots using SQLite as backend database.
- Easy setup using small templates instead of confusing long files.
- Ability to create snapshots of the volumes you want simply by using different configuration templates.
- Ability to create read-only or read-write snapshots.
- Ability to use the same SQLite database for everything.
- Ability to specify the prefix of the name for the snapshots for better identification.
- Ability to specify a
kindidentifier to differentiate them in the database. Useful if you plan to have hourly, weekly, monthly or more "kind" of snapshots of the same subvolume(s). - Supports restoration of snapshots in the original directory or a specific one.
- Automatic snapshots cleanup.
- Nice CLI output to see the status and details of snapshots.
Known limitations
Due to SQLite limitations to handle concurrent database operations, we need to make use of SQLite's busy_timeout, which was initially implemented in ce44bf6. Without it you will get the error: Error: database is locked (code 5) if you try to make concurrent snapshots exactly at the same time. The default timeout is 5 seconds which is more than enough time so that no problem occurs even in the most demanding scenarios.
In summary, busy_timeout is the maximum time that SQLite will retry the failed transaction. Considering that Rusnapshot's database operations are small and shouldn't take long, 5 seconds is a decent time. If you continue to get the mentioned error, try increasing --timeout, remember that the value must be in milliseconds.


