Welcome

# Beta Release 27

Alex Pankratov :

Aug 12, 2013

.

The mop-up release

1. Modified pre-/post-command launch to inherit and augment bvckup's environment rather than to start with an empty one.

2. Changed Filter Config window to re-populate default exclusions list when switching the backup from inclusive to exclusive mode.

3. Fixed several places in the app where text that included an ampersand was rendered incorrectly

4. Fixed the problem with updater creating a double-slashed path in the uninstaller registry entry (that caused the "uninstaller is missing" error when trying to uninstall the app from the Control Panel)

5. Modified code to cope with a large number of backup jobs. This has to do with internal event monitoring, which was previously limited to just 64 objects and therefore couldn't support more than that number of real-time backup jobs. New code can handle arbitrary number of jobs.

6. Fixed an issue with device monitoring code not getting started after switching app mode (to/from service).

MikeB :

Aug 12, 2013

Ref the update process itself .... I deliberately left BvckUp running job A (of two) when I asked it to update itself.  This it managed with complete dignity - but I noticed that it "cancelled" job A, and as soon as it was able to, started job B.

In my test scenario, job B will take ages and therefore Job A's work will be at risk until B completes. I can imagine that remembering the state of job A such as to be able to re-start it from where it had to be stopped is probably impractical (if not down-right dangerous for arbitrary updates). To me, however, it would seem to minimise the risk to continuity of protection if BVckUp were to remember that it had had to abort a specific job, and when updated run that job again from scratch - not go on to the next job in sequence.

Alex Pankratov :

Aug 12, 2013

Fair suggestion, will do, thanks.

highend :

Aug 12, 2013

This was the first time that I wanted to try it with real data...

Backup from: D:\
Backup to: T:\Backup
The destination is a mounted Truecrypt partition on an external hd

What to backup:
[*] Include Everything
On the root of the D:\ drive I deselected all current folders

T:\Backup already contains all backup files. SyncBackSE copied them all over.

What I expected:
All deselected folders aren't touched in any way and only all files on the root of the drive are copied to the destination.

What happened:
After the first scan of the destination Bvckup2 began to delete all files and folders inside the destination structure under all those deselected folders.

E.g.:
D:\Images (deselected)
Delete everything under
T:\Backup\Images

I "lost" about 60GB (of 600GB) on the destination drive before I stopped the backup task. The files on the source drive were still there and I used SyncBackSE to get everything back on the external drive.

Conclusion:
If I exclude a folder I expect that the backup task just ignores the content of it and doesn't try to delete anything from the destination...

Right / wrong?

enktesisllc :

Aug 12, 2013

Each revision gets better and better.

Just one question: How do I force the app to open minimized? It's seems to randomly choose to open or open minimized.

MikeB :

Aug 13, 2013

@highend ..... Which of the two settings for "how to scan" did you use for this experiment?

Alex Pankratov :

Aug 13, 2013

@highend

If I exclude a folder I expect that the backup task just ignores the content of it and doesn't try to delete anything from the destination...

Think of Bvckup as a cloning app rather than a file copier. Given the source and the destination it will always try and make destination look like a source. Filters shape the contents of source, but they don't change the fact that source is cloned to destination.

