The support forum

Backup operator privileges

consonaut :

Aug 31, 2015

I'm trying to do a nightly sync of a roaming profiles and a home directory share. Since those shares are hosted on Windows Server 2008 I can't use VSS over SMB.

Even though we are following the "best practice" permission advice from Microsoft it seems that bvckup has an issue with the profile folders. If I run a robocopy job with "/B" it works though.

Any chance bvckup could get an option to use the backup operator privileges?

Alex Pankratov :

Sep 01, 2015

Good catch. The app actually grabs backup privileges, but it used them only for copying ACLs and such, but not when copying files.

I've rectified this just now - next maintenance release will default to /B equivalent when the app has backup privileges, with an option to override this behavior if needed. The release should be out in an hour or two.

Alex Pankratov :

Sep 01, 2015

PS. Nice username.

consonaut :

Sep 02, 2015

Thanks a lot. For now I was kicking off a robocopy job at the end of the other sync jobs but robocopy performance is pretty bad, taking 3 to 4 times as long as the same job with bvckup.

Thanks again for the quick implementation, I'll update later today and will try it on tonights run.

Alex Pankratov :

Sep 02, 2015

Ok, great. Let me know how it goes.

consonaut :

Sep 03, 2015

The files get created fine but now I'm getting quite a few "Copying Attributes; Access Denied; Function:GetFileSecurtiy" errors.

I'll check the integrity of the files content later.

Alex Pankratov :

Sep 03, 2015

Argh... you are right, of course.

There are several ways to get/set security information for a file and the app currently uses one that takes file *name* as an ID. This works locally when the process grabs the SeBackup privilege. However there's a more generic way to do it - by an open file *handle*, the one created with "backup semantics", the /B in robocopy terms. Let me look into this quickly and see what it would take to change this part.

Alex Pankratov :

Sep 03, 2015

Alright, so there's a simple fix and there's a proper fix.

Former will result in each source and destination file getting open twice. It's easy to do, but it will slow down the copying of smaller files.

Latter will do both the data and security info copying in one sitting, but it requires a bit of the rework of the app's insides. The nuance here is that the app needs to retry opening file just for data copying if it cannot open it for copying both. This is to ensure that the data gets backed up, even if the secondary attributes cannot be copied.

In any case, I'm going to fix this properly, meaning that it'll be done Monday or thereabouts.

consonaut :

Sep 03, 2015

Thanks for looking into it. For me, I'd much prefer the proper fix even if it takes some time, since performance is actually a big concern.

I'll check back for an update on Monday, don't let me ruin your weekend though ;-)

Alex Pankratov :

Sep 08, 2015

Done with the changes, will be running regression tests tomorrow and if all goes well, the update will go out tomorrow as well.

Alex Pankratov :

Sep 10, 2015

Ok, update's out. Please give it a try when you get a chance.

consonaut :

Sep 10, 2015

Updating right now. I'll get back to you tonight or tomorrow morning, when I had the chance to do a test run.

consonaut :

Sep 11, 2015

Worked like a charm.

The only errors I have left now are with folders users are getting from 3rd party Mac users that show on NTFS volumes as encrypted.

But aside from teaching my users to remove the encryption via folder properties, there is probably not a lot that can be done about that.

Alex Pankratov :

Sep 13, 2015

Excellent, thanks for the follow-up.

New topic

Create
Made by IO Bureau in Switzerland
Support

Updates Newsletter
Blog & RSS
Follow Twitter
Reddit
Miscellanea Press kit
Testimonials
Company Imprint

Legal Terms
Privacy