The support forum

Created file timestamps not supported by destination

dolaner :

Sep 08, 2015

I am currently synchronizing/backing-up to a CIFS share on a NetApp filer which has been going great.  I now am moving my backup target to a new volume and have already copied all of the data from the old volume to the new volume.  I was hoping that I could just switch the target for by Bvckup2 job and pickup where I left off but Bvckup2 wants to resync/re-backup all files due to the created date/time needing to be updated.  With over a million files across a slow link this will takes weeks and I obviously would like to avoid it.  When I reviewed logs I found that Bvckup2 is stating 'Destination does not support "created" file timestamps'.  I have verified that over CIFS I can indeed set file created timestamps on files in my backup target.  Ideally I would like Bvckup2 to be copying file/folder created timestamps but at the very least I would like to avoid updating all files when  I switch the backup to the new target location.

-Is there any way to manipulate the logic for deciding if a backup target supports created timestamps?
-Is there any way to force Bvckup2 to copy created time-stamps?
-Is there any way to make Bvckup2 not update all file created timestamps on it's initial run when copying to my new target location?

dolaner :

Sep 08, 2015

Some additional information - I have noticed that bckup2-fsi.log only contains information relating to the source and not the destination.  The relevant section from the logs relating to what the destination supports is shown below.  Interestingly if I set the source to be a CIFS share on my NetApp filer it enumerates what is supported by the CIFS share and this is also shown below.  I also found that I can disable ctime checks via "conf.ctime_match" but I would really prefer to be copying the ctimes over as well so this is not an ideal solution for me.

-=DESTINATION ON FILER=-
2015.09.07 18:51:39.650 (UTC-6) 3 4                 Destination
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Device : remote, over unspecified protocol
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Type :
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Created timestamps : ?
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Modified granularity : unavailable
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Supported attributes : read-only, hidden, system, archive
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Maximum file size : unknown
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Volume : flags 00000000, serial FFFFFFFF

-=SOURCE ON FILER=-
2015.09.07 18:51:39.650 (UTC-6) 3 4                 Source
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Device : remote, over unspecified protocol
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Type : NTFS
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Created timestamps : supported
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Created granularity : 100 ns  ( 100 ns probed, 100 ns deduced )
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Modified granularity : 100 ns  ( 100 ns probed, 100 ns deduced )
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Supported attributes : read-only, hidden, system, archive
2015.09.07 18:51:39.650 (UTC-6) 3 5                     Volume : flags 000400CF, serial 80000421

Alex Pankratov :

Sep 08, 2015

Alright, so the answer to your principal question on avoiding mass re-copying is that you simply need to create a new backup job and point it at existing source and new backup folder (the one you pre-populated with file from the old volume).

First backup run is special in a sense that it doesn't compare created times on files when deciding if two files (one at source, one at destination) are a match. It will update them to match though if they are different.

This is done specifically for the case of taking over a backup that was done through standard copying from A to B. Such copying preserves "modified" timestamps, but resets "created" ones.

So what you will see is that the app will update all your files, but it will update *timestamps* only. This is generally a very quick operation, so just don't panic when you see 1,000,000 steps being planned for the first run. If in doubt - run the simulation first through right-click Command menu.

-- Secondly --

To make the app re-query file system parameters, make your way to settings.ini and nuke all entries starting with "filesys." - these are the cached values of file system properties. If these aren't found on the next backup run, the app will re-query them from the device.

Alternatively, you can run the backup with Ctrl-Go and it will force the app to flush all cached information, including the file system information.

-- ctime_match --

conf.ctime_match controls whether ctimes are used for change detection. Value of 2 means "match", everything else means "don't".

*Copying* of ctimes is controlled by "ctime" entry in "conf.copy_extras" variable, but it will still be suppressed if the app thinks that ctimes aren't supported by either source or destination file system (as it does in your case).

This is also possible to override, though it's a bit more involved and I'd rather resolve this matter properly - i.e. by making the app recognize that ctimes *are* supported by your new filer.

--

To go over the questions:

-Is there any way to manipulate the logic for deciding if a backup target supports created timestamps?


It is possible, but this opens its own can of worms (see above).

-Is there any way to force Bvckup2 to copy created time-stamps?


Not if it thinks that they are not supported by source *or* destination.

-Is there any way to make Bvckup2 not update all file created timestamps on it's initial run when copying to my new target location?


You can suppress copying of created timestamps, but it should be a persistent setting, because once it's removed, the app will want to copy them on the next run.

dolaner :

Sep 09, 2015

I created a new job but am still receiving the message 'Destination does not support "created" file timestamps'.  I am able to modify create file timestamps using software such as NirSoft BulkFileChanger.  Any thoughts on where to take it next?  I am happy to provide any logs you may need.

It might be worth noting that I am running the software in service mode with the service running as a specific Active Directory user.  This user is a local administrator on the target device and is a member of both the "Administrators" and "Backup Operators" groups on the local server.

BTW - I don't think I have ever received such a nuanced response to a support related question =)

Alex Pankratov :

Sep 09, 2015

Alright, so

(a) please forward me your bvckup2-fsi.log (to support@pipemetrics.com)

(b) the way created timestamp support is tested is that the app simply creates a temporary file at destination, queries its timestamps, subtracts 100 seconds from created timestamp, 200 - from modified, sets them on the file, reads them back again and checks if the created timestamp is the same as just set. In your case it isn't.

(c) App's run-time disposition (i.e. being in service mode) makes no difference here.

(d) I'll take a question that needs a nuanced technical response over simpler query at any time. At the very least this looks like a two-way conversation :)

dolaner :

Sep 09, 2015

I sent over the log files which appear to only contain source volume information.

Alex Pankratov :

Sep 15, 2015

This should be resolved with 74.18 release - https://bvckup2.com/support/forum/topic/598/3728

dolaner :

Sep 16, 2015

I can confirm that this issue is now fixed.

This is the first time I have reported an issue in software that I have paid for and had the issue fixed.  Almost unbelievably in just a weeks time.  Thank you for your assistance Alex, our company will continue to use this software and will be purchasing some additional licenses shortly.

Alex Pankratov :

Sep 17, 2015

What can I say... It was a interesting bug :)

New topic

Create
Made by IO Bureau in Switzerland
Support

Updates
Blog / RSS
Follow Twitter
Reddit
Miscellanea Press kit
Testimonials
Company Imprint

Legal Terms
Privacy