[#1]

Hi,

- Platform:

Windows 7, x64

- Mozy Version:

2.14.0.183

- Bug:

Mozy seems to treat locked BitLocker drive as non-existent, deleted, thus discarding all the data on the server side as well. Bad idea.

Unlocking the relevant BitLocker drive back out and performing yet another manual Mozy backup with the Start Backup button re-sends all the data to the server from scratch.

- Steps to Reproduce:

1.) Unlock a BitLocker drive.

2.) Include the BitLocker drive letter into a Mozy backup set through Settings >> File System.

Also: (Settings >> Options >> Scheduling >> Scheduled).

3.) Perform a (successful) manual Mozy backup with the Start Backup button.

4.) >>Lock<< the BitLocker drive.

5.) [Wait a few days and?] perform another manual Mozy backup with the Start Backup button. All the BitLocker drive letter data gets re-backed up from scratch as if previously deleted.

- Expected Behavior:

Do not assume that the data on a locked BitLocker drive has been deleted. Simply exclude it from the backup, >>retaining the very last copy on the server side<<.

- Rationale:

Certain sensitive data needs to remain BitLocker locked and secure on day-to-day basis, but BitLocker unlocked and Mozy backed up only once a month. However, other data needs to be Mozy backed up more frequently or even on day-to-day basis (continuously).

---

Thanks...

Gary

[#2 · Accepted solution]

Thanks for the good writeup of the bug report!

This is actually working as designed though. I haven't actually used Bitlocker, but I believe it works in the same mannerisms as Truecrypt in that it mounts a "virtual like" volume, or makes the volume accessable when activated for lack of a better term.

Whenever files are unaccessable, be it an external drive that is unplugged, a virtual drive or mounted drive, a network drive that is offline, whatever the case the backup can not see the files and thus marks them as deleted. When the files are accessible again, the files have already been marked for deletion as such causes a rebase. File that haven't changed since their backup will not upload as always, but it will go through everything as if it was a new file.

We are looking into ways to change the way we handle files when they disappear, but as for now that is working as designed.

[#3]

Thanks for the reply.

IMHO, adding a particular drive letter to a backup set within a backup application, in a sense, "declares" that data as "valuable" and "expected to be persistent". Even if, say, a network drive cannot be mounted (but its drive letter remains), it is probably a bad decision to simply drop all the backed up data.

Moreover, BitLocker, as opposed to TrueCrypt, does not introduce secondary, virtual drive letters, but rather retains original partition-assigned drive letters and is capable of reporting a BitLocker-encrypted drive as Locked or Unlocked (but still considered healthy within the Windows system). A Locked, healthy, permanent drive letter should probably be handled differently than a temporary external drive letter that disappears altogether.

I hope you guys can fix it sometime.

Thanks,

Gary

[#4]

Actually, the problem is worse than I thought.

1.) It might not be necessary to run a Mozy backup cycle across a BitLocker drive that is locked, it [might be] enough just to have the Mozy Windows service running in the background.

2.) Not only will the last backup of a locked BitLocker drive be flagged as deleted on Mozy servers, but also Mozy "Settings >> File System" selection WILL BE CLEARED AUTOMATICALLY, resulting in a COMPLETELY QUIET BACKUP DROP WITHOUT ANY ERROR MESSAGES WHATSOEVER ON ANY MOZY BACKUP CYCLE.

This is absolutely HORRIFIC behavior for backup software. Without any error messages, neither during the problematic backup cycle, nor during subsequent backup cycles, 30 days will pass and the last, archival Mozy backup will be erased as well.

Quiet 100% data loss.

Please respond.

Thanks,

Gary