7 ms·

With the exception of being able to upload to different targets (which can be piggybacked onto borg with something like rclone), borg is definitely the one with

With the exception of being able to upload to different targets (which can be piggybacked onto borg with something like rclone), borg is definitely the one with more whistles, not the other way around. Restic is lagging behind borg in most features, they always come up in borg first and then after a year restic maybe implements them. Important features currently missing in restic which exist in borg: compression, append-only backups, extensive include/exclude patterns, flagging any directory for exclusion directory exclude with a tag file inside it, setting "--chunker-params" - thus being able to adjust deduplication settings (like size of chunks, how hard it tries to look for duplicates etc) to the nature of the files and the limitations of RAM and CPU during backup. (and other minor ones). Other differences which some might consider good and others bad include: * Borg is in Python, Restic is in Go? Python is a more widely known language, the chance that more developers will be able to maintain it is higher, the chance for new features is higher, the chance that bugs will be found is higher. Both still provide a static binary download so deployment is very easy for both. * Borg allows setting names for archives (which can still be templated with things like {now} or {username}), while Restic automatically names them with random ids. Borg's approach seems more user-friendly. * Borg allows more choice in what encryption is used, including authenticated/non-authenticated, and including using no encryption at all (might be useful in some cases). (https://borgbackup.readthedocs.io/en/stable/usage/init.html#encryption-modes https://borgbackup.readthedocs.io/en/stable/usage/init.html#...) * Borg allows specifying "max_segment_size = xxxx" on a repository, thus allowing to somewhat adjust the size of archive ("segment") files while they are stored on the server (default being 500 MB). Restic uses its own sizing and (if I remember correctly) more often than not it produces very small files (a couple of MBs) which crowd the filesystem. In general, archive file sizes can affect the filesystem and the uploading them to the cloud, where many cloud providers API operates on individual files, not on parts of them.

mike-cardwell 7y ago
append-only backups: It supports this with the REST backend. flagging any directory for exclusion directory exclude with a tag file inside it: It has this. It's called --exclude-caches and will exclude any directory with a "CACHEDIR.TAG" file in with the correct content.
- Erlich_Bachman 7y ago
  Ok, that's certainly a good thing that it does support it now. Borg also allows to specify the name of that file, it does not restrict it to being "CACHEDIR.TAG". Giving an option to support both "CACHEDIR.TAG" and any other filename is a good thing. (One might want to exclude other directories that way, unrelated to cache directories.)
  - mike-cardwell 7y ago
    CACHEDIR.TAG seems to be based on a spec that multiple pieces of software are starting to use. Give it a quick google. I can't think of any reason why you would need to customise the name of the file, but I'm sure there are use cases out there.
    - deleted 7y ago
      [deleted]
    - nine_k 7y ago
      This is also a problem. I might like to mark certain things as not backed up because they contain sensitive or otherwise unrelated information. But I might not want other tools treat them as cache data, that is, transient and safe to delete.
      - mike-cardwell 7y ago
        Then you can just add `--exclude filename` to your backup job.
  - kilburn 7y ago
    Actually, "--exclude-caches" in restic is just an alias equivalent to the following [1]: --exclude-if-present "CACHEDIR.TAG:Signature: 8a477f597d28d172789f06886806bc55" You can specify the tag filename, and optionally append ":initial content" (the tag file must start with this content to avoid false tagfile matches). [1] https://restic.readthedocs.io/en/stable/040_backup.html#including-and-excluding-files https://restic.readthedocs.io/en/stable/040_backup.html#incl...
petre 7y ago
> Borg is in Python, Restic is in Go? Python is a more widely known language One doesn't need an interpreter + supporting libraries to run a backup program. With a Go program one just drops a statically compiled binary in $PATH and it just works. Anyway, I'm still using duplicity. It backups on rsync, ftp, you name it. Written in Python as well, unfortunately. Don't care abot S3 etc as I don't like loss of control over my backups.
- Erlich_Bachman 7y ago
  To repeat my original post, both tools provide a static binary download, making it easy to deploy. Both "just work". It's a single file that you chmod and run. Duplicity, as you may know is not a deduplicating backup solution, it is an incremental backup solution, suffering from all the flaws and limitations thereof. If you happened to not realize the difference, I highly recommend this short but informative blog post from Backblaze: https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/ https://www.backblaze.com/blog/backing-linux-backblaze-b2-du...
  - petre 7y ago
    Static binary as the whole interpreter and modules bundled in a fat binary? No thanks. I know the difference, but this way we have 4G volumes we could eventually burn to DVDs if we'd want to. No backup repositories, cloud storage solutions or new and obscure network protocols involved. Deduplication is also uninteresting for us because the largest part of our backup are SQL dumps. This is why we make full backups every time.
    - Erlich_Bachman 7y ago
      You don't have 14 MBs to spare for a static binary? What is this zealotry against interpreter languages? You know that your Go static binaries are basically the same thing - one binary packaged with all the bundled modules into a fat file? Where is the logic here? Also why would deduplicating be uninteresting when the backups are SQL dumps? That is EXACTLY the scenario in which deduplication would shine, because it would take each dump and find parts of it that are the same as the latest backup, finding the individual small chunks that have changed in those dumps, and only backing them up. Do you actually know how deduplication works? You might want to look that up more properly.

