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!
1 point · 1 comment
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
21 views
Mentions
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