There's also a "How to delete" preference that affects the contents of destination, but it is merely a safeguard (by the way, those 60GB that got nuked in your case should be sitting in the $Archive folder at destination, intact). In the end, it all boils down to how the program works at the high level. What you assumed is reasonable (though there are few very hairy edge cases I can think of), but it's not what I coded :) Alex Pankratov : Aug 13, 2013 @enktesisllc How do I force the app to open minimized? Shutdown the program, add "start_minimized 1" without quotes to %LocalAppData%\Bvckup2\ui\bvckup2-ui.ini and restart the program. Alex Pankratov : Aug 13, 2013 @MikeB Which of the two settings for "how to scan" did you use for this experiment? Fair question, but be mindful of the following - cached snapshot is treated as an unreliable view of the destination. Specifically, it means that if during the backup the app encounters a discrepancy (e.g. file that it needs to delete being already missing), then it discards the snapshot and rescans the destination. highend : Aug 13, 2013 @MikeB "Snapshot of the destination from the last run" @Alex It's still a backup application and really: Disabled folders (in other words "excluded" from a backup job) should never be used to delete their destination counterpart. Just a simple example for a (relatively normal) backup plan: A few folders on the root of a drive. Two of them contain let's say 300 GB and take a lot of time because they contain virtual machine images (Hyper-V / VMware). They aren't backuped in realtime (unlike the other folders on that drive) so you need two different backup jobs. The first one excludes these two folders and includes the other ones. The second one excludes all other folders and only includes these two. From the experience I just got the first job would delete the contents of the vm image directories the second one of all other folders. I guess you see the problem. Ofc it's possible to use"Keep backup copies" but this is problematic because e.g. the snapshots for all the vm image files won't get deleted after getting backuped when they are destroyed on the source partition. Every snapshot of a VMware is as large as the assigned ram size for a vm... Alex Pankratov : Aug 13, 2013 @highend - I understand. This means that the backup needs to operate strictly off the source snapshot and assume that the destination is not being touched by anyone else. Or rather that *this* backup's parts at the destination aren't touched by others. Which translates into quite a bit of diligence that is required when arranging an access to the destination and setting things up. It is not a rocket science and it's fine by me and it's fine by you, but it is asking too much of less technical users. I'm not arguing against what you are saying, but do you see my point too? Let me sleep on this. I am already considering tagging some features as advanced and hiding them by default. First candidate is the "run as a service" and I can try and fit this "off the snapshot only" mode there as well. Meanwhile, the obvious work around is to point VM backup at \backup\scheduled and bacup the rest into \backup\real-time. Give each a directory of its own. Alex Pankratov : Aug 13, 2013 @highend, tell me this - Say, you are backing up "foo" folder from c:\temp to x:\temp and at some point you create c:\temp\foo\bar and drop a new file hola.txt there. Then the backup runs and it just happens that x:\temp\foo\bar already exists. How do you expect a backup program to react to this? highend : Aug 13, 2013 @Alex The first thing that came to my mind when I stumbled upon this problem was: Wouldn't it be an option to add a third state to the selection tree? Folder = not clicked (default state / green checkmark in front it) -> include this folder Folder = clicked once (e.g. orange circle) -> exclude folder (don't delete on destination!) Folder = clicked once again (red cross) -> exclude folder (and delete on destination) This would be a visible (and for the novice user) option to get around the problem. Regarding your question about what to do in this case: It depends and needs the user to set an option what he prefers. E.g.: 1. File on destination's last modified time = older than on source -> overwrite it 2. Same but vice versa 3. Ask the user what to do (only in non service mode) 4. Don't do anything but create a log entry (and create an environment variable to allow the postprocessing script to e.g. inform the user / take some actions) These are some of the options (just though about it for a minute). pgfitzgerald : Aug 13, 2013 FWIW, I have a similar situation. However, I just naturally went about it this way: Job 1 = D:\Users\pgfitzgerald\* -> E:\Backups\Data (Excluding Downloads and Virtual Machines) Real time Job 2 = D:\Users\pgfitzgerald\Downloads\* -> E:\Backups\Downloads Every 12 hours Job 3 = D:\Users\pgfitzgerald\Virtual Machines\* -> E:\Backups\Virtual Machines Every 24 hours I can see how one might want to do it the way highend describes, but doesn't Bvckup even go as far as to warn you the destination is non-empty when you try to set it up that way? highend : Aug 14, 2013 @pgfitzgerald Using different destination folders for every backup job is a workaround, indeed. Unfortunately I'm not a fan of such a structure because of one reason: Should your source drive ever fail and you have to restore everything you have to take care that you copy all those subfolders back to their correct location instead of just copying all over. Ofc this doesn't happen that often (I had two dead drives in the last 2 years (3 different PCs), so I had to restore everything twice) but I want to care about backup strategy in the first place not about proper restore actions when you get the worst case... Alex Pankratov : Aug 14, 2013 Good stuff. I'll reply in a few hours. Alex Pankratov : Aug 14, 2013 @highend - I like the idea with 3 states, and makes sense to me, but at the same time I'm pretty damn sure it will confuse the *hell* out of a lot of people. It is the cost/benefit thing. For every user like you and me who can potentially benefit from this flexibility, how many users will the app lose, because it would look too complicated for them? This and also the edge cases is what bothers me. The more intricate the logic, the larger the number of various odd cases that the app needs to handle and, more specifically, the more if-then-elses the UI needs to include to try and present all these situations in a sensible way. All in all, I really want to push the production release out first and then, leisurely lounging on a Caribbean beach under a gentle breeze, polish it to perfection. There's certainly a lot of practical sense in what you are saying, I just need to understand how to massage it into the app without scaring simpler users away. jrothlis : Aug 14, 2013 How about instead of the 3 states, you can configure the type of backup? Either a Mirror, which replicates deletions, or not a mirror, which just adds stuff to the backup without deleting anything. The default would be "not a mirror". From the Robocopy help: /PURGE :: delete dest files/dirs that no longer exist in source. /MIR :: MIRror a directory tree (equivalent to /E plus /PURGE). This is what /E does: /S :: copy Subdirectories, but not empty ones. /E :: copy subdirectories, including Empty ones. Alex, I would recommend going through all of Robocopy's help for inspiration of what would be useful features/settings (whether in the GUI or just in the INI). Alex Pankratov : Aug 14, 2013 Either a Mirror, which replicates deletions, or not a mirror, which just adds stuff to the backup without deleting anything. But this won't help with @highend's setup. I would recommend going through all of Robocopy's help for inspiration Ok, I'll have a closer look. highend : Aug 15, 2013 @Alex If a user runs away because he has 3 options instead of two... He would have run anyway. It's not about having options, it's about: a.) Presenting them in a meaningful way at the right place with enough information (tooltips, context sensitive help, etc.) b.) Setting good default values You should take a look at SyncBackSE (/Pro). It has hundreds of options (and most of them are configurable per backup). But apart from setting the name, type (backup, sync, mirror) and the source + destination folder(through a wizard!) you don't need to configure any additional options to let such a profile run "out of the box". I'm only missing one option: delta copy. That's the reason that I subscribed as a beta tester for bvckup. Cloud backups aren't funny without delta copy :( Btw, burying options in an .ini file isn't always a good thing. If you have a userbase of 20.000 and you implement a feature that makes sense but only 5 users requested it -> Use the .ini file. But for "major" options, always elevate them to the gui. I know that this doesn't couple with your actual setting implementation but when this app get's out of beta and more users will use a trial time, more and more users will request features and you'll struggle to stuff them into the gui. You want to keep settings simple. That's fine. But backing up things is a complex thing and does need a bunch of decisions to fulfill the user's requirements. Don't get me wrong Alex, I still like the look and the features of bvckup but it's still a rather long way to get out of beta stage (ofc only if you want to compete with all those long existing backup applications). Releasing an application that deletes your existing backup by default is a bad choice. I have to explain the last sentence. Most people want an easy to use backup application. Most people backup from the root of their drive(s). But I know lots of people who store stuff on their backup drives that they just moved over because they rarely use it and don't want to take space on their internal drives. E.g. photos from your holidays, video clips of your new born child, ... Bvckup can (by default) delete this stuff. If that stuff takes a few hundred gigabytes and the left space on such a drive is lower than that, the$Archive folder won't help you out...

I'm not complaining, atm it's still just a beta test.
Just my 2 cents.

Alex Pankratov :

Aug 15, 2013

@highend - Good stuff, digesting. Give me a day.

Alex Pankratov :

Sep 27, 2013

[ Six weeks later ]
Continued here - https://bvckup2.com/support/forum/topic/120

# New topic

Create
Made by IO Bureau in Switzerland
Support