The support forum

A Better Way To Scan A Remote

NARBS :

Apr 03, 2017

Hello,

I am probably using this wonderful program in a way that it was not originally or intentionally designed to be used.  I have outlying locations that I need to keep an up to date backup here locally to be spun off to tape archive.

Bvckup works wonderfully well in that it is doing this without any major issues.  I have checked and rechecked to make sure any changes are accurate, and I am confident in the programs abilities to do its job.

My minor issue is that scanning a remote either as the source or in one case the destination takes an exceptionally long time.  Here is the key lines from the log of a backup that just finished.
2017.04.02 22:31:06.683 (UTC-6) 2 0 Running the backup ...
2017.04.03 08:38:03.782 (UTC-6) 2 2 Deducing changes ...
2017.04.03 08:38:33.170 (UTC-6) 2 1 Processing ...
2017.04.03 08:46:59.788 (UTC-6) 2 1 Completed in 10 h 15 min with 2 errors
Note that the start to processing time is almost the entire time for this to run.

So, what I would like to know  - is there a way to run the scan on the remote side, and then transfer that result to Bvckup to then make the comparison for differences?

Alex Pankratov :

Apr 03, 2017

No, there's no way to do that.

The scanning module is already optimized to scan locations on network shares as quickly as possible (it does that by running several scans in parallel).

That said, your 10 hours of scanning time is extremely long. I don't think I've ever see anything like this before. What's on the other end and how large is the backup?

NARBS :

Apr 06, 2017

Bvckup2 is running on the Destination server, running Server 2012
The Source is an aging (close to 12 year old server) running Server 2003

That is the reason for running Bvckup; to keep a copy of the files from that server here for redundant backup.  There is a tape backup unit at the remote site; however, the server I am backing up runs the tape unit.

Until we can get a proper virtual environment set up there; I cannot create a VM to move the server data to.  So, this is a viable solution that works great; except the long scan time.

Speaking of, is there a way to stop the scanning of the destination and force the use of the last scan?  I ask this part because I have another install of Bvckup on a Server 2008 machine copying its data to a different remote location.  After a period of time, it rescans the destination; and that scan took over 12 hours.

Which means in two cases, one a source scan and the other a destination scan - both taking an extraordinary amount of time.

The backup itself is very quick, generally only taking twenty minutes or less.  Thus my question, is there a way to do a remote scan and then transfer that result file to the host running Bvckup for it to use?

Alex Pankratov :

Apr 10, 2017

Speaking of, is there a way to stop the scanning of the destination and force the use of the last scan?


No, not without some serious voodoo.

Tell me this though - how many cores are in your 2008 and 2012 servers? The number of cores is used as a basis for determining how many threads to use while scanning (and, yes, it shouldn't be doing that for _remote_ locations), so if your servers are single- or dual-cored, they won't actually do a parallel scan, but the regular sequential one.

We should have a maintenance release ready to go by the end of tomorrow and it will have this patched up - it will default to 8-thread scan for remote locations regardless of the local core count. This may help with your scan times... unless it's the 2003 machine that is hopelessly slow.

NARBS :

Apr 10, 2017

Local source on most machines would be multiple cores (XEON CPU for the physical ones).  At least one destination is a potentially a virtual and could be a single core.

The physical destination here at my site is dual XEON CPU with at least four cores each.  The oldest source server that is copying to this destination could be a single XEON CPU, it is at least nine years old and may only be a dual core.  It was never intended to still be in production this many years later, but it is what it is.

I will check back tomorrow and see if you have updated this with a notice stating the updated patched version is available for download.

Thank you.  You are as awesome with your support as your program is at functioning.  Although I have had some issues; those have almost entirely been because of the way I am having to use the program; which would be impossible for you to program in for every possible contingency.

New topic

Create
Made by Pipemetrics in Switzerland
Support


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

Legal Terms
Privacy