The support forum

Recently added files have null destination timestamp

amd20x6 :

Oct 07, 2017

Files created from yesterday (after the update to R78.7?) keep getting repeatedly backed up. Looking through the logs, it appears the affected files have null timestamps on the backup side.

Timestamps are valid in Windows Explorer for both source and destination files.

Pressing Ctrl+Go caused this to temporarily stop happening. But when any files are changed afterwards, the recopied files start to pile up again.

No effect from disabling antivirus on both sides.
Both filesystems remain online between runs.
Destination machine is also running Backblaze. Stopping its service doesn't help.

Machine with files to be backed up:
Windows 10 Professional 1703 / build 15063.632
NTFS filesystem, scanned for errors

Destination machine:
Windows 10 Professional 1703 / build 15063.632
NTFS filesystem on external USB drive, scanned for errors
Destination shared via standard Windows filesharing

A failed delta copy:
2017.10.07 08:12:27.099 (UTC-6) 2 2         554. Updating file Redacted\Path\To\VM.vhdx
2017.10.07 08:12:27.099 (UTC-6) 3 3             Details
2017.10.07 08:12:27.099 (UTC-6) 3 4                 Source: 4.75 GB, created  2017.10.06 20:29:38.807, modified  2017.10.06 23:47:03.656, archived
2017.10.07 08:12:27.099 (UTC-6) 3 5                     Raw: 5104467968 / 131518133788073257 / 131518252236569432 / 00000020
2017.10.07 08:12:27.099 (UTC-6) 3 4                 Backup: 4.75 GB, created  0000.00.00 00:00:00.000, modified  0000.00.00 00:00:00.000, archived
2017.10.07 08:12:27.099 (UTC-6) 3 5                     Raw: 5104467968 / 0 / 0 / 00000020
2017.10.07 08:12:27.099 (UTC-6) 3 3             Resetting the delta state...
2017.10.07 08:12:27.099 (UTC-6) 3 4                 Destination file timestamps have changed since the last run
2017.10.07 08:12:27.099 (UTC-6) 3 5                     Was: created  0000.00.00 00:00:00.000, modified  0000.00.00 00:00:00.000, 5104467968 bytes
2017.10.07 08:12:27.099 (UTC-6) 3 5                     Now: created  2017.10.06 21:52:59.302, modified  2017.10.06 23:47:03.656, 5104467968 bytes
2017.10.07 08:14:49.476 (UTC-6) 3 3             Performance
2017.10.07 08:14:49.476 (UTC-6) 3 4                 34.19 MBps / 35853974 bps, 2 min 22 sec
2017.10.07 08:14:49.476 (UTC-6) 3 3             Completed in 2 min 22 sec, copied in full

A failed normal copy:
2017.10.07 08:12:25.650 (UTC-6) 2 2         519. Updating file Other\Redacted\Path\To\file.txt
2017.10.07 08:12:25.650 (UTC-6) 3 3             Details
2017.10.07 08:12:25.650 (UTC-6) 3 4                 Source: 4305 bytes, created  2017.10.06 23:21:40.324, modified  2017.10.06 23:21:40.327, archived
2017.10.07 08:12:25.650 (UTC-6) 3 5                     Raw: 4305 / 131518237003248564 / 131518237003273557 / 00000020
2017.10.07 08:12:25.650 (UTC-6) 3 4                 Backup: 4305 bytes, created  0000.00.00 00:00:00.000, modified  0000.00.00 00:00:00.000, archived
2017.10.07 08:12:25.650 (UTC-6) 3 5                     Raw: 4305 / 0 / 0 / 00000020
2017.10.07 08:12:25.682 (UTC-6) 3 3             Performance
2017.10.07 08:12:25.682 (UTC-6) 3 4                 0.12 MBps / 124447 bps, 34 ms
2017.10.07 08:12:25.682 (UTC-6) 3 3             Completed in 32 ms, copied in full

---
Any ideas?

Thanks!

amd20x6 :

Oct 07, 2017

I am not 100% sure this started yesterday. I believe it likely did because none of the recopied files were created before then and the job was configured to use a destination snapshot.

The list of files to be repeatedly backed up survived multiple reboots until I tried Ctrl+Go.

Alex Pankratov :

Oct 07, 2017

Ok, a couple of things.

1. Please show me the "Preparing > Deducing changes > File system information" part from the Ctrl-Go run.

2. Please downgrade to https://bvckup2.com/files/bvckup2-setup-1.78.5.0.exe and see if the problem remains.

It might be easier to do this over email (support@pipemetrics.com) if you don't mind. I'll post the summary of our findings here once this is resolved.

##EDIT## -- whoops, pls downgrade to 1.78.5, not .6
(I edited the link just now).

Alex Pankratov :

Oct 07, 2017

Also:

3. I will need a copy of your %LocalAppData%\Bvckup2\bvckup2-fsi.log - this is a log of file system information ("fsi") discovery process.

4. What are you running in terms of the OS on your remote machine?

amd20x6 :

Oct 07, 2017

Alex,

Thanks for your quick response. I've sent the requested info and logs via email.

R78.5 has resolved the problem for me.

Thanks again!

Alex Pankratov :

Oct 08, 2017



Should be resolved with 78.8 -
https://bvckup2.com/support/forum/topic/973/5504  (top item)

amd20x6 :

Oct 08, 2017

I can confirm that R78.8 resolves this issue. Thanks for the quick resolution- and on a weekend!

dean :

Oct 09, 2017

This still seems to be an issue for me.

After the latest update, the backup job runs and tries to archive the entire backup directory and copy the files again.

I tried version 78.8 and I downgraded to 78.5 still same issue with both.

This is a problem because I don't have enough room for two entire backups. I also cannot afford to delete the backup and copy again since this will take a lot of time and there will be no backups during the copy... any options?

dean :

Oct 09, 2017

I believe the problem is that the backup modified the files the first time it run with the issue version.

Now each file has version in the name:
SOME FILE (2017-10-07, 21-40-37) (2017-10-09, 13-30-44).doc

I think the program sees this as not a match and tries to download the entire contents again. Is there a way to avid this? I really cannot afford to loose the backup and start from scratch.

Alex Pankratov :

Oct 09, 2017

I believe the problem is that the backup modified the files the first time it run with the issue version.


The issue was that the timestamps of backup copies was incorrectly recorded in the bvckup's own index of backup directory. The only side effect of this was that on each run the program thought these files were modified and re-updated them.

This does not involve deletion or archiving of existing backup copies **unless** you've put a manual override in as per [1] to also archive _modified_ files.

So I'm pretty sure your issue is unrelated to the one at the start of this topic.

Do you see any errors reported during the scanning phase?

Now each file has version in the name:

SOME FILE (2017-10-07, 21-40-37) (2017-10-09, 13-30-44).doc

Where exactly did you see this?

The "(date, time)" suffix is appended to the name of the backup copy when its original is deleted from the source and the backup copy is moved to the $Archive folder at the top of the backup location. You have this suffix appended *twice* - I can only guess that you have recovered this file from the $Archive, placed it back in the source tree and then it got deleted there again, triggering the second archival and yielding the second suffix. I can't think of a scenario when Bvckup 2 would end up doing something like this entirely on its own.

New topic

Create
Made by Pipemetrics in Switzerland
Support


Follow
Twitter
Dev blog
Miscellanea Press resources
Testimonials
On robocopy
Company
Imprint

Legal Terms
Privacy