mike-cardwell 7y ago

append-only backups: It supports this with the REST backend. flagging any directory for exclusion directory exclude with a tag file inside it: It has this. It's called --exclude-caches and will exclude any directory with a "CACHEDIR.TAG" file in with the correct content.

Erlich_Bachman 7y ago
Ok, that's certainly a good thing that it does support it now. Borg also allows to specify the name of that file, it does not restrict it to being "CACHEDIR.TAG". Giving an option to support both "CACHEDIR.TAG" and any other filename is a good thing. (One might want to exclude other directories that way, unrelated to cache directories.)
- mike-cardwell 7y ago
  CACHEDIR.TAG seems to be based on a spec that multiple pieces of software are starting to use. Give it a quick google. I can't think of any reason why you would need to customise the name of the file, but I'm sure there are use cases out there.
  - deleted 7y ago
    [deleted]
  - nine_k 7y ago
    This is also a problem. I might like to mark certain things as not backed up because they contain sensitive or otherwise unrelated information. But I might not want other tools treat them as cache data, that is, transient and safe to delete.
    - mike-cardwell 7y ago
      Then you can just add `--exclude filename` to your backup job.
- kilburn 7y ago
  Actually, "--exclude-caches" in restic is just an alias equivalent to the following [1]: --exclude-if-present "CACHEDIR.TAG:Signature: 8a477f597d28d172789f06886806bc55" You can specify the tag filename, and optionally append ":initial content" (the tag file must start with this content to avoid false tagfile matches). [1] https://restic.readthedocs.io/en/stable/040_backup.html#including-and-excluding-files https://restic.readthedocs.io/en/stable/040_backup.html#incl...

petre 7y ago

> Borg is in Python, Restic is in Go? Python is a more widely known language One doesn't need an interpreter + supporting libraries to run a backup program. With a Go program one just drops a statically compiled binary in $PATH and it just works. Anyway, I'm still using duplicity. It backups on rsync, ftp, you name it. Written in Python as well, unfortunately. Don't care abot S3 etc as I don't like loss of control over my backups.

Erlich_Bachman 7y ago
To repeat my original post, both tools provide a static binary download, making it easy to deploy. Both "just work". It's a single file that you chmod and run. Duplicity, as you may know is not a deduplicating backup solution, it is an incremental backup solution, suffering from all the flaws and limitations thereof. If you happened to not realize the difference, I highly recommend this short but informative blog post from Backblaze: https://www.backblaze.com/blog/backing-linux-backblaze-b2-duplicity-restic/ https://www.backblaze.com/blog/backing-linux-backblaze-b2-du...
- petre 7y ago
  Static binary as the whole interpreter and modules bundled in a fat binary? No thanks. I know the difference, but this way we have 4G volumes we could eventually burn to DVDs if we'd want to. No backup repositories, cloud storage solutions or new and obscure network protocols involved. Deduplication is also uninteresting for us because the largest part of our backup are SQL dumps. This is why we make full backups every time.
  - Erlich_Bachman 7y ago
    You don't have 14 MBs to spare for a static binary? What is this zealotry against interpreter languages? You know that your Go static binaries are basically the same thing - one binary packaged with all the bundled modules into a fat file? Where is the logic here? Also why would deduplicating be uninteresting when the backups are SQL dumps? That is EXACTLY the scenario in which deduplication would shine, because it would take each dump and find parts of it that are the same as the latest backup, finding the individual small chunks that have changed in those dumps, and only backing them up. Do you actually know how deduplication works? You might want to look that up more properly.