The support forum

"Created" timestamps

Aug 28, 2019


Bvckup 2 will schedule an existing backup copy of a file for _updating_ when it deems it out of sync with the source. It does that by looking at a triplet of "created" timestamp, "last modified" timestamp and file size. If any part of the triplet is different between the source and backup copies, the file will be updated.

Between these three properties, the "created" timestamp is an odd one out, because quite a few non-Windows storage devices simply don't support it.

Aug 28, 2019

Detecting support for "created" timestamps

Bvckup 2 tests for the created-time support automatically and it will adjust its comparison logic if no support for it is detected. It will also log this in the following section of the backup log:

    2019.08.28 11:15:00   Running the backup ...
    2019.08.28 11:15:00     Preparing ...
    2019.08.28 11:15:04       Deducing changes ...
    2019.08.28 11:15:04         File system information
    2019.08.28 11:15:04           Destination
    2019.08.28 11:15:04             Created timestamps : supported           <<<

Additionally, program's final decision to use or not to use c-time for change detection will be logged in this section:

    2019.08.28 11:15:00   Running the backup ...
    2019.08.28 11:15:00      Preparing ...
    2019.08.28 11:15:04         Deducing changes ...
    2019.08.28 11:15:04            Preparing backup plan ...
    2019.08.28 11:15:04              Planner setup
    2019.08.28 11:15:04                Created timestamps: compare and update
The file system information is cached between the runs, i.e. it is NOT re-queried every time a backup is run. This info is automatically queried on the first run and when the backup is reconfigured to use a different storage device.

The program can be told to re-query this information by starting the backup manually using Go while holding the Ctrl button down.

HOWEVER note that this will also discard all other cached information, including the file index of the backup (a.k.a. "destination snapshot") and will cause the backup file index to be rebuild. For larger backups, especially residing on slower and/or network devices, this may translate into a longer running time.

Aug 28, 2019

Suppressing the use of "created" timestamps

In certain cases it may be desirable to not use "created" timestamps for change detection even if they are fully supported by both the source and backup devices.

This is done by adding the following override to the job's configuration:

        conf.ctime_match  1

See for how to do this.

Verifying the override

Once the override is in, the job is reloaded and re-run, you should see the following in the log:

    2019.08.28 15:02:13   Running the backup ...
    2019.08.28 15:02:13     Preparing ...
    2019.08.28 15:02:17       Deducing changes ...
    2019.08.28 15:02:17         Preparing backup plan ...
    2019.08.28 15:02:17           Planner setup
    2019.08.28 15:02:17             Created timestamps: don't compare, but update

The "don't compare" bit in the last line confirms that the planner won't schedule the update for files that differ only in created timestamps.

New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms