3 ms·

For the longest time I used to use borg. These days, however, I am using kopia[0] https://kopia.io/ https://kopia.io/ Quite happy with it.

jarenmf 5y ago
Seems like an interesting project, what are the differences from borg?
- k8sToGo 5y ago
  Well it is written in Go instead of Python. If I remember correctly, borg is single threaded and quite slow. Kopia is really fast. Other than performance, the biggest benefit is that multiple clients can write to one repository at once. There is a designated maintenance user, though.
- mekster 5y ago
  When it comes to backup software, do yourself a favor and do extensive research on their stability and reliability. From what I learnt, borg has least problem of all the open source backup software with the most wanted features (encryption, dedup, compression and rotation) and others all have their quirks, be it huge memory usage, data loss to worst being corruption of the backup repository. Things may have improved since I've looked but you want user feedbacks saying so. It's too late to know that backup software has been failing when you need it as the original data is already unavailable, so choosing by the look of landing page is a bad way when it comes to backup. kopia is still new and last time I used about a year ago, it still had basic problems, so I would never use it in place of borg. restic, duplicati, duplicity and duplicacy all have some sort of problems especially when the repo gets large but of course there are cases where things are working fine. https://forum.rclone.org/t/rclone-as-destination-for-borgbackup/12717/9 https://forum.rclone.org/t/rclone-as-destination-for-borgbac... (Restic issues) https://www.reddit.com/r/Backup/comments/opu1ep/comment/h67n6s4/ https://www.reddit.com/r/Backup/comments/opu1ep/comment/h67n... (Kopia issues) https://forum.duplicacy.com/t/memory-usage/623/24 https://forum.duplicacy.com/t/memory-usage/623/24 (Duplicacy doing a big rewrite of the engine to fix memory issues.) https://forum.duplicati.com/t/is-duplicati-2-ready-for-production/4714 https://forum.duplicati.com/t/is-duplicati-2-ready-for-produ... (duplicati stability issues) https://www.reddit.com/r/unRAID/comments/eg0zpe/duplicati_seems_too_fragile_for_realworld_use/ https://www.reddit.com/r/unRAID/comments/eg0zpe/duplicati_se... (Another duplicati issues) borg also has change logs with any major reliability problems mentioned up front which gives you more confidence than serious bugs buried in GitHub issues like other tools. https://borgbackup.readthedocs.io/en/stable/changes.html https://borgbackup.readthedocs.io/en/stable/changes.html The only downside of borg is it can only target ssh host natively, but there are services like rsync.net (with special borg pricing), borgbase or you could locally run borg and rclone the entirety to anywhere you want.
  - k8sToGo 5y ago
    So my issue with borg is that it is slow and verification takes forever on large repositories. Will you not use borg now as well? Every software has its issues. That's why it's important to test restores regularly.
    - formerly_proven 5y ago
      There are a bunch of options to borg check depending on what you want. A full check with --verify-data is indeed rather slow, because it checks everything (essentially equivalent to seeing if all archives can be extracted plus a bunch of extra checks). If you only want to detect e.g. bit-rot, --repository-only will be sufficient in most cases and will be I/O limited.
    - mekster 5y ago
      There are certain priority to what you treat as issues. Slowness is the least of the problem against data loss or repo corruption and perhaps you may be able to somewhat circumvent it by splitting the repo to different locations or disks.
  - vlz 5y ago
    You mention duplicity but do not give a link to an issue. Do you know if there is something wrong with it? Would really appreciate you pointing me towards that if so.
    - mekster 5y ago
      Sorry I didn't link to an issue but a concern with duplicity is more about its implementation which needs incremental backups to depend on the base full backup (that you would make the first time) which means if you want to prune that base backup later on, you need to take a new full backup for later incremental backups to depend on instead of taking continuous incremental backups indefinitely. https://duplicity.gitlab.io/duplicity-web/vers8/duplicity.1.html https://duplicity.gitlab.io/duplicity-web/vers8/duplicity.1.... > When restoring, duplicity applies patches in order, so deleting, for instance, a full backup set may make related incremental backup sets unusable. Other software mentioned have each incremental backups independent of each others, so you can prune any of it and the last one is still retrievable.

