1

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.

2

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 https://bvckup2.com/support/forum/topic/1140 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.