51–60 of 119 posts
Is this what append-only achieved for Borg?
Borg vs Restic vs Kopia ? They are so similar in features. How do they compare? Which to choose?
Kopia is awesome. With exception to it’s retention policies, but work like no other backup software that I’ve experienced to date. I don’t know if it’s just my stupidity, being stuck in 20 year thinking or just the fact it’s different. But for me, it feels like a footgun. 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 switc…
This has been replaced with a permissions feature that still provides both delete and overwrite protections. The difference is the underlying store needs to implement it rather than running a server that understands the permission differences. You can read more about this change here: https://github.com/borgbackup/borg/issues/8823#issuecomment-...
> The "no-delete" permission disallows deleting objects as well as overwriting existing objects.
[0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...
This has been replaced with a permissions feature that still provides both delete and overwrite protections. The difference is the underlying store needs to implement it rather than running a server that understands the permission differences. You can read more about this change here: https://github.com/borgbackup/borg/issues/8823#issuecomment-...
Earlier quoted context omitted.
Is this a joke? I don't see what value this provides that rsync, tar and `aws s3 cp` (or AWS SDK equivalent) provides.
How do you version your rsync backups?
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) ]Earlier quoted context omitted.
How do you version your rsync backups?
I use rsyncs --link-dest abridged example: rsync --archive --link-dest 2025-06-06 backup_role@backup_host:backup_path/ 2025-06-07/ Actual invocation is this huge hairy furball of an rsync command that appears to use every single feature of rsync as I worked on my backup script over the years. rsync_cmd = [ '/usr/bin/rsync', '--archive', '--numeric-ids', '--owner', '--delete', '--delete-excluded', '--no-specials', '--…
This has been replaced with a permissions feature that still provides both delete and overwrite protections. The difference is the underlying store needs to implement it rather than running a server that understands the permission differences. You can read more about this change here: https://github.com/borgbackup/borg/issues/8823#issuecomment-...
This comment needs to be pinned, alongside what the developers say [0] since the change is very misunderstood. > The "no-delete" permission disallows deleting objects as well as overwriting existing objects. [0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...
For anyone looking to migrate off borg because of this, append-only is available in restic, but only with the rest-server backend: 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-o…
Earlier quoted context omitted.
This comment needs to be pinned, alongside what the developers say [0] since the change is very misunderstood. > The "no-delete" permission disallows deleting objects as well as overwriting existing objects. [0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...
Isn't this "no-delete permission" just a made-up mode for testing the borg storage layer while simulating a lack of permissions for deleting and overwriting? In actual deployment, whatever backing store is used must have the access control primitives to implement such a restriction. I don't know how to do this on a posix filesystem, for example. Gemini gave me a convoluted solution that requires the client to change…
[0] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...
[1] https://github.com/borgbackup/borg/blob/3cf8d7cf2f36246ded75...