This is a two-part post. Read Part 1 here
It's important to protect business data. Employee access and use of data should be managed by the IT department. But a contractor is often entrusted with data on their own computers. We certainly don't want our laptop to be stolen and have to tell the client that source code or databases with sensitive data just got lost, and, no, it wasn't encrypted.
In Part 1, I discussed how I used VeraCrypt for my encryption. Below is how I solved problems relating to Google Backup and Sync, and Microsoft SQL Server.
The Trouble with Google Backup and Sync (the application formerly known as Google Drive)
I use Google Drive's desktop application to synchronize client files as well as personal. I think that's reasonable, since I can and should expect Google to be secure. Now that I have my test.vc file mounted as F, it's outside of the local Google folder. How do I get it into Drive?
If you're still using the Drive application, one way is to use a symbolic link, which I won't go into here. I've done this for other folders, but didn't want or need to in this case. The reason is that Google has replaced the Drive app with Backup and Sync. Backup and Sync allows backing up any folder on my computer, including other drive letters.
The computer is then available on the web version of Drive (but not the Android app, yet, why not???).
Great! So, what's the problem? Well, Backup and Sync is by default configured to run on login, which makes sense. I like to configure VeraCrypt to run on login, too. The problem is, by the time I get my password entered and the file mounted, Backup and Sync is already reporting that the F drive is unavailable, do I want to stop syncing the F drive? (no)...and the only thing I can do is restart Backup and Sync.
There's a simple solution to this that I wish had worked out for me. It will for most people. A VeraCrypt drive can be configured to act as a Removable drive. And Backup and Sync will be notified if a removable drive comes back online.
Let's show that. In Backup and Sync, stop backing up the F drive. In VeraCrypt, select the F drive and Dismount.
Now, select test.fc and click Mount again, but before submitting the password click Mount Options.
In the options, check "Mount volume as removable medium" and finish mounting the volume.
The F drive will now show as a Removable drive, just as if you'd plugged in a USB external or flash drive.
You might also be prompted to start backing up the USB device. Choose Not Now.
Let's prove we can unmount and remount without restarting Backup and Sync.
In Backup and Sync Preferences, choose to backup the F drive. Let the drive finish syncing (this might take a while, the app likes to reprocess everything). Then, in VeraCrypt, dismount it. You'll get a warning message. Don't take any action.
Now remount the F drive, making sure you set it as removable in the options. Backup and Sync will see the drive is reconnected, and start syncing it.
This is great, and I thought I was finished. If you don't run SQL Server, you probably are, but....
The Strangeness of SQL Server (or a VeraCrypt Bug?)
I develop using SQL Server Express. The SQL service runs automatically at start up and attempts to start any configured databases. See where this is leading?
If I put database files in my F drive, they won't be available to SQL Server on startup and the database will be marked as "Pending", meaning it can't be started. I'd have to restart the SQL service.
There's a solution, but first, what happens if I try to create a SQL database on my removable F drive? Create a "Data" folder first.
Research this error and everyone says it's a permissions problem. I labored for hours under that belief, trying various correct-but-not-successful permissions settings.
Close the error. Pause Backup and Sync. Dismount the F drive, remount it without making it removable. Try creating the Test database again.
Yep, it works fine. What gives? Maybe SQL Server doesn't like installing databases on removable media? That's not the case. It's supported, and I was able to create a database just fine on a USB drive I plugged in.
No, the problem appears to be with VeraCrypt and how it configures itself as a removable drive. I haven't looked into this, though.
This means I can't configure my VeraCrypt drive as removable, which screws up my Backup and Sync solution, above.
Fight, Fight, Schedule Tasks!
It seems like I can't have what I want, which is to start my computer, log in, mount my encrypted drive, and not have to fuss with either Backup and Sync or SQL Server. But I can.
Here's my solution.
- Set my encrypted volume back to regular (not removable).
- Turn off both Backup and Sync and SQL Server from automatically starting
- Use Windows Task Scheduler to delay-start them when I log in, giving me time to mount the encrypted container.
Backup and Sync Task
In Backup and Sync's Preferences > Settings, turn off "Open Backup and Sync on system startup".
Next, open Task Scheduler. Select the Task Scheduler Library, and choose Create Task. Here are the settings. Notice the "log on" trigger, and the one minute delayed start.
SQL Server Task
Open Services, find the SQL Server instance you're running, and set the startup to Manual.
The biggest challenge I faced in creating the scheduled tasks was permissions. The task should have been able to run with my account and elevated privileges. It would, when I was logged in. But it failed on reboot. The solution was to use the local Administrator's group. I don't know why. Here are the settings. Triggers, Conditions and Settings are the same as above.
Death by 998 Cuts
I've now removed two irritations in my daily work flow. It took a while, but is time well spent. I also learned some things. Hopefully this helps you, too.
Save yourself some grief. Set up Backup and Sync to ignore .mdf and .ldf files. They can't be backed up while in use, and will always be throwing errors. If you really need the data, set up SQL backups.