Setup Help Block Copying

[dbadmin]

I am having a little trouble getting the block level copying working and I thought maybe if I tell you what I am trying to do you can tell me the correct way to set it up.

I have a bunch of VHDX files that are iSCSI backup targets. I would like to sync them from the server where they are on the local drive, to a QNAP NAS that will be located in another office. I would like to first "seed" the backups on the NAS while its in the main office as the VPN link it will have tops out at 30mbits.

What is the most optimal way to set this up? My idea was to setup the full software on the server that has the source files on the physical drive (Left side) and a VM on the NAS which would have the remote service monitoring a UNC path that's on the NAS itself where the files will sync (right side). Should that work ok?

So far in my testing I have been unable to get the block level to work normally, after the first sync, the next backup completes instantly and the log file indicates there's nothing to be done. Interestingly enough though, if I run a "test backup integrity" it will request the checksums, the remote service picks up on the file, finds the differences, and when its done the appropriate blocks are transferred. So at least in part something is working, I just am not sure what I am doing wrong.

Any help would be much appreciated.

[superflexible]

Hello,
the main problem is most likely that the timestamps for these files do not change even if their contents change. To override the timestamp check, please edit the profile and go to the tab sheet Comparison->More and choose "Always copy the files, even if timestamp unchanged".

Then the partial file updating (block level copying) will do its thing.

The seeding is another issue. If you use the remote service on the destination site, there are no special precautions you need to take, because the service calculates the checksums every time, on the fly. But that also means that the remote service needs to run on a Windows machine on the destination site with a very fast connection to the NAS, and this service will read in the complete VHDX files from the NAS every time for the backup in order to calculate the checksums.

If you don't want so much traffic on the destination site between the NAS and a PC, you could work without remote service. In that case, ideally, you would seed the files, then move the storage to the other site, making sure that the original VHDX files do not change during this time. Syncovery should then perform the first sync over the Internet without the VHDX files having been changed, so that it can recognize that these files are actually identical and save the checksums locally. After that run, the source files can be changed and only the changed blocks will be copied in the future.

[dbadmin]

Thanks for the help.

I thought about the time-stamp thing and I have indeed already tried that option but it did the same thing. I cant however remember what combination of settings I was using, so I have just started another test without using the remote service with the recommended settings and I will post back shortly as to the result.

As for the remote service, I was planning on running a VM with windows on the NAS box itself. This unit is one of those fancy newer NAS boxes that can run VM's as well as being a normal NAS. So the topology would look like this:

Windows Server (Local VHDX source)--->VPN--->Windows VM on NAS (Remote Service)--->NAS Share (Same physical box as VM)

Does that seem like it would be good?

[dbadmin]

I replicated my issue with the backup thinking that nothing changed. After the initial sync of the VHDX, if you mount that file on the destination to check the contents, then the next time you try try the backup it will finish instantly and do nothing. If however you mount that VHDX as read-only then everything will work on the next backup as expected. So that was a little lesson learned and an oddball situation but perhaps that info will help someone in the future.