Kopia vs Restic comparison

I just learned about Kopia which has one of the longest “attributes” lines as listed on: https://github.com/restic/others

  • What are the pros/cons of Restic vs Kopia?

  • Are there certain use cases better suited to one over the other?

1 Like

Did you try both? I haven’t spent much time with kopia but felt restic is more straight forward to use in its CLI. Doesn’t matter much though.

Kopia looks to be about a year old, compared with Restic about five years old. Time in use and wider adoption might mean Restic has more bugs worked through than Kopia.

Of interest from the features page (https://kopia.io/docs/features/):

3 types of compression are supported including pgzip and the recent zstd.

B2 isn’t supported, but B2 now emulates S3 for free, with a minimal performance hit.

If anyone could spot features missing in either direction that would be appreciated.

I have used both kopia and restic and am currently a kopia user (with minor contributions to the project). The company I am at has contributed code to both restic and kopia.

Overall, kopia has better support for eventual consistency and parallel operations (lock-free). Also has better performance in terms of speed and compression too. I really appreciate that kopia has an API and SDK but yes, it is a more recent project.

What do you mean by better support of eventual consistency? Does that it just mean backing up to S3 backends? Is there any other meaning for the backup process/state itself

I did a quick performance comparison creating an initial snapshot (full backup) of 5228 files, 3.001 GiB to an SMB drive over a fairly fast LAN. Restic took 23:48min. Kopia finished in 3:30. While creating the backup, Kopia shows three numbers: bytes hashed, cached, and transmitted. All three stages seem to be asynchronous. I guess that’s what the term “eventual consistency” refers to.

Edit: this was without compression. Setting compression to zstd in Kopia brought down the backup creation time to 2:30 and the size to 2.3GB :slight_smile:

It would be very interesting if someone could nail down what is causing that big of a difference between the two for that task. Any takers?

@random:
Any chance you can re-do your test on a local filesystem? As this is SMB, I’m wondering if this is related to #2659.

Did a similar test against a local USB 3.0 HD, but also different dataset and OS (Linux this time, above it was Windows):

  • Restic 0.9.6: Added to the repo: 4.841 GiB, processed 20542 files, 5.243 GiB in 1:10
  • Kopia 0.5.2: same in 2m15s (with zstd compression) and 1m22s without
    :slight_smile:

I used restic 0.9.6 compiled with go1.13.4 on windows/amd64. That bug is supposedly introduced by go1.14 only.

In Kopia the hashing and uploading seems to be strongly decoupled. Not sure how Restic does this exactly but if it waits with the next block until the previous block has been uploaded to ensure consistency at all times (or sth. similar; I am guessing naively here) this could explain the difference in performance too.

Source: internal SATA SSD, Btrfs, 58496 files 31.029 GiB. Target: internal SATA harddisk, Ext4.

  • Kopia 0.5.2 (AppImage downloaded from GitHub), repository initialized with default parameters (GUI)
  • Restic 0.9.6 (current Arch package), repository also initialized with default parameters (CLI)

My results:

  • Kopia: 7:48, repository size 30.72 GiB
  • Restic: 6:55, repository size 30.56 GiB

So, no surprise here.

3 Likes

From an earlier comment, by eventual consistency I do mean being able to handle object storage (e.g. AWS S3) eventual consistency correctly.

I am also benchmarking the two systems and hope to have a blog post with more data out soon. kopia results are quite impressive.

1 Like

Does restic (via rclone) have issues with handling S3 backends? I think that rclone does all the work on managing the backend pieces and so restic should be ok too?

(I dont know much about eventual consistency but as long as restic isn’t immediately get at recently uploaded files and modity them; it shouldn’t be a problem ?)

Despite Kopia being more recent it will be interesting to see how the release and feature implementation cadence compares to Restic.

Admittedly there is a balance to be had in terms of stability, but some feature discussions for Restic date back several years, often with promising contributions sitting idle with little directional feedback.

Kopia author here - I just found this thread.

Eventual consistency improvements in Kopia 0.6 (to be released soon) mean that on a reasonable eventually-consistent store such as S3 which guarantees “read-after-create” semantics (with the “as long as you don’t peek before creating” caveat) but does not guarantee “list-after-create”, kopia will be able to ensure:

  • connected repository clients will see their own writes for as long as repository is connected
  • you will be able to see writes from other repository clients and they won’t “go back in time”

This is done using caching and two-stage compaction logs, which guarantee that as long as eventual consistency settles writes within ~1hr (currently that time is hardcoded, but could be configurable for extreme cases in the future), clients should observe this reasonable behavior and garbage collection remains safe.

BTW. It’s been >3 months since 0.5 release and there have been big performance improvements since then in the Git repository, so when benchmarking it’s best to compile the binary yourself.

If you have any more questions, feel free to ping me on https://slack.kopia.io

2 Likes

FWIW, fast-forward a number of years and that will be the case with most software, including Kopia.

You may well be right, and my comment was not intended as a criticism.

For those of us on the Restic bandwagon it is simply disheartening at times to realise that features/improvements we desire are unlikely to materialise any time soon (in my case VSS support and of course speedier prunes).

1 Like

Being one that gets a mail for every comment/issue/PR/etc in the restic repository I can tell you that there’s a lot of work, not to mention thought, going on even if it may not seem so (including for the prune command). I personally think the next restic release will be quite an improvement :slight_smile:

The fact that there’s some years-old issues and PRs is mostly due to us not wanting to straight off close the ones we don’t envision merging soon (we’d rather keep them around for various reasons) as well as there being a lot more work to dealing with even seemingly simple ones than most people probably imagine. Writing code is easy, reviewing and making sure code won’t break things is hard and takes a lot of time, even for seemingly simple things. Not meant as an excuse or anything, just saying there’s more to it than one might think.

I have your VSS thing (assuming yours is the one I’m thinking of) on the radar, it’s one of those I’d like to get merged sometime soon. But there’s still not a lot of testing having been done on it, and if I’m not mistaken someone reported a 32-bit problem with it just the other day, so it’s not entirely straight-forward.

2 Likes

Fair comment, I understand and appreciate all that you have said, no doubt most Restic users would echo the same.

Sadly I am not a bidding contributor, indeed my programming skills are more than a little rusty (and not in the trendy way). That said I do recognise the work which must go into ensuring stability, while also balancing the challenge of feature parity.

Looking forward to the next release, I am sure it will be well recieved.

2 Likes