Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2028
  • Last Modified:

Backup Exec fails with TrueCrypt encrypted system partition.

I have been working on setting up a server with full disk encryption.  The server is running Server 2008 R2 and full disk encryption was implemented with TrueCrypt.  I am utilizing Backup Exec 2010 for my backup procedures but when attempting to backup the system state of the machine, the backup fails with the error indicating that the VSS provider was unable to create the required snapshot.

Removing the full disk encryption enables Backup Exec to successfully create the backup.  My issue is simply that I need both of these capabilities and need to figure out how to get both full disk encryption along with a sustainable backup strategy on the same machine.  

I have spent a few hours on tech support with Symantec and they have been unable to solve the problem.  I have also investigated utilizing BitLocker which is integrated into Server 2008 but unfortunately, the program indicates that my hard drives are not partitioned correctly to utilize the software, and my system lacks a TPM chip required to use BitLocker.

I am open to any combination of full disk encryption software / backup software.  My only requirement is to minimise cost as much as possible.
  • 3
  • 2
1 Solution
how easy is it to remove the full disk encryption? i know there is a command line part to truecrypt so you should be able to create a script to run the encryption/decryption for you.  if you can create a batch file from this script your cheapest option might be to create a script that removes the encryption and add the script to BE's 'run this program before backing up', then reverse the script and add to 'run this program after backing up'. then if you want the backups encrypted just use BE's own built in encryption.
if you do go this route i would strongly advise practicing on a dummy machine first!
mcvay178Author Commented:
Decryption on the 80 gb system partition takes about 20 minutes, encryption takes about 3 hours.. I would be a bit uncomfortable with this solution since 1, we are decrypting out system so it poses a security risk, and 2, assuming TrueCrypt failed to encrypt properly and corrupted the system, our company would be unable to function until the server was completely reformatted and restored.  
Can you give us some more color on your requirements? For example:

1. Are your backups stored onsite or offsite? On removable media or on running systems?

2. Is Backup Exec a firm requirement or are you willing to use an alternative backup mechanism?

3. Is full disk encryption a firm requirement, or would an encrypted volume for the data itself be acceptable?

Among other things, I'm trying to make sure we don't have any needless complications in the requirements. For example, if this is a company server that runs 24/7 onsite then encrypting the system volume doesn't seem to add security. Anyone who achieved physical (or virtual) access would find everything unencrypted for the taking. Encryption would only protect you when a) the server was off, or b) the data was elsewhere. Protecting the local server physically is best done, well, physically. Protecting it virtually is a task that must be undertaken regardless of encryption.
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

mcvay178Author Commented:
An encrypted volume is acceptable but it must be accessible even when the user is not logged in, ie  mount at boot.  Either this or as long as the thing stays mounted.. its the shared files, medical database and sql server on 2 of our work servers and must be accessible at all times.

Backup Exec is not a firm requirement.  It just happens to be the software I have on the system right now.  I would just like something automated and as hassle free as possible.. exporting dns entries in regedit isn't my idea of a good friday afternoon.

Backups are stored onsite, with an offsite rotated out biweekly.

The primary concern is that some of our business partners actually had someone break into their business and literally steal the server box out of their office causing a huge HIPAA mess.  Encryption of medical information is a mitigating factor in that circumstance since as soon as the machine is unplugged, an on-the-fly encryption system will be safe. (ie truecrypt)

In terms of physical protection, we have similar safeguards as the business mentioned above.  Unfortunately, two solid doors and an alarm system all locked tight didn't stop them in that case, so it has become a requirement from management that assuming the server is physically stolen, regardless of the physical security, the data must stay safeguarded.  Encryption is the only way I can think of that appropriately mitigates the HIPAA risk.  

Hope this clarifies the situation.  Post back if you have any other questions.
Yes, that sets things out pretty clearly. Alright - am I correct that the full-disk encryption you have used so far requires a password to be manually entered at login? It seems to me that it must, if it is going to stop thieves from accessing the drive after removing it from your office. If we want them to fail, we have to make sure they are missing something. If the server can start up - including access to the encrypted data - all by itself, and they have the server, then they aren't missing anything. So I think that a manual security step at login is going to be a firm requirement for you.

Here is the best solution I can think of given the constraints we have discussed:

1. Divide your drive into a unencrypted system partition and a TC-encrypted data partition. If re-partitioning is a hassle, just make the TC volume file-based instead.

2. Back up the system partition normally via Backup Exec. If you created the data volume as a TC file on the system partition, just tell Backup Exec to ignore that file.

3. Get the data volume to prompt for its decryption password at boot, or at some point before SQL Server starts up and expects its database to be there. Someone will have to physically enter the password each time this occurs. Likewise, ensure that Windows doesn't mind having its file-share directory show up late to the boot party.

4. Get SQL Server to dump periodic SQL files, query logs, binaries, or whatever makes the database back-up-able to a dedicated directory on the data volume. Let's say your directories to be backed up are /share and /db-dump.

5. Set up a file-based, TC-encrypted backup volume on the system partition.

6. Periodically back up /share and /db-dump from the TC data volume to the TC backup volume using any backup system that works. Wipe the contents and replace it with your new backup data each time. You might find that Backup Exec works as expected for this, because you aren't trying to take a whole system snapshot. But simple scripts should work too. You'll want to mount the backup volume only when starting a backup, and unmount it again when the backup is complete.

7. When the main Backup Exec operation runs and takes its backup of the entire system partition, that partition will contain the TC backup volume as a coherent, unmounted file that is not being accessed. So it should work without complaint, and would restore it just the same. The only extra recovery step would be that after using Backup Exec to restore your system partition, you would have to recreate the data volume (as partition or file) and re-populate it from the contents of the encrypted backup volume that was restored onto the system partition.

Obviously you could tweak this formula a lot of ways for convenience, but this seems solid and workable to me as a starting point. Check out this thread for a very relevant discussion of running your database out of a TC volume:
mcvay178Author Commented:
Great breakdown.  Sorry for the delayed response, I have been under the gun at school and work so I have not had time to post.

I have already unencrypted the system partition of my file server and essentially followed your guidance on the setup and it is functioning properly.  I have yet to convert the medical database to this setup because we have been waiting on backups tapes and were changing around responsibilities for backups so it has just been held up a bit.. I will be converting the system this week and will test backups utilizing the scheme you have laid out.

Since the file server is functioning properly, I know this scheme works so thank you for the solution!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now