Anyone using kopia for backup?

Is anyone using kopia for backup? I am wondering how reliable it is. After getting burned by duplicati I am wary of newer backup solutions.

I have a pretty comprehensive backup strategy today but I feel like there is a weakness. My cloud backups. Today I am replicating my encrypted borg backups to the cloud using rclone. While this works fine, it introduces a risk. If something bad happens to my local borg repo, that would get replicated to my cloud copy.

My objective is to retain my local borg repo but do a completely separate backup directly the cloud. I was originally thinking of using restic. But kopia also looks interesting.

2 Likes

I used borg and restic in the past for some time but was not really happy. Then I switched to kopia and I like it very much.

A very nice feature is that it does maintenance automatically according to the policy you have defined (or the default policy if you have not specifically defined anything here).

For backup to the cloud it can be combined with rclone.

1 Like

Thanks for the feedback!

This is what I am trying to avoid. However, it looks like kopia can directly target S3, B2, Azure Blob, GCS, Webdav, sftp or kopia’s own repo solution without the need for rclone or a local copy.

1 Like

What’s wrong with only uploading a borg backup copy after checking it with borg check? If it fails the check in any way, do not upload, but raise alarm.

I assume “the cloud” is a server you have access to, so you can run the check there, too.

I only started using borg recently, so I’m not very experienced with it.

It doesn’t protect against a bug in borg itself. Is that paranoid? Probably. But I a can’t trust my Frogatto & Friends save game files to anything less.

5 Likes

True. For such data, there is no single backup solution, you always need multiple technologies.

For my needs, I have a really primitive solution, but I think quite effective. The really important data, which is unlikely to ever change, but must under all circumstances be preserved (tier 3, as I call it), I burn it to DVDs and give copies of it to a few trusted friends and family members for safe keeping.

1 Like

Realistically speaking you need to have a space-vault for that.

:frog:

I tried Kopia in the VM today, but it is a bit complicated in CLI. GUI ist Okay, but how to restore snapshot/backup via CLI?

I tried Borg a few months ago, it worked with restoring backup in local disk, but it does not work with restoring to other mounted disk. (Maybe I am missing something)

I am happy with Restic at the end after many tests in VM, its document is nice.

1 Like

In this case use just borg (or restic) and kopia the same time. A bug in both at the same time is less probable. :slight_smile:

1 Like

That is exactly what I want to do. Use borg for my local backups and use either restic or kopia for my cloud backups.

With kopia you have to mount a snapshot. Then you can restore.

Example

kopia mount kfb056233f99d414006db704ad6fc62b6 /mnt/

where kfb056233f99d414006db704ad6fc62b6 is the snapshot id.

1 Like

“I heard you like ZFS so I put snapshots in your backups.”

zfs send | zfs receive , or syncoid (from sanoid).:wink:

I didn’t want to mention it because then I might seem even more paranoid but I do that also.

For important data I usually have 4 copies + snapshots.

  1. The original copy & it’s snapshots
  2. A replica & it’s snapshots created with zfs send(znapzend)
  3. A borg backup
  4. A cloud backup
1 Like

Just because you’re paranoid, doesn’t mean it isn’t out to get you! That 4-step solution OUGHT to be adequate! :grin:

I am a bit older than most of you here (40 in hexadecimal). When I started with computing in 1986 or so a teacher in a course said: One backup is no backup (It was in German: Ein Backup ist kein Backup). I never forgot this. That’s the reason I don’t believe you are paranoid. :slight_smile: You may imagine that I also have much more than a single backup of my data.

2 Likes

In truth, it is a lesson learned the hard way. If data loss is possible it will happen to me.

  • I have had countless spinning disks fail
  • I have had at least 5 SSDs fail
  • I have had raid 5 arrays that lost two disks at the same time
  • I have had raid 6 arrays that lost three disks at the same time
  • I have had bad memory cause widespread disk corruption

That is just at my house on my personal network…

I also had countless HDDs (especially Seagate) and SSDs fail, but my no. 1 reason for losing data is user error.

Thanks, I will plan to setup Kopia for a cloud backup without root permission and systemd timer. It has nice policy UI which has schedule configuration.
I let restic for a weekly root backup in my other dual disks in my local.

If you are interested in the current benchmark in 2022: Borg, Restic, Kopia, Bupstash vs. Duplicacy on ZFS and XFS:

I was using borg before and thought I would give bupstash and kopia a try side by side and see if they are any reliable. That’s the most important thing for me than X tool is 5 sec faster than Y tool when creating backups. I have about 12 kopia repos which I also sync with rclone once a week. Today when i booted up, 1 of the 12 repos struggled to connect. so I tried it again and got this error -

Connect Error: INTERNAL: internal server error: connect error: error opening repository: error connecting: unable to create shared content manager: error loading indexes: error downloading indexes: error loading index blob xn3_cb5c1140f8cb745b0512a4900af4816e-sbf300b730eccaaf3117-c1: error decrypting BLOB xn3_cb5c1140f8cb745b0512a4900af4816e-sbf300b730eccaaf3117-c1: ciphertext too short: 0

I thought if local data is corrupted, or if anything is wrong with my local repo maybe I could try connecting via rclone, but apparently that doesn’t work since the recent rclone upgrade (saw it in the kopia issues) I could download whole repo from the cloud backup manually and try it and that might work but all of this doesn’t make me confident. I posted on the kopia github and hopefully the repo isn’t lost completely.

Edit: Downloaded the repo from the cloud and tried opening it, same errors sadly. So looks like all snapshots are gone for that particular backup.