Constantly detecting changes?
Tekno Venus :
Aug 04, 2014
After purchasing and using Bvckup2 on my own computer for many months now, I decided to set it up on other computers. However, I'm having issues
I've set up a continuous backup of the User folder, excluding AppData and with an exclusion rule for *NTUSER* to prevent those files being backed up. However, Bvckup is constantly 'detecting changes' and then backing up. It apparently detects changes every 10 seconds, even though no changes have actually been made and the computer is just idling or browsing the web - nothing that should make any changes to the selected folders. This constant checking is preventing my external drive from going to sleep.
Looking at the log, it shows my suspicions - no changes have actually been made!
2014.08.04 21:06:28.977 (UTC+0) 2 1 No changes detected
2014.08.04 21:06:29.017 (UTC+0) 2 1 Completed in 347 ms with no errors
I can email you the full log if you desire, and anything else you need. Bvckup is running as a service, but the behaviour is the same if it's running in user mode. I've had to change to a 6 hour schedule for the time being, but I use continuous mode on my personal machine with no issues. Problem machine is Windows 7 SP1 x64.
Alex Pankratov :
Aug 04, 2014
This is actually an expected behavior. The reason for it is that the changes that trigger the run fall into the folders and files that are excluded from the backup.
I have explained before (and I can't seem to find that post now) that there are three principal ways to monitor filesys changes on Windows. First is to subscribe to the high-level "something changed in this tree" notifications, second is to subscribe to discrete "item Xyz changed" events and third is to parse NTFS change journal.
Third is not really the best option because the journal can be flushed with no notice and it requires admin privileges to read.
The problem with second is that the event queue is lossy, meaning that the system may start dropping events if there's too much going on. More importantly, it maps to an uncontrolled kernel memory usage. Imagine you just touched 100,000 files - now, you have a large chunk of memory allocated by the kernel to hold the notifications on behalf of the app, and the only way to flush it is to process notifications. And what if the app can't.
Long story short, Bvckup 2 uses the first method. It comes with some caveats and you have just experienced the most notable of them - false positive scans when excluded items are touched. What you can do is to trace what is touching files under \User and which files it touches exactly by using procmon from Microsoft (SysInternals) - http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
- at the very least you will get an idea what's constantly writing there.
Feel free to shoot me an email as well if you want to talk this over in private.
Tekno Venus :
Aug 15, 2014
Sorry, I completely forgot about this post! Thanks for the great explanation, that makes sense. I may leave it on a 6 hour schedule on that system anyway, I shall see over time how it is working. I'll dig around with Procmon (I am familiar with the tool) and see if it uncovers what's causing the changes and perhaps try and stop that.
Thanks for your help - I will be purchasing a license for that machine soon! Keep up the good work!
Aug 20, 2014
I've started to have the same problem, but in my case it seems to be Bvckup itself that causes it. I made the self-backup config file edit with the backup folder on a hard drive partition that I reserve for such things. Most of that partition is the subject of a Bvckup continuous back-up job (including the Bvckup back-up folder). I tried excluding the Bvckup back-up folder, but the problem persists, except that no changes are found. The only way to stop it is to delete the line from the config file, which is OK, but I have to remember to re-instate it temporarily if I make any changes to back-up jobs.
Alex Pankratov :
Aug 29, 2014
Indeed, that's Bvckup's own doing. It touches its configuration files quite often including updating them after each backup run to record run's stats. I guess what I can do is to make it write out the self-backup copy *only* if a job is modified from the UI. This way this copy won't have any recent stats, but then it won't be touched as often.