# Recreating database logic/understanding/issue/slow

**URL:** https://forum.duplicati.com/t/recreating-database-logic-understanding-issue-slow/6496
**Category:** Support
**Created:** [March 4, 2019, 4:26pm UTC](https://forum.duplicati.com/t/recreating-database-logic-understanding-issue-slow/6496 "2019-03-04T16:26:24Z")
**Posts on this page:** 1
**Showing post:** 4

<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: [March 5, 2019, 12:59am UTC](https://forum.duplicati.com/t/recreating-database-logic-understanding-issue-slow/6496/4 "2019-03-05T00:59:49Z")

</div>

> [@josea](#):
>
> I am trying to make sense of the files in the storage folder. I am guessing that the dlist one is created when a backup session completes, and it contains a list of of dblock/dbindex/files or similar.

[How the backup process works](https://duplicati.readthedocs.io/en/latest/appendix-a-how-the-backup-process-works/) has some documentation, including for filelist.json that’s in the dlist file.

> [@josea](#):
>
> Is there a place where the logic this is applying is documented? I couldn’t find it.

Unfortunately I don’t think documentation gets as far down as details of recreate. If you can read source (which also has a few comments), the links I point to might help. It looks to me like it gathers dlists, then dindexes, then (as said earlier) goes to fetch dblock files if data is still missing. Testing with new backup having an empty source file caused dlist to have this entry in filelist.json – but not in the dindex or dblock:

> {“type”:“File”,“path”:“C:\emptytests\length0.txt”,“hash”:“47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=”,“size”:0,“time”:“20190305T000452Z”,“metahash”:“TZm2AFXRe8Y4ja/tCPQ7NU/QSv9mqhpnUcht89kWldU=”,“metasize”:137}

I tested a new backup of a 1 byte file, then added a 0 byte file and did another backup. I used a [Database](https://duplicati.readthedocs.io/en/latest/03-using-the-graphical-user-interface/#database-management) `Delete`, then used [Commandline](https://duplicati.readthedocs.io/en/latest/03-using-the-graphical-user-interface/#using-the-command-line-tools-from-within-the-graphical-user-interface) to run a [repair](https://duplicati.readthedocs.io/en/latest/04-using-duplicati-from-the-command-line/#the-repair-command), changing the `Commandline arguments` to [–console-log-level](https://duplicati.readthedocs.io/en/latest/06-advanced-options/#console-log-level)=information and (on next line) [–version](https://duplicati.readthedocs.io/en/latest/06-advanced-options/#version)=(1 for first backup or 0 for second). The options can also be added at screen bottom `Add advanced option`. Remember to delete database as you change versions. You’ll see (if you get the same results) that the version with only the 1-byte file ends nicely after the dindex files are read, but the second backup (known as 0 because 0 is newest) continues to read all dblock files.

The recreated database also has the VolumeID 0f -1, so possibly that’s at least one way to get that oddity. Getting deep in terminology, the 0 length file ended at Blockset table, without BlocksetEntry or Block table. Earlier I had described one that got to the Block table with an empty block. There are 3 ways to show this.

If you prefer to test using a full database Recreate (instead of specifying --version), live logging as you did originally should be fine. You could also examine your source area to see if you even have any empty files, because there might be some other ways (not involving empty files) to get all the dblock files downloaded.

Usually though, a test case is better than none, so I hope this aids development. I might soon file an [issue](https://github.com/duplicati/duplicati/issues), however I’d certainly encourage you to do it if you can replicate something similar to the above test results.

---

_[View the full topic](https://forum.duplicati.com/t/recreating-database-logic-understanding-issue-slow/6496)._