The support forum

Source and destination are identical, but bvckup tries to update each file and copy it again

aliciamb :

Jul 21, 2021

Hi all,

Longtime user here (since 2017 no less!), but I've completely hit the wall.

I'm trying to use bvckup to synchronise my NAS drive to a standalone USB external drive, attached to my PC.

I have already copied all the files over manually, and when I test it with something like Free File Sync, it tells me that the files on each drive are identical and there are no anomalies.

However, when I set bvckup running, it performs the scan and then tells me it is 'Updating' every file individually, but rather than just updating the data, it transfers the whole file over again.

With 2tb+ to copy, the estimated time to complete 11 days.

Is it something to do with timestamps? I saw in the log that the NAS has 'Created Timestamps - NOT SUPPORTED' - but I really don't know what to do here.

Any help would be greatly appreciated.

Alex Pankratov :

Jul 22, 2021

This is most likely caused by NAS truncating or rounding up/down timestamps in an unusual way. The program includes fairly comprehensive logic for determining this sort of truncation automatically, but sometime it may be off. Also, there were several cases when a NAS update changed truncation logic, making it more coarse, but bvckup2 continued to use the original deduction.

Do this:

1. Look in the Processing section of the backup log and pick any file that is being pointlessly updated. Look at the details. They will show exact timestamps on the source and backup copies. See how far apart "modified" timestamps are.

2. Look in the Preparing section of the log > Deducing changes > Timestamp granularity > Modified. This will show how far apart timestamps can be before the program will consider them different.

If #1 is more than #2, then this is the problem.

To solve this, you will need to manually set timestamp granularity to an appropriate level. This is done by adding the following override to the job's configuration -

        conf.mtime_gran     20000000

Timestamps are measured in 1/10th of microsecond, so this value - 20,000,000 - stands for 2,000,000 microseconds or 2,000 milliseconds or 2 seconds. For your case you will obviously need to adjust it as required.

See for how to add an override.

aliciamb :

Jul 27, 2021

Hi Alex,

Thanks for getting back to me - much appreciated!
It took me a while to get back to sorting it out and I'm afraid I've made no progress.

Could you please look at the below screen cap of my log and let me know your thoughts?

This screencap was taken after I did another mirror copy using the software, and yet it seems that the modified timestamp on the NAS source is *after* the timestamp on the destination - and by a few hours no less (not microseconds).

Do you have any idea as to what is going on here?
Thanks again!

aliciamb :

Jul 27, 2021

Sorry, I should clarify - by mirror copy with software, I mean with the NAS software. There is an option to do a one off mirror copy backup.

aliciamb :

Jul 27, 2021

And a third time - wrong link :)
Here is the right one

aliciamb :

Jul 27, 2021

Hi Alex,

OK - so I did one more thing I hadn't done - which was create a whole new backup job from scratch and ran it again. I did this because I had checked the windows details of the files in question, and the modified timestamps were the same. So I figured somehow Bvckup was loading out of date timestamps from a previous loaded job.

So creating a brand new job from scratch fixed the problem. I'm not sure if it's a bug or not, but it seems that even when you run the job with newly modified files, it still somehow can load old data (?). Hope this helps for future updates. Thanks again.

Alex Pankratov :

Jul 28, 2021

Have a look at "Detecting changes" section in the settings of a backup job.

New topic

Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms