The support forum

Seeding a Back UP to a Synology

stosht :

Jun 11, 2019

Hello,

I've got an external drive that I've ran a Bvckup 2 backup task to. After finishing this backup, I've moved it to an offsite location on a synology which I have VPN access to.

Upon adjusting the backup job to reflect the drive's new location, I'm asked if I want to reset the delta state, to which I say no. When I start the backup job, it scans both the source AND destination (even though I have "use destination snapshot" active).

This wouldn't be a problem except upon scanning the destination, Bvkcup sees every single file as needing to be updated. When I look what's being updated, it's the "Date Created", "Date Modified", and "Attributes". On some files this update is fast, but on others Bvckup will copy the entire file, which seems strange just for date differences.

The date differences are also very small. For instance on a particular source file, I have the date modified as: 2015.10.27 23:34:31.674. The Destination file is read as: 2015.10.27 23:34:32.999. In fact, every destination file seems to end in ".999".

I've successfully done this same procedure over the same VPN to an off site Windows machine without this issue, so something tells me the Synology is doing something funny to these files attributes . Does anyone have any ideas for a fix/work-around?


Now that I've typed all of this I did a quick search for "Synology" on the forums and found what seems to be the same issue I have:

https://bvckup2.com/support/forum/topic/762

Though this was in 2016. Any new info since then? If Synology hasn't changed since then, it seems like the way around this would be to have Bvckup 2 NOT rescan the destination upon a path change. Obviously this would have to be decided by the user on a case by case basis. Or maybe I'm over-simplifying this ;)

Interested to hear if anyone has figured anything out for this.

stosht :

Jun 11, 2019

FWIW, I've manually adjusted the granularity to 2 seconds per:

https://bvckup2.com/support/forum/topic/282

The backup job is now performing as expected.

Alex Pankratov :

Jun 11, 2019



Hmm, interesting. The program automatically tests both source and backup devices to determine their effective timestamp granularity and then uses this info to do "fuzzy" (ranged) comparison of file timestamps when determining if they changed or not.

Moreover, there's a piece of code that specifically takes care of Synology producing timestamps with 999 ms.

So, in theory, it should've all worked right out of the box for you. I wonder why it didn't.

Can you show me this part of the log from the first run after you switched the job to use Synology? Either here or by email to support@pipemetrics.com.

    2019.06.11 14:24:46   Running the backup ...
    2019.06.11 14:24:46       Preparing ...
    2019.06.11 14:24:51           Deducing changes ...
    2019.06.11 14:24:51               File system information
    2019.06.11 14:24:51                   Source
    2019.06.11 14:24:51                       ...
    2019.06.11 14:24:51                   Destination
    2019.06.11 14:24:51                       ...

Re: these bits -

Upon adjusting the backup job to reflect the drive's new location, I'm asked if I want to reset the delta state, to which I say no.


Correct, precisely this.

When I start the backup job, it scans both the source AND destination (even though I have "use destination snapshot" active).


Snapshot is discarded when the path is changed. This is by design. Also, changing the path forces the re-testing of the devices, including their timestamp resolutions. Hence my question above.

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