4 ms·

Not to be confused with Duplicati [1] or Duplicacy [2]. There are too many backup programs whose names start with 'Duplic'. [1] https://www.duplicati.com/ http

by tzs 3y ago

Not to be confused with Duplicati [1] or Duplicacy [2]. There are too many backup programs whose names start with 'Duplic'. [1] https://www.duplicati.com/ https://www.duplicati.com/ [2] https://duplicacy.com/ https://duplicacy.com/

jszymborski 3y ago
While we're on the topic of Duplicati, I feel the need to share my personal experience; one that's echoed by lots of folks online. Duplicati restores can take what seems like the heat death of the universe to restore a repo as little as 500Gb. I've lost a laptop worth of files to it. You can find tonnes of posts on the Duplicati forums which retell the same story [0]. I've moved to Borg and backing up to a Hetzner Storage Box. I've restored many times with no issue. Remember folks, test your backups. [0] https://forum.duplicati.com/t/several-days-and-no-restore-feedback/5396 https://forum.duplicati.com/t/several-days-and-no-restore-fe...
- johnchristopher 3y ago
  > Remember folks, test your backups. Since you mention it, I am seizing the opportunity to ask: how should borg backup be tested ? Can it be automated ?
  - jszymborski 3y ago
    It's actually pretty simple using the check command [0]! borg check --verify-data REPOSITORY_OR_ARCHIVE You can add that to a cron job. Alternatively, I think the Vorta GUI also has a way to easily schedule it[1]. I'll add that one thing I like to do once in a blue-moon is to spin-up a VM and try to recover a few random files. While the check command checks that the data is there and theoretically recoverable, nothing really beats proving to yourself that you can, in a clean environment, recover your files. [0] https://borgbackup.readthedocs.io/en/stable/usage/check.html https://borgbackup.readthedocs.io/en/stable/usage/check.html [1] https://vorta.borgbase.com/ https://vorta.borgbase.com/
    - johnchristopher 3y ago
      > It's actually pretty simple using the check command [0]! > borg check --verify-data REPOSITORY_OR_ARCHIVE Thanks ! I thought there were some more convoluted process but I couldn't picture out anything except extracting the whole archives and check up by hand.
  - pdimitar 3y ago
    Yes, I have a bunch of scripts that allow me to pick a Borg snapshot and then do stuff with it. One such action is `borg export-tar` that just creates a TAR file containing a full self-sufficient snapshot of your stuff. Then just listing the files in the archive is a not-bad way to find an obvious problem. Or straight up unpacking it. But if you're asking about a separate parity file that can be used to check and correct errors -- I haven't done that.
- flagged24 3y ago
  Same story, Hetzner storage box, local backups and at times a backup to my Android phone. Automated backup testing and a notification on Telegram if anything is amiss.
rabbitofdeath 3y ago
Duplicacy for me has been amazing - I use it to backup all of my machines nightly all consolidated into 1 repo that is copied to B2 and it works amazingly. I've restored plenty and have not had any issues.
- russelg 3y ago
  I'm curious as to why you took that approach. Why not just straight to B2 from each machine? Is it for a redundant local copy of all the backups? If so that sounds like a good idea since restoring from B2 takes ages just because listing the revisions is hella slow for me...
  - rabbitofdeath 3y ago
    I like the one-repository approach as it works well - it resides on my NAS which is always on and it is a local backup for multiple machines. From there, I replicate to B2 as an emergency copy in the event my NAS (RAID is not backup!) dies or something horrific. I tried to make it future-proof as much as possible too - with Duplicacy, you can easily clone/copy repositories so new hardware migration will be extremely simple. Not only simple with local hardware, but easy to migrate to a different cloud storage as well. Just don't lose your repository encryption key!

by tzs 3y ago

jszymborski 3y ago

While we're on the topic of Duplicati, I feel the need to share my personal experience; one that's echoed by lots of folks online. Duplicati restores can take what seems like the heat death of the universe to restore a repo as little as 500Gb. I've lost a laptop worth of files to it. You can find tonnes of posts on the Duplicati forums which retell the same story [0]. I've moved to Borg and backing up to a Hetzner Storage Box. I've restored many times with no issue. Remember folks, test your backups. [0] https://forum.duplicati.com/t/several-days-and-no-restore-feedback/5396 https://forum.duplicati.com/t/several-days-and-no-restore-fe...

johnchristopher 3y ago
> Remember folks, test your backups. Since you mention it, I am seizing the opportunity to ask: how should borg backup be tested ? Can it be automated ?
- jszymborski 3y ago
  It's actually pretty simple using the check command [0]! borg check --verify-data REPOSITORY_OR_ARCHIVE You can add that to a cron job. Alternatively, I think the Vorta GUI also has a way to easily schedule it[1]. I'll add that one thing I like to do once in a blue-moon is to spin-up a VM and try to recover a few random files. While the check command checks that the data is there and theoretically recoverable, nothing really beats proving to yourself that you can, in a clean environment, recover your files. [0] https://borgbackup.readthedocs.io/en/stable/usage/check.html https://borgbackup.readthedocs.io/en/stable/usage/check.html [1] https://vorta.borgbase.com/ https://vorta.borgbase.com/
  - johnchristopher 3y ago
    > It's actually pretty simple using the check command [0]! > borg check --verify-data REPOSITORY_OR_ARCHIVE Thanks ! I thought there were some more convoluted process but I couldn't picture out anything except extracting the whole archives and check up by hand.
- pdimitar 3y ago
  Yes, I have a bunch of scripts that allow me to pick a Borg snapshot and then do stuff with it. One such action is `borg export-tar` that just creates a TAR file containing a full self-sufficient snapshot of your stuff. Then just listing the files in the archive is a not-bad way to find an obvious problem. Or straight up unpacking it. But if you're asking about a separate parity file that can be used to check and correct errors -- I haven't done that.
flagged24 3y ago
Same story, Hetzner storage box, local backups and at times a backup to my Android phone. Automated backup testing and a notification on Telegram if anything is amiss.

rabbitofdeath 3y ago

Duplicacy for me has been amazing - I use it to backup all of my machines nightly all consolidated into 1 repo that is copied to B2 and it works amazingly. I've restored plenty and have not had any issues.

russelg 3y ago
I'm curious as to why you took that approach. Why not just straight to B2 from each machine? Is it for a redundant local copy of all the backups? If so that sounds like a good idea since restoring from B2 takes ages just because listing the revisions is hella slow for me...
- rabbitofdeath 3y ago
  I like the one-repository approach as it works well - it resides on my NAS which is always on and it is a local backup for multiple machines. From there, I replicate to B2 as an emergency copy in the event my NAS (RAID is not backup!) dies or something horrific. I tried to make it future-proof as much as possible too - with Duplicacy, you can easily clone/copy repositories so new hardware migration will be extremely simple. Not only simple with local hardware, but easy to migrate to a different cloud storage as well. Just don't lose your repository encryption key!