bacup

5 years after the OVH data center fire, the server backup daemon I wrote in Rust reached version 0.2.0 (now with ZFS snapshot support) Time flies. 6 years ago I wrote this post reddit.com I was impacted by the OVH data center fire and I lost some data of various services I was running on it. Now, I still have fun managing servers, and I have migrated everything to zfs. From that the idea: let's extend bacup to support zfs snapshots, full and incremental. The philosophy of bacup is quite simple: - remotes are where the data is uploaded - services are programs running in the system, that we can invoke to get dumps zfs snapshot fits perfectly in the service category - so I created the zfs service. You can now back up your pools and datasets using both full and incremental strategies. Setting it up is just a matter of defining the zfs service in your configuration: [zfs] snapshot_name = "storage-fs" dataset = "storage" # Optional: schedule for full backups. # Intermediate runs automatically take incremental backups against the latest snapshot. # When omitted, every run defaults to a full backup. full_when = "monthly 1 01:00" And mapping the service to your remote destination: [backup] [backup.storage] what = "zfs.storage" where = "remote.bucket_name" when = "daily 22:00" remote_path = "/bucket/location/zfs/storage/" compress = false keep_last = 32 I’ve been running v0.2.0 in production on my local homelab server for a few weeks now - handling incremental backups for both the root filesystem and the main RAIDZ array (where my local LLMs and Immich instance store data). Incremental shapshot (so 1 full, and several incremental until the next full) also allow to save the cloud bill. If anyone wants to give it a try (cargo install bacup) or review the merged codebase, feedback and PRs are more than welcome! GitHub: galeone/bacup Cheers!

5 years after the OVH data center fire, the server backup daemon I wrote in Rust reached version 0.2.0 (now with ZFS snapshot support) Time flies. 6 years ago I wrote this post reddit.com I was impacted by the OVH data center fire and I lost some data of various services I was running on it. Now, I still have fun managing servers, and I have migrated everything to zfs. From that the idea: let's extend bacup to support zfs snapshots, full and incremental. The philosophy of bacup is quite simple: - remotes are where the data is uploaded - services are programs running in the system, that we can invoke to get dumps zfs snapshot fits perfectly in the service category - so I created the zfs service. You can now back up your pools and datasets using both full and incremental strategies. Setting it up is just a matter of defining the zfs service in your configuration: [zfs] snapshot_name = "storage-fs" dataset = "storage" # Optional: schedule for full backups. # Intermediate runs automatically take incremental backups against the latest snapshot. # When omitted, every run defaults to a full backup. full_when = "monthly 1 01:00" And mapping the service to your remote destination: [backup] [backup.storage] what = "zfs.storage" where = "remote.bucket_name" when = "daily 22:00" remote_path = "/bucket/location/zfs/storage/" compress = false keep_last = 32 I’ve been running v0.2.0 in production on my local homelab server for a few weeks now - handling incremental backups for both the root filesystem and the main RAIDZ array (where my local LLMs and Immich instance store data). Incremental shapshot (so 1 full, and several incremental until the next full) also allow to save the cloud bill. If anyone wants to give it a try (cargo install bacup) or review the merged codebase, feedback and PRs are more than welcome! GitHub: galeone/bacup Cheers!

bacup 0.2.0 is out! 🦀 bacup: an easy-to-use backup tool designed for servers now supports ZFS native snapshots. • Full & incremental dataset/pool backups • Easy TOML config (map service to remote - that's it) cargo install bacup galeone/bacup #Rust #ZFS #DevOps