> The "no-delete" permission disallows deleting objects as well as overwriting existing objects.
[0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...
it was implemented for "file:" (which is also used for "ssh://" repos) and there are automated tests for how borg behaves on such restricted permissions repos.
after the last beta I also added cli flags to "borg serve", so it now also can be used via .ssh/authorized_keys more easily.
so it can now also be used for practical applications, not just for testing.
not for production yet though, borg2 is still in beta.
help with testing is very welcome though!
[0] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...
[1] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...
Making e.g. snapshots on the backing storage was always the better approach.
https://github.com/restic/restic
https://github.com/restic/rest-server
which has to be started with --append-only. I use this systemd unit:
[Unit]
After=network-online.target
[Install]
WantedBy=multi-user.target
[Service]
ExecStart=/usr/local/bin/rest-server --path /mnt/backups --append-only --private-repos
WorkingDirectory=/mnt/backups
User=restic
Restart=on-failure
ProtectSystem=strict
ReadWritePaths=/mnt/backups
Been using this for about five years, it saved my bacon a few times, no problems so far.
rclone serve restic --stdio
restrict,command="rclone serve restic --stdio --append-only backups/my-restic-repo" ssh-rsa ...
ssh user@rsync.net rclone serve restic --stdio ...
restic ... --option=rclone.program="ssh -i <identity> user@host" --repo=rclone:
I've been doing this on rsync.net since at least February; works great!
I had the impression that in the beginning Borg started as a fork of Restic to add missing features, but Restic was the more mature project.
Is there still anything Borg has that Restic lacks?
For me the reason to use Borg over Restic has always been that it was _much_ faster due to using a server-side daemon that could filter/compress things. The downside being you can’t use something like S3 as storage (but services like Borgbase or Hetzner Storage Boxes support Borg).
That’s probably changed with the server backend, but with the same downside.
I am very much in the market for a replacement (looking at Rustic for example).
I'm not sure what exactly you expect that would be different?
rustic currently is in beta state and misses regression tests. It is not recommended to use it for production backups, yet.
Is this what append-only achieved for Borg?
There used to be append-only, they've removed it and suggest using a credential that has no 'delete' permission. The question asked here is whether this would protect against data being overwritten instead of deleted.
TL;DR: don't panic, all is good. :-)
Longer version:
- borg 1.x style “append-only” was removed, because it heavily depended on how the 1.x storage worked (it was a transactional log, always only appending PUT/DEL/COMMIT entries to segment files - except when compacting segments [then it also deleted segment files after appending their non-deleted entries to new segments])
- borg 2 storage (based on borgstore) does not work like that anymore (for good reasons), there is no “appending”. thus “—append-only” would be a misnomer.
- master branch (future borg 2 beta) has “borg serve —permissions=…” (and BORG_PERMISSIONS env var) so one can restrict permissions: “all”, “no-delete”, “write-only”, “read-only” offer more functionality than “append only” ever had. “no-delete” disallows data deleting as well as data overwriting.
- restricting permissions in a store on a server requires server/store side enforced permission control. “borg serve” implements that (using the borgstore posixfs backend), but it could be also implemented by configuring a different kind of store accordingly (like some cloud storage). it’s hard to test that with all sorts of cloud storage providers though, so implementing it in the much easier to automatically test posixfs was also a motivation to add the permissions code.
Links:
- docs: https://github.com/borgbackup/borg/pull/8906/files
- code: https://github.com/borgbackup/borg/pull/8893/files
- code: https://github.com/borgbackup/borg/pull/8844/files
- code: https://github.com/borgbackup/borg/pull/8837/files
Please upvote, so people don't get confused.
Anyone knows when will it come out of beta?
For low-latency storage (like file: and maybe ssh:) it already works quite nicely, but there might be a lot to do still for high-latency storage (like cloud stuff).
I don't know about any show-stoppers in borg 1.x.
Design limitations?
Yes, there are some, that's why borg2 will be quite different. But these are no easy or small changes.
Also, borg2 will be a breaking release (offering borg transfer to copy existing archives from borg 1.x repos). It takes long because we try to put all breaking changes into borg2, so you won't have to transfer again too soon after borg2 release.
For example, the file changed warning. That one ended up breaking my backup cron. I wasn't being notified (my fault there) and the rsync wasn't running. Caught it months later when I tried to run a test restore.
I'm fine with it returning a warning but people were asking for an option to suppress it and you said in 2022 it would be fixed in v2.
That's why it's disappointing. Appreciate the work though! Borg has definitely been a life safer and has recovered a failed production server already.
But this was a good reminder I should probably figure out some good way to monitor my borg repo for unintended changes. Having snapshots to roll back to is only useful if a problem is detected in time.
It wasn't perfect, but it did protect against some scenarios in which a device could be majorly messed up, yet the server was more resistant to losing the data.
For work, the backup schemes include separate additional protection of the data server or media, so append-only added to that would be nice, as redundant protection, but not as necessary.
Borg has the issue that it is in limbo, i.e. all the new features (including object storage support) are in Borg2, but there's no clear date when that will be stable. I also did not like that it was written in Python, because backups are not always IO blocked (we have some very large directories, etc.).
I really liked borgmatic on Borg, but we found resticprofile which is pretty much the same thing (it is underdiscussed). After some testing I think it is important to set GOGC and read-concurrency parameters, as a tip. All the GUIs are very ugly, but we're fine a CLI.
If rustic matures enough and is worth a switch we might consider it.
Single binary, well supported, dedup, compression, excellent snapshots, can mount a backup to restore a single file easily etc etc.
It's made my backups go from being a chore to being a joy.
This should be simpler still:
Git LFS is 50k loc, this is 891 loc. There are other differences, but that is the main one.
I don't want a sophisticated backup system. I want one so simple that it disappears into the background.
I want to never fear data loss or my ability to restore with broken tools and a new computer while floating on a raft down a river during a thunder storm. This is what we train for.
I don't see what value this provides that rsync, tar and `aws s3 cp` (or AWS SDK equivalent) provides.
abridged example:
rsync --archive --link-dest 2025-06-06 backup_role@backup_host:backup_path/ 2025-06-07/
rsync_cmd = [
'/usr/bin/rsync',
'--archive',
'--numeric-ids',
'--owner',
'--delete',
'--delete-excluded',
'--no-specials',
'--no-devices',
'--filter=merge backup/{backup_host}/filter.composed'.format(**rsync_param),
'--link-dest={cwd}/backup/{backup_host}/current/{backup_path}'.format(**rsync_param),
'--rsh=ssh -i {ssh_ident}'.format(**rsync_param),
'--rsync-path={rsync_path}'.format(**rsync_params),
'--log-file={cwd}/log/{backup_id}'.format(**rsync_params),
'{remote_role}@{backup_host}:/{backup_path}'.format(**rsync_params),
'backup/{backup_host}/work/{backup_path}'.format(**rsync_params) ]I think it sort of works like apples time-machine but I have never used that product so... (shrugs)
Note that it is not, in the strictest sense, a very good "backup" mainly because it is too "online", to solve that I have a set of removable drives that I rotate through, so with three drives, each ends up with every third day.
Google Cloud Store Archive Tier is a tiny bit more.
But I weigh that against data recovery from failed disks and the loss of the data I put in Glacier (family photos/etc). Then its dirt cheap.
My low value backups go into a cheap usb hdd from Best Buy.
I even wrote python scripts to automatically cleanup and unmount if something goes wrong (not enough space etc). On openbsd I can even Double encrypt with blowfish(vnconfig -K) and then a diff alg for bioctl.
Every once in a while things gets sparsed out, so that for example I have daily backups for the recent past, but only monthly and then even yearly for further back.
Bonus: the backups are readable without any specific tools, you don't have to be able to reinstall a backup software to restore files, which may or may not be difficult in 10 years.
This is the tool I use: https://github.com/hcartiaux/bontmia
It's forked from an old project which is not online anymore, I've fixed a few bugs and cleaned the code over the years.
Are you talking about using ZFS snapshots on the remote backup target? Trying to solve the same problem with local snapshots wouldn't work because the attack presumes that the device that's sending the backups is compromised.
Yes.
Would be interested to know what others have set up as I'm not really happy with how I do it. I have zfs on my NAS running locally. I backup to that from my PC via rsync triggered by anacron daily. From my NAS I use rclone to send encrypted backups to Backblaze.
I'd be happier with something more frequent from PC to NAS. Syncthing maybe? Then just do zfs sync to some off site zfs server.
Do note the 5 TiB minimum order for it though, it's not something that's enabled on other accounts.
I guess some people might have been relying on this feature of borgbackup to implement that requirement
Also, if anyone cares about preserving hardlinks and overlay2 directories, fileflags without loss of metadata. The binary is a drop in.
They are so similar in features. How do they compare? Which to choose?
All three have a lot of commands to work with repositories. Each one of them is much better than closed source proprietary backup software that I have dealt with, like Synology hyperbackup nonsense.
If you want a better solution, the next level is ZFS.
> If you want a better solution, the next level is ZFS.
Not a backup. Not a bad choice for storage for backup server tho
I don't need to configure and monitor cron jobs.
With ZFS, all file system is replicated. The backup will be consistent, which is not the case with file level backup. With latter, you have to also worry about lock files, permissions, etc. The restore will be more natural and quick with ZFS.
When I tested Restic (eight years ago) it was super slow.
No opinion about Kopia, never heard of it.
The fact that Kopia has a UI is awesome for non-technical users.
I migrated off restic due to memory usage, to Kopia. I am currently debating switching back to restic purely because of how retention works.
I was setting up PCs for unsophisticated users who needed to be able to do their own restores. Most OSS choices are only appropriate for technical users, and some like Borg are *nix-only.
I tried KopiaUI couple of times, it's not something I want as a personal backup tool.