zfsnapr
borgmatic
Our great sponsors
zfsnapr | borgmatic | |
---|---|---|
7 | 61 | |
21 | 1,639 | |
- | 3.0% | |
5.6 | 9.5 | |
8 months ago | 7 days ago | |
Ruby | Python | |
BSD 2-clause "Simplified" License | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
zfsnapr
-
Kopia: Open-Source, Fast and Secure Open-Source Backup Software
FreeBSD had a pretty decent option in the base system two decades ago - FFS snapshots and a stock backup tool that would use them automatically with minimal effort, dump(8). Just chuck `-L` at it and your backups are consistent.
Now of course it's all about ZFS, so there's at least snapshots paired with replication - but the story for anything else is still pretty bad, with you having to put all the fiddly pieces together. I'm sure some people taught their backup tool about their special named backup snapshots sprinkled about in `.zfs/snapshot` directories, but given the fiddly nature of it I'm also sure most people just ended up YOLOing raw directories, temporal-smearing be damned.
I know I did!
I finally got around to fixing that last year with zfsnapr[1]. `zfsnapr mount /mnt/backup` and there's a snapshot of the system - all datasets, mounted recursively - ready for whatever backup tool of the year is.
I'm kind of disappointed in mentioning it over on the Practical ZFS forum that the response was not "why didn't you just use ", but "I can see why that might be useful".
Well, yes, it makes backups actually work.
> Also, it's unclear to me what happens if you attempt a snapshot in the middle of something like a database transaction or even a basic file write. Seems likely that the snapshot would still be corrupted
A snapshot is a point-in-time image of the filesystem at a given point. Any ACID database worth the name will roll back the in-flight transaction just like they would if you issued it a `kill -9`.
For other file writes, that's really down to whether or not such interruptions were considered by the writer. You may well have half-written files in your snapshot, with the file contents as they were in between two write() calls. Ideally this will only be in the form of temporary files, prior to their rename() over the data they're replacing.
For everything else - well, you have more than one snapshot backed up, right?
1: https://github.com/Freaky/zfsnapr
-
ZFS for Dummies
I make remote snapshot backups with Borg using this: https://github.com/Freaky/zfsnapr
zfsnapr mounts recursive snapshots on a target directory so you can just point whatever backup tool you like at a normal directory tree.
I still use send/recv for local backups - I think it's good to have a mix of strategies.
-
BorgBackup, Deduplicating archiver with compression and encryption
This is why I made https://github.com/Freaky/zfsnapr
Instead of working out how to teach my backup tools about snapshots, I just mount them in a subtree and use that as a chroot env.
-
Ask HN: Can I see your scripts?
borg-backup.sh, which runs my remote borg backups off a cronjob: https://github.com/Freaky/borg-backup.sh
zfsnapr, a ZFS recursive snapshot mounter - I run borg-backup.sh using this to make consistent backups: https://github.com/Freaky/zfsnapr
mkjail, an automatic minimal FreeBSD chroot environment builder: https://github.com/Freaky/mkjail
run-one, a clone of the Ubuntu scripts of the same name, which provides a slightly friendlier alternative to running commands with flock/lockf: https://github.com/Freaky/run-one
-
Correct Backups Require Filesystem Snapshots
I wrote https://github.com/Freaky/zfsnapr a few months ago so I could finally have point-in-time consistent Borg backups with ZFS snapshots, without having the mess of teaching Borg where every .zfs directory was.
It recursively snapshots mounted pools, and recursively mounts snapshots of the mounted datasets into a target ready to point your backup tools at. I do so via a chroot so I didn't need to make any changes to my Borg setup - just to how I run it.
-
Snapshot stat changes on access
This is the approach I take with zfssnapr - make a recursive snapshot of pools and then use mountpoint/canmount to recursively mount datasets on a location. Then I can just point borg at it without having to teach it where exactly each .zfs directory is.
- zfsnapr — recursively mount a system snapshot on a given location
borgmatic
-
Rclone syncs your files to cloud storage
- for important files, a separate box where I have borgmatic [1] in deduplication mode installed; this is updated once in a while
Just curious: Do you have any reason to believe that such a data corruption bug is likely in ZFS? It seems like saying that ext4 could have a bug and you should also store stuff on NTFS, just in case (which I think does not make sense..).
[1]: https://github.com/borgmatic-collective/borgmatic
- Duplicity
-
Kopia: Open-Source, Fast and Secure Open-Source Backup Software
Not really dumb. I do use them too but with Borgbackup on the top (since they support it natively).
I found Borgmatic ( https://torsion.org/borgmatic/ ) to be the best way to run my backups. It takes care of everything from pruning to verifying the checksum etc... and it integrates with some monitoring (like cronitor).
So Borgmatic + rsync.net is the best combo
- Ask HN: How do you do backups for personal/home server?
-
KBackup vs rsync?
For backups I use Borg myself. If you need a GUI, you can use Vorta or Pika. With borgmatic, there is also a wrapper that extends the range of functions of Borg.
- How do you deal with backups outside the cloud?
-
Suggestions for Incremental Backup Software
Furthermore, Borgmatic is a wrapper for Borg that extends or improves the range of functions.
-
BorgBackup 1.2.4 released
For those of you not familiar, borgmatic is a very convenient tool which runs as a wrapper around borg.
-
Server lost power, world not loading correctly
I recommend Borg and Borgmatic. Automated, easy to setup, capable of notifying you if anything happens, deduplication and compression makes backups smaller, etc.
-
Any advice/best practices for how to backup emails of Linux-based mail server
To add to this, Borg backup can be a little daunting to configure. There is a wrapper script called Borgmatic that distills it down to a single yaml config file. There are also some cloud hosts like BorgBase and rsync.net with native Borg support.
What are some alternatives?
BorgBackup - Deduplicating archiver with compression and authenticated encryption.
ioztat - ioztat is a storage load analysis tool for OpenZFS. It provides iostat-like statistics at an individual dataset/zvol level.
vorta - Desktop Backup Client for Borg Backup
benchmarks - Benchmarks of different backup tools.
restic - Fast, secure, efficient backup program
RcloneZFSBackup - Backup ZFS snapshots to cloud storage using RCLone
ansible-role-borgbackup - Ansible role to set up Borg and Borgmatic
borgtui - A nice TUI for BorgBackup
zpaqfranz - Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife for the serious backup and disaster recovery manager. Ransomware neutralizer. Win/Linux/Unix
bupstash - Easy and efficient encrypted backups.
kopia - Cross-platform backup tool for Windows, macOS & Linux with fast, incremental backups, client-side end-to-end encryption, compression and data deduplication. CLI and GUI included.