You are correct Frog, it is 68 Beta. Thanks for the info, will check it out. Update to post. I looked over the versions, and truthfully, a lot of the stuff added , I don't need and would probably not use. I just don't like using a program as a "moocher" (using the free Beta) when the developer is putting so much work in on a project. Guess that is a foolish attitude but I was raised that way. Maybe I can make a donation....
@angstrom made that BETA available for FREE (and it works very well, by the way), mainly as a gift to his v1 users and as a tease for, hopefully, future v2 subscribers... there should be no need to feel bad about using it (just remember, there's no mainline support for the BETA). If all you need is a simple file replicator, it works very well.
Thanks! I contacted Bvackup by email and got a very nice reply from Alex Pankratov indicating it is fine to use 68Beta for free - he hopes I will tell others about Bvckup 2,which I will for sure. I just went ahead and upgraded to the latest version, just to support Alex and get the extra features and speed in doing so. Great support from him and a great program.
Bvckup 2 v79.10 Released (September 26, 2018) Website / Download: https://bvckup2.com/update Release Notes
Bvckup 2 v79.11 Released (October 02, 2018) Website / Download: https://bvckup2.com/update Release Notes
I have "Options > Preferences > Check for updates and notify if one is available" selected. But it never does. I always have to go Help > Check for updates. I only just updated it via the Help > Check for updates method now because I saw the above October 3 post.
Bvckup 2 v79.12 Released (October 21, 2018) Website / Download: https://bvckup2.com/update Release Notes Spoiler: Changelog v79.12 Release 79.12 ⦁ Fixed an issue with querying destination file system and device information. In some cases the program would try and do it before backup folder is created, logging one or two errors as a result of that. Operationally this made little difference in the vast majority of cases, but it was still a bug, so fixed. ⦁ Fixed an issue with erroneous "Login required" failures after a successful authenticated connection to a publicly inaccessible share. That is, if you were backing up to/from a share that _required_ an authentication and that wasn't accessible otherwise, then on the first backup run the program would successfully connect to the share (using credentials supplied), but then it would bail out erroneously thinking that it still didn't have a connection. ⦁ Fixed an issue with redrawing pushpin icons in the Backup To/From fields in the Backup Settings dialog when collapsing "More section" of the window. In some cases there would be some junk drawn in place of the icons, because the latter weren't re-drawn after the window was transformed. ⦁ Fixed an issue with copying progress bar variable precision %-age display. It's a mouthful for this - when copying larger files, the UI will show the progress bar and the %-age done so far. Depending on the copying speed and size of file, the percentage may show one or more decimal places (up to 3) to make sure there _is_ some non-trivial activity shown even for slow-going copies. The issue was that this bit was broken in recent releases and the UI always showed no decimals. ⦁ Added retrying on "VSS is busy" condition when creating a source volume snapshot. The context is this - Shadow Copying service may refuse creating a volume snapshot if another snapshot is being created at the very same moment. This is an inherently retryable situation, so this release adds just that - the engine will now retry up to 10 times 30 seconds apart when running into this condition. Retry parameters are configurable through the INI. Retrying is enabled only when "More Options" > "Shadow Copying" is set to "Require", and not for the "As needed" setting. ⦁ Speeded up saving of destination snapshots at the end of a backup. ⦁ Suppressed logging of deduplicated files during the scanning phase. These were logged because dedup'd files are reparse points and RPs were unconditionally logged before this change. ⦁ Suppressed complaints about deprecated INI entries when upgrading from pre-78 releases.
This VSS "Delay" is always been something of an issue for me with Tweaking.com Registry BackUp. Something about that service never bothered investigating in-depth but takes over 2:45 seconds if not longer to kick in and begin shadow copying registry files. Not trying to swing OT but seems Bvckup 2 also (as described) has experienced some issue. It's not the program(s) trying to access but VSS working some other activity when triggered at times. Kudos to Dev. for addressing with that provision to allow for the thing to kick in when it's in a condition of delay or other.
The retrying mechanism handles "VSS is busy making another snapshot" error only (VSS_E_SNAPSHOT_SET_IN_PROGRESS). It won't retry on any other errors or timeouts.
Thank You @angstrom. Great application and effort bringing it up and along while ironing out situations that come to attention.
Hello @angstrom since today I've been unable to connect your site. Is there any reason you banned my ip and computer from access? TIA
We blacklist IPs that poke around wrong parts of the website or doing stuff that no normal users should be doing. Especially if when these are Tor or VPN exits. PM me your license ID and the IP address and I'll have a look as time permits.
@angstrom No, I won't provide you anything as I consider I am/was not doing or "poking around wrong parts of the website or doing not normal stuff". If browsing the forums the way I do is considered a menace, or an improper behavior then I shall not go back to your site anymore, I won't lose sleep over it. Have a nice day.
Sounds like a false positive, which @angstrom is trying to correct. Perhaps consider taking his offer of help
I agree, Seeker - good suggestion. With all that's happening now in the US, it is good for us all to make an effort to get along with the people these forums. They are usually trying to help us. I appreciate all the help I have received in here and try to not make any comments that upset others or take comments others make to me as personal. I will try not be too aggressive or too thin-skinned, I promise.
Bvckup 2 v79.13 Released (October 30, 2018) Website / Download: https://bvckup2.com/update Release Notes Spoiler: Changelog v79.13 Release 79.13 ⦁ Added support for pre-computing delta state of existing backups https://bvckup2.com/wip/30102018 https://bvckup2.com/support/forum/topic/1131 ⦁ Added support for displaying absolute next-run times in the UI https://bvckup2.com/wip/29102018 ⦁ Changed the layout of About window a bit. ⦁ "Switch mode" menu option is now shown by default on Windows Server installations. ⦁ "Backup everything" option from the tray menu now does NOT apply to disabled jobs. ⦁ Fixed tabbing order in the Backup Settings window. ⦁ Fixed Ctrl-A support in edit boxes.
Bvckup 2 v79.13.1 Released (November 1, 2018) Website / Download: https://bvckup2.com/update - no changelog availabe -
Sometimes I feel like such a dunce. I am trying to determine whether Archive of Deleted Items Folders are limited in any way - either by date or size or something else and I can't seem to find the answer. Do they just continue to grow without ever being limited? Appreciate any input about this which will straighten out my feeble mind. Thanks.
<right-click>Adjust backup settings/Deleting/Archive backup copies/Edit details You can turn on an option to control how long they stay around or deselect that option (DEFAULT) to keep them forever...
Bvckup 2 v79.14 Released (November 7, 2018) Website / Download: https://bvckup2.com/update Release Notes Spoiler: Changelog v79.14 Release 79.14 ⦁ Fixed cosmetic issue with fading transitions in the UI, i.e. reworked code to eliminate occasional flicker during fade-ins and fade-outs. ⦁ Fixed an issue with the UI not showing changes in backup state. The issue surfaced when running without Administrator privileges. About 20 minutes after launching the program the UI would stop receiving updates from the engine, so while you could start a job with Go and it would execute, the UI wouldn't actually show any job progress. Another symptom was that when an activation code was used to license an installation, the UI would confirm the activation going through, but then keep on saying that the program was still in trial mode. That too was due to the UI not receiving respective updates from the engine. # Kudos to Andy, Lanka, Michael and John for helping with reporting and tracking down this issue. For those on their coffee break, here's some light reading as to Why this was happening. The post-mortem The cause of the issue was a trivial mistake in the code that tried reading some VSS-related information without first checking that VSS was available. This led to an "Access denied" fault, which should, under normal circumstances, trigger a crash. So it should've been a really visible issue that would've been caught in testing on the first pass. However in this case the code in question was in a callback set with SetTimer() function. When the top-level UI code called DispatchMessage(), the control went to user32.dll, which issued the callback, the callback ran that code and the code crashed. You'd think what difference does it make, a crash is a crash... Yes, exactly. Welcome to the club. Apparently, callbacks issued by SetTimer() are framed by a pair of RtlActivateActivationContextUnsafeFast() and RtlDeactivateActivationContextUnsafeFast() calls, which set up and tear down their own SEH handler. So the timer callback code can crash all it wants and you'll be none the wiser. Here's a sample code - https://gist.github.com/apankrat/ce6d15e5a6aac681257257ad5809ca9b So what happened in Bvckup's case is that it would receive a timer callback, which will run its internal event loop. The loop will dispatch event handlers and one of them will throw a SEH exception, which will be promptly eaten by user32.dll instead of being passed up to the UI for reporting. This left the UI thinking that its event loop was still active, so on the next timer callback the UI would see that the loop is still busy and it would skip running it - hence completely stalling the event processing, including the reception of the updates from the engine. Long story short - set your exception handlers for all your callbacks from Windows API or end up seeing your code behave in a way that makes no sense whatsoever.
