No description
Find a file
2025-04-20 14:50:52 -05:00
.github Create FUNDING.yml 2024-02-07 01:05:46 -05:00
.vscode Initial commit. 2021-04-15 21:12:08 -05:00
docs Rename file. 2024-02-07 01:01:05 -05:00
examples Update config templates. 2024-02-07 00:03:29 -05:00
src Clippy fixes 2025-04-20 14:50:52 -05:00
.gitignore Initial commit. 2021-04-15 21:12:08 -05:00
.rustfmt.toml Add rustfmt 2024-02-05 11:47:43 -05:00
builder.sh Update builder.sh 2022-03-11 15:32:33 -05:00
Cargo.lock Add support for using a hostname identifier 2024-02-07 00:01:10 -05:00
Cargo.toml Add support for using a hostname identifier 2024-02-07 00:01:10 -05:00
README.md Update documentation. 2024-02-07 00:04:37 -05:00

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 kind identifier 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).
  • Ability to specify the maximum number of snapshots to keep for automatic cleanup.
  • Supports restoration of snapshots in the original directory or a specific one.
  • Supports machine name identification for better tracking when using the same database in multiple machines.
  • 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.

Screenshots

List snapshots

2021-04-23_11-11

Create and restore snapshot

2021-04-23_11-15

Delete snapshot

2021-04-23_11-17