The support forum

Renaming destination drive was a big mistake ? can't find the solution..

Apollo17 :

Oct 07, 2018

I use Bvckup for more than a year but I'm probably too stupid to find the solution in the options or even the forum. My problem is simple.
I backuped a full 8Tb drive named "EX" to a backup drive also named "EX".  So, G:\EX\ to H:\EX\  Worked perfectly, as always.

NOW, I changed the name of destination drive to "EX backup" instead of "EXE" I also changed that in the Bvckup process window. That was apparently not a good idea.... because when I pressed go, even though nothing had changed since the end of the (successful) backup... it started to copy everything again !....

I stopped, changed back the destination drive to the initial name, also in bvackup options, but still, although the two drives are identical to the kb. the software want to start again. It shows "Retrieving files", and bang start 172046 steps all over ! I'm dead... Only two questions :

- Can I do something to bring back bvckup to know it has indeed done a good job and no need to do it again (took me days to backup 8Tb) ?
- Are we stuck to keep the exact drive name (in the source or in the destination) forever once a backup job is done ? Or the same destination folder name ?

Sorry if it was covered before, I didn't find the solution in the forum. And very, very annoyed to have a perfect sync destination drive... that bvackup doesn't recognize anymore, even with the original name back.   Thanks a lot for your attention !

Apollo17 :

Oct 07, 2018

After more checking, the situation is clear, the two drives are identical to the kb, but bvckup just want to start all over again.
Being able to make bvckup recognize its perfect backup again would save me a week of 24/7 backup work. As for the drive name change, I suppose it wasn't something to do :-(

Alex Pankratov :

Oct 07, 2018



Can you please check for me the exact version you are running?

Renaming a drive will not trigger the re-copying. However it does trigger the re-querying of drive information, which includes timestamp resolution, which in turn - if queried incorrectly - may cause otherwise unmodified files to be re-backed up. And it so happens that 79.9 and 79.10 releases had a problem of exactly this kind. This was resolved in 79.11 as per [1], but you obviously need to be updated to that release to see the effect.

[1] https://bvckup2.com/support/forum/topic/1060/6175

Apollo17 :

Oct 07, 2018

Can't thank you enough to even read my post on a Sunday and try to help.
I had 79.10 now 79.11 but same issue.
When I initiate a backup, I have:
taking snapshot of the source volume, no errors
Preparing the backup plan, no errors, retrieving file IDs (171/776 !)
than it start copying... but also it says '1 error' not enough space (of course, since it ask for 7.7Tb again).
nothing is deleted though, I don't get how it could copy my stuff since, when I do a check from my Windows 8, both drives still have the same data size, files folders etc..  Is there a way to export the log options infos ?

Apollo17 :

Oct 07, 2018

BTW, to make this thread a bit useful to other (hopefully :-), are we allowed to change the name of source or destination folders (or both) or even change drives names between backups job without having my issue (losing the sync and apparently having to start all over again)  ?
Since the contents don't change and both source/dest. are still mirrors I thought the program would understand it and accept the modifications.

Alex Pankratov :

Oct 07, 2018


are we allowed to change the name of source or destination folders (or both) or even change drives names between backups job without having my issue (losing the sync and apparently having to start all over again)  ?


Yes, this is supported.

https://bvckup2.com/wip/06092016

Is there a way to export the log options infos ?


Right-click on the log entry and select "Copy block to clipboard"

... but same issue


Which issue is it exactly? If it's of needlessly re-copying otherwise unchanged files, then
(1) run the job
(2) let it get to the Processing stage
(3) pick one such file from the log - this will be "Updating xyz..." entry and use the above right-click-copy-block to extract the entry and all its children; then paste it here and I'll have a look
(4) you can then cancel the job by clicking on Stop twice

Apollo17 :

Oct 07, 2018


Thanks. I sent you my reply and the log to support@pipemetrics.com since it was off limit.  

Apollo17 :

Oct 08, 2018

To all interested on my issue, it is now solved thanks to Alex.
It was a problem with bvckup2’s view of the backup folder. By default it caches the index of the backup folder, so it would mean that somehow through all preceding troubled runs that index got out of sync with what’s actually on the disk.
I was instructed to force the program to rescan the backup by running the job with Go *while holding Ctrl down*.

It worked, and in 3 minutes everything was in order again. Ctrl-Go and Alex saved 8Tb of backup !

Apollo 17 signing-off.

New topic

Create
Made by Pipemetrics in Switzerland
Support

Follow
Blog / RSS
Social Twitter
Reddit
Miscellanea Press resources
Testimonials
Company
Imprint
Legal Terms
Privacy