4 ms·

> 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. Wi

by 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.
    - petre 7y ago
      No zealtory. I'd rather have the interpreter installed from the distribution and drop the fatpacked program with bundled libraries and everything in a bin directory. If it needs installing on Windows then the fatcpacked binary with bundled interpreter is also fine.
eeZah7Ux 7y ago
> With a Go program one just drops a statically compiled binary in $PATH and it just works. Until one of the statically compiled dependencies needs a security fix. Then people realize why shared objects where invented.
- deleted 7y ago
  [deleted]
- IshKebab 7y ago
  That's not why they were invented, and it's not even a good reason to use them.

by petre 7y ago

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.
  - petre 7y ago
    No zealtory. I'd rather have the interpreter installed from the distribution and drop the fatpacked program with bundled libraries and everything in a bin directory. If it needs installing on Windows then the fatcpacked binary with bundled interpreter is also fine.

eeZah7Ux 7y ago

> With a Go program one just drops a statically compiled binary in $PATH and it just works. Until one of the statically compiled dependencies needs a security fix. Then people realize why shared objects where invented.

deleted 7y ago
[deleted]
IshKebab 7y ago
That's not why they were invented, and it's not even a good reason to use them.