2.0.3.9 Backups are still slow?


#1

Hi guys, I don’t know… all my backups seem slow since all versions after 2.0.3.5. I’m under the impression check-filetime-only is not working.

I am making a local disk to disk backup now. 100 Gigs, 100k files, no changes since last backup - which took 2 minutes. Now with 2.0.3.9, it is taking long… will see how long. 20 minutes?

Again I have to revert to 2.0.3.5 :frowning:

Also it says weird things like “1 Dateien (-10190233 bytes) to go”. Also I have seen “1 file (0 bytes) to go”.

EDIT: While it is running I can see, Sysinternals Process Explorer reports I/O of ~70 MByte Read (per second I guess) permanently on the Duplicati Process. So I think it reads whole files. Now that will take long.

Best regards
ms


#2

Thanks for the info.

The negative “bytes to go” issue with 2.0.3.9 is known, but not yet fixed.

As for the performance, I hadn’t heard anybody yet report that it’s apparently reading entire files even with --check-filetime-only enabled. I know there’s a “metadata not changed” issue floating around as well that might be related.

Hopefully we’ll find those are indeed related and can be resolved with a single fix.


#3

https://forum.duplicati.com/t/metadata-was-reported-as-not-changed-but-still-requires-being-added/3320/48 explained how the 2.0.3.6 rewrite caused --check-filetime-only to issue warnings and do full scanning of files, however the above note didn’t exist as of last comment here. Many prior suspicions expressed were right. :grin:


#4

@Tapio, version 2.0.3.10 has been released which seems to have fixed the “bytes to go” issue (among other things).

Some users are reporting slower backups, but there is now an environment variable that can be set to determine which algorithm is used that seems to speed things up for some users.


#5

Can you clarify what this is, how we set it, and what the pros/cons would be? As I’ve noted in 2 other threads so far, my main PC’s primary B2 backup job is now taking over 10x as long when the only change I’ve made was upgrading from 2.0.3.9 to 2.0.3.10.

Also - the link you posted for the 2.0.3.10 release thread appears to be either incorrect, deleted, or more private than my permission settings allow.


#6

Sorry, I’m not sure what happened there - but for the record (since you already know) 2.0.3.11 canary has now been released with some SQL tweaks that seem to be returning backup times to expected durations.


#7

@Tapio, please let us know if you upgraded to a newer version (like 2.0.3.11) and whether or not the performance improves.

If it does, I’ll mark that as the “Solution” to entice anybody hanging on to 2.0.3.9 for some reason to upgrade. :slight_smile:


#8

After a few tests I see performance is good as before. Probably solved. :slight_smile:


#9

Done. Sorry I picked my post afls the “solution” but it seemed the closest to a “do this” item. :slight_smile: