# Need help resuming local database repair **URL:** \ **Category:** Support\ **Created:** [September 12, 2021, 4:38pm UTC](https://forum.duplicati.com/t/need-help-resuming-local-database-repair/13050 "2021-09-12T16:38:39Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)\ **Post date:** [September 15, 2021, 12:44am UTC](https://forum.duplicati.com/t/need-help-resuming-local-database-repair/13050/4 "2021-09-15T00:44:21Z")
> [@dyc3](#): > > I was on the profiling log level in under the “Live” tab, and left it for 2 days with no new messages. I’m not sure if this will run forever, without limit. A log file may be more reliable, but profiling log is big. Regardless, I guess we don’t know anything about where it ended (e.g. was it close or very far off?). If you wish to try, [DB Browser for SQLite](https://sqlitebrowser.org/) could inspect the database, maybe comparing the known (by inspection) number of dindex files at the remote against how many got into IndexBlockLink table. > [@dyc3](#): > > Size is ~2 TB The default 100 KB [blocksize](https://duplicati.readthedocs.io/en/latest/06-advanced-options/#blocksize) is too small for that big a backup. but there’s no auto-tune or config aid. 2 MB would have made fewer blocks to track. Some DB operations grow too slow with many blocks. Unfortunately one can’t change blocksize on an existing backup. Too much code requires it constant. > [@dyc3](#): > > I’ve looked at the related code briefly, and I can’t really figure out what part is creating those massive queries. Nobody’s figured out the scaling-with-size slowdown, but I’ve been trying to get an experiment up [here](https://forum.duplicati.com/t/backups-suddenly-taking-much-longer-to-complete/12994/10). You’re probably not in a measuring mood at the moment, but there were some tools watching the files. > [@dyc3](#): > > there’s no way to have duplicati resume the recreate process? I think not, but I don’t think anybody here can give absolute answer. There’s certainly [no specific option](https://duplicati.readthedocs.io/en/latest/04-using-duplicati-from-the-command-line/#the-repair-command). > [@dyc3](#): > > I have a partially recreated database from the previous attempt that is readable. So if you like, you can browse it, or if it’s in-place now, post a link to a [database bug report](https://duplicati.readthedocs.io/en/latest/03-using-the-graphical-user-interface/#creating-a-bug-report) along with the destination files counts so that maybe someone else can figure out if it got anywhere near end of create. I suppose you can give whatever you got a bit of a sanity check with the `Verify files` button which will download a few files and integrity-check the database. To maximize message catching, set up live log at Warning level or higher, and also see if any info is in job log or server log at About → Show log → Stored. --- _[View the full topic](https://forum.duplicati.com/t/need-help-resuming-local-database-repair/13050)._