Alex Pankratov :
Apr 19, 2017
Is there a mode I can put Bvckup2 in so that it very simply just copies data from a source to a destination, without having to take the time to perform a full scan of the source/destination and then building the ID's and creating the snapshots, etc?
Scanning of the source is needed regardless of how the copying is made (not just with bvckup2, but with any tool). The difference with Bvckup 2 is that it's done upfront and other tools like robocopy do it as they go, so it ends up intermixed with the actual copying.
Scanning of the destination can be suppressed by using destination snapshots, but still requires a single full scan. *However*, in the data migrating scenario the destination is likely to be empty, so there's not much to be optimized here.
File ID retrieval *can* be suppressed. IDs are used for more/rename detection, so setting Backup Settings > More Options > Move detection to OFF will do the trick. This is absolutely worth doing for one-off migration jobs as ID retrieval is an expensive operation.
Snapshot creating - saving destination snapshot is very cheap, literally milliseconds.
If you were referring to the *VSS* snapshot of the source volume, this can be suppressed by setting Backup Settings > More Options > Shadow Copying to Disable. However the default is "As needed" meaning that the snapshot won't be created unless the app runs into a locked file. If you don't have locked files during a migration, so there's no overhead, but if you do, you will want the shadow copying, so, again, not much can be optimized here.
I guess I'll ask, in summary, this way...we have two additional modes we would like to use this for (besides the normal sync mode): migration and fast copy.
For both cases you should get pretty close to what you are after using:
1. Manually run job
2. Use destination snapshot
3. Copy files in full
4. Disable move/rename detection
Running this sort of job will scan the source. On the first run it will scan the destination as well, but presumably it will be empty. It will then go straight to copying files to destination.
If the job aborts, the destination snapshot will capture the state of backup, so on the next run the app will only need to scan the source. As I explained the source is scanned regardless of how things are copied, but doing it upfront allows coalescing listing operation and doing them in parallel, so it's generally (much) faster.
The only edge case if the machine dies or the app itself gets killed/crashes. This will prevent a snapshot from being created (as it's saved after a run completes) and it will cause the app to do a destination scan on the next job run.
Now, all that said, I can see a point in having a simpler way to set this up. Let me see what we can do.