# 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:** 68

<div class="post-metadata">

**Author:** ![Sami\_Lehtinen](https://forum.duplicati.com/user_avatar/forum.duplicati.com/sami_lehtinen/32/1779_2.png) [@Sami\_Lehtinen](https://forum.duplicati.com/u/Sami_Lehtinen)\
**Post date:** [September 14, 2019, 1:42pm UTC](https://forum.duplicati.com/t/recreating-database-logic-understanding-issue-slow/6496/68 "2019-09-14T13:42:30Z")

</div>

I’ve got similar experiences about recreate and even the worst part of it, which is failure to recreate. But that story is in the different thread, but highly correlated with everything in this thread.

> [@Backup valid, but still unrestorable?](https://forum.duplicati.com/t/backup-valid-but-still-unrestorable/6441/9):
>
> Out of curiosity what back end are you using?

Personally I see that the only major fallback with current Duplicati. Slow rebuild would be acceptable in disaster recovery situations. But failure shouldn’t be an option.

Everything else is already working well enough that I’m happy about it. But this is the thing which make me sweat at night. Because I could just find any backup to be un-restorable at random after extremely slow database restore process. But I did see from some other thread that the rebuild / recreate task is being improved, which hopefully solves this issue.

---

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