Kopia 0.7.0 not backing up any files! (Repro Needed)

Just updated to 0.7.0 from 0.6.something.

After the update was finished, all path sizes are showing as 0 Bytes. When clicking on a folder it shows all previous snapshots and their correct sizes (~400 GB in one of my folders), but the latest snapshots done after updating to 0.7.0 are showing as 0 Bytes.

This worries me a bit as the working snapshots will be deleted soon due to the retention policies…

When clicking on “snapshot now” it takes less than one second to complete. My repository is located on a local drive and the sources are mounted CIFS-paths as with local drive letters in Windows.

EDIT: Forgot to add that after the update to 0.7.0 was completed, I had to reconnect to my repository, but in previous upgrades this was not necessary.

This is known issue with 7 rc1 ui but the rc1 cli worked well

Try the cli tool

I don’t want to use the CLI tool, that’s why I use Kopia (as it is one of very few softwares of this kind that actually has a usable GUI).

The version I’m using is:
Version v0.7.0 built on Sunday, September 20, 2020 6:35:45 PM appveyor-vm

Are RC’s released in the auto-update? The update I installed was the one automatically prompted by Kopia GUI.

Something weird is happening after first launch after upgrade (some kind of permission issue) . Quitting and restarting Kopia fixes the issue. I’ll look into that.

Actually I’m not able to reproduce this, but because I’ve seen this 2-3 times in the past, I know what you’re talking about. Having said that I don’t know how exactly this happens, but restarting KopiaUI fixed the issue for me.

Basically for some reason when this happens, kopia reads the directory but it finds no files in it without any errors so it creates an empty snapshot. I suspect some kind of permissions issue.

This should be easy to remove using kopia snapshot delete from CLI, unfortunately the UI option is not available (yet).

If somebody finds a repro sequence that reliably triggers this, definitely let us know here.

I actually found the repro:

  1. Create repository (UI or CLI)
  2. Create some snapshots
  3. Disconnect from repository
  4. Launch KopiaUI
  5. Connect to the same repository path
  6. Take snapshot of existing path - becomes empty
  7. Exit KopiaUI
  8. Start KopiaUI
  9. Take snapshot of existing path - correct

So basically when KopiaUI is started without a repository and connection is first established in the UI, the next snapshot will have size zero. So it’s obviously not permission-related.

When KopiaUI is started with a pre-existing repository the bug does not repro, which explains why restarting fixes the issue. It also explains why @gregoff82 saw it - he had to reconnect after upgrading to 0.7.0.

I’ll try to track it down and release a hotfix ASAP.

Pull request out - https://github.com/kopia/kopia/pull/641 - this wasn’t easy to track down, but the fix was ultimately very simple.

Is this UI only issue? Any impact to CLI?

No CLI impact. Only UI was affected and only on initial connection. It’s been fixed now and v0.7.1 is now being built:


Nice that you found a fix. During the night my scheduling kicked in and it actually started to backup files.

However, it seems that it started over from the beginning (and not doing a incremental backup) so my other path that holds > 4TB is currently at 1.1 TB after aprox 5 hours. No biggie since my source and destination is within the same LAN, but for others with actual remote sources and/or destinations it can become quite an issue.

Anyhow, thanks for your time and keep up the good work! This is one of the best backup tools i’ve tried out (and I’ve tried alot!).

Pretty sure this is only reading and re-hashing files and not sending anything over the network since all the data is in the repo.

You can actually get the incremental backup if you:

  1. stop current snapshot
  2. delete zero-sized snapshots and all snapshots after last full successful snapshot using kopia snapshot delete
  3. restart snapshot

The repo hasn’t taken any more disk space so that sounds resonable.

Anyhow, I like the fact that my machine at home is working for me while I’m at work myself, so I’ll leave that for now (probably mostly done once I get home anyway).