# Backup started failing "non-empty blocksets with no associated blocks"

**URL:** https://forum.duplicati.com/t/backup-started-failing-non-empty-blocksets-with-no-associated-blocks/3549
**Category:** Support
**Created:** [May 13, 2018, 8:35pm UTC](https://forum.duplicati.com/t/backup-started-failing-non-empty-blocksets-with-no-associated-blocks/3549 "2018-05-13T20:35:58Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)
#### Post date: [January 9, 2019, 4:51pm UTC](https://forum.duplicati.com/t/backup-started-failing-non-empty-blocksets-with-no-associated-blocks/3549/7 "2019-01-09T16:51:36Z")

</div>

> [@johnvk](#):
>
> I am guessing that @T_C means deleting from the source list

Agreed, and that’s what I translated into “deselection”, meaning take what was checked and click to uncheck. After that, things got less clear to me. I don’t think I wandered into on-disk deletions from source (don’t do it), however deletions from destination backup files (and their representation in the database) are key to the bug because it’s complaining about seeing files with non-zero lengths where it can’t find any blocks for the files… Version deletion can eventually take care of that (or sooner, if requested) by erasing memories of those files.

---

_[View the full topic](https://forum.duplicati.com/t/backup-started-failing-non-empty-blocksets-with-no-associated-blocks/3549)._