Cleve :
Jan 06, 2021
Alex,
I have something weird.
We have a backup folder witch contains Outlook Archives.
This folder is coped once in the night to our D: drive on the Bvckup server.
When we run our Job to copy from D:\Folder to Z:\Folder (Z is an NAS)
it will try to copy some files and if we re-run that one again it will still find changes on the file and subsequently copy that one again.
I checked the logging and strangely it shows that everything is the same but it still copy it.
Below is the exempt from our logging witch handles D: to Z:
2021.01.06 13:32:24.604 (UTC+1) 2 1 Processing...
2021.01.06 13:32:24.604 (UTC+1) 3 2 A total of 1 step, 2.39 GB to process
2021.01.06 13:32:24.604 (UTC+1) 3 3 Exactly 2562139136 bytes
2021.01.06 13:32:24.604 (UTC+1) 2 2 1. Updating file Archive-Gesmi-CLV.pst
2021.01.06 13:32:24.604 (UTC+1) 3 3 Details
2021.01.06 13:32:24.604 (UTC+1) 3 4 Source: 2.39 GB, created 2020.10.05 08:38:41.573, modified 2021.01.03 09:02:23.309, archive
2021.01.06 13:32:24.604 (UTC+1) 3 5 Raw: 2562139136 / 132463571215730156 / 132541345433099003 / 00000020 / 23b0046867c59c34
2021.01.06 13:32:24.604 (UTC+1) 3 4 Backup: 2.39 GB, created 2021.01.06 11:39:55.475, modified 2021.01.03 09:02:23.309, archive
2021.01.06 13:32:24.604 (UTC+1) 3 5 Raw: 2562139136 / 132544031954759101 / 132541345433099003 / 00000020 / 23b0046867c59c34
2021.01.06 13:34:45.151 (UTC+1) 3 3 Completed in 2 min 20 sec, copied in full
2021.01.06 13:34:45.151 (UTC+1) 3 4 17.38 MBps | 17.43 reading, 1289.89 writing | bulk mode
2021.01.06 13:34:45.339 (UTC+1) 2 1 Finishing up...
1
Alex Pankratov :
Jan 07, 2021
"Created" timestamps are not getting set correctly on the backup copies.
Source: ... created 2020.10.05 08:38:41.573, modified ... , archive
Backup: ... created 2021.01.06 11:39:55.475, modified ... , archive
The program automatically tests for the support of created timestamps, but it doesn't do it on every run. Instead, it caches the results and will re-query volume properties only when the volume serial changes.
You can see what it thinks volume properties are here -
2020.12.18 21:02:40 Running the backup...
2020.12.18 21:02:40 Preparing...
2020.12.18 21:02:44 Deducing changes...
2020.12.18 21:02:44 File system information
2020.12.18 21:02:44 Destination
2020.12.18 21:02:44 ...
I'd guess that the file system on your NAS volume was silently changed, that change dropped the "created" timestamp support, but the program had no way to learn about this. You can force it to re-query volume details by running the backup manually with Ctrl-Go. Holding Ctrl down forces Bvckup2 to flush all cached info (so it will also force a rescan of the destination folder even if the job is set to use file index snapshots).