- 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.
at first it was implemented to easily test permission restricted storages (can't easily test on all sorts of cloud storages).
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.
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).
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.
Nothing really breaking but annoying, but I suppose you wouldn't even consider it a bug then.
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.
borg supports the "obfuscate" pseudo compressor since 1.2.0 (since Feb 2022), that adds random extra length to the chunks, using one of 2 different algorithms to determine the extra length.
Basic stuff might work in a "posix-like" environment, like when using cygwin or WSL.
The main problem is that there currently aren't active windows developers within the borgbackup project who continuously test and improve the windows specific code parts.
Since recently, we at least have some working CI on windows again, at least that was fixed.
Comparisons might be interesting, but one needs to be aware that they would be a bit apples to oranges:
- unreleased code that is still in heavy development (borg2, especially the new repository code inside borg2).
- released code (restic) that has practically proven "cloud support" since quite a while.
borg2 is using rclone for the cloud backend, so that part is at least quite proven, but the layers above that in borg2 are all quite fresh and not much optimized / debugged yet.