jarenmf 5y ago

Seems like an interesting project, what are the differences from borg?

k8sToGo 5y ago
Well it is written in Go instead of Python. If I remember correctly, borg is single threaded and quite slow. Kopia is really fast. Other than performance, the biggest benefit is that multiple clients can write to one repository at once. There is a designated maintenance user, though.
mekster 5y ago
When it comes to backup software, do yourself a favor and do extensive research on their stability and reliability. From what I learnt, borg has least problem of all the open source backup software with the most wanted features (encryption, dedup, compression and rotation) and others all have their quirks, be it huge memory usage, data loss to worst being corruption of the backup repository. Things may have improved since I've looked but you want user feedbacks saying so. It's too late to know that backup software has been failing when you need it as the original data is already unavailable, so choosing by the look of landing page is a bad way when it comes to backup. kopia is still new and last time I used about a year ago, it still had basic problems, so I would never use it in place of borg. restic, duplicati, duplicity and duplicacy all have some sort of problems especially when the repo gets large but of course there are cases where things are working fine. https://forum.rclone.org/t/rclone-as-destination-for-borgbackup/12717/9 https://forum.rclone.org/t/rclone-as-destination-for-borgbac... (Restic issues) https://www.reddit.com/r/Backup/comments/opu1ep/comment/h67n6s4/ https://www.reddit.com/r/Backup/comments/opu1ep/comment/h67n... (Kopia issues) https://forum.duplicacy.com/t/memory-usage/623/24 https://forum.duplicacy.com/t/memory-usage/623/24 (Duplicacy doing a big rewrite of the engine to fix memory issues.) https://forum.duplicati.com/t/is-duplicati-2-ready-for-production/4714 https://forum.duplicati.com/t/is-duplicati-2-ready-for-produ... (duplicati stability issues) https://www.reddit.com/r/unRAID/comments/eg0zpe/duplicati_seems_too_fragile_for_realworld_use/ https://www.reddit.com/r/unRAID/comments/eg0zpe/duplicati_se... (Another duplicati issues) borg also has change logs with any major reliability problems mentioned up front which gives you more confidence than serious bugs buried in GitHub issues like other tools. https://borgbackup.readthedocs.io/en/stable/changes.html https://borgbackup.readthedocs.io/en/stable/changes.html The only downside of borg is it can only target ssh host natively, but there are services like rsync.net (with special borg pricing), borgbase or you could locally run borg and rclone the entirety to anywhere you want.
- k8sToGo 5y ago
  So my issue with borg is that it is slow and verification takes forever on large repositories. Will you not use borg now as well? Every software has its issues. That's why it's important to test restores regularly.
  - formerly_proven 5y ago
    There are a bunch of options to borg check depending on what you want. A full check with --verify-data is indeed rather slow, because it checks everything (essentially equivalent to seeing if all archives can be extracted plus a bunch of extra checks). If you only want to detect e.g. bit-rot, --repository-only will be sufficient in most cases and will be I/O limited.
  - mekster 5y ago
    There are certain priority to what you treat as issues. Slowness is the least of the problem against data loss or repo corruption and perhaps you may be able to somewhat circumvent it by splitting the repo to different locations or disks.
- vlz 5y ago
  You mention duplicity but do not give a link to an issue. Do you know if there is something wrong with it? Would really appreciate you pointing me towards that if so.
  - mekster 5y ago
    Sorry I didn't link to an issue but a concern with duplicity is more about its implementation which needs incremental backups to depend on the base full backup (that you would make the first time) which means if you want to prune that base backup later on, you need to take a new full backup for later incremental backups to depend on instead of taking continuous incremental backups indefinitely. https://duplicity.gitlab.io/duplicity-web/vers8/duplicity.1.html https://duplicity.gitlab.io/duplicity-web/vers8/duplicity.1.... > When restoring, duplicity applies patches in order, so deleting, for instance, a full backup set may make related incremental backup sets unusable. Other software mentioned have each incremental backups independent of each others, so you can prune any of it and the last one is still retrievable.