Exclude mounted file system (Cryptomator) from image backups.


Author
Message
wbrells
wbrells
New Member
New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)
Group: Forum Members
Posts: 14, Visits: 37
I'm using the Cryptomator program to securely store files in Google Drive. Those files are accessed locally via a mounted virtual file system which in my case appears as C:\Users\wbrel\Documents\myDymoMount. This file system contains UNENCRYPTED versions of my files which I would like to exclude from an Image backup. I've tried the Registry modification that has been widely suggested as a way of excluding files from Image backups. Under FilesNotToSnapshotMacriumImage I added:

Name: Cryptomator
REG_SZ_MULTI: C:\Users\wbrel\Documents\myDymoMount\*.* /s

with an Enter to terminate the line. Unfortunately, the files under myDymoMount are still being backed up! Is there any way to prevent mounted file systems from being backed up by Macrium Reflect (or to get the above Registry modification to actually block the backup of those files)?

Thanks,
Wayne


jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)
Group: Forum Members
Posts: 9.1K, Visits: 61K
I've never had a use case for this, but I've pulled my hair out dealing with registry modifications not having an effect and then seeing that I had made a tiny typo when setting it up.  So if you haven't already, verify that the item is in the correct folder and that you don't have a typo of some kind.  Other than that, if you haven't already restarted, I'd suggest doing that in case the VSS engine needs to restart to apply those changes.  As a last resort, you could create a separate partition on your disk to store the data and easily exclude that partition from your backups.  I know that sounds like a blunt instrument solution, but I personally always store my user data on a separate partition simply because it gives me a way to restore my OS to an earlier point in time without having to roll back my personal data to that earlier point in time as well.  When the latter is on a separate partition, that one can be left as-is when performing a Reflect restore.  (Although I suppose if you moved ALL of your data to this other partition for this benefit, then you'd have the exact same problem here of wanting to exclude specific data from a partition that you'll still be backing up.)

wbrells
wbrells
New Member
New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)
Group: Forum Members
Posts: 14, Visits: 37
Thanks for your comments! I've just rebooted my system so the VSS engine will be sure to pick up my changes. I've checked and double-checked the Registry modifications and everything certainly seems to be in order. BTW I have a couple of mounted Cryptomator file systems of this type and neither is getting excluded from the backup. I'm wondering if mounted file systems are treated differently than "regular" files? As a test, I'll try excluding a "normal" directory under ...\Documents and see if THAT gets excluded. Should I see an indication in Macrium Reflect's VSS log report showing that my files have been excluded from the backup?

Some of the Cryptomator mounted file systems can get quite large, so creating a separate partition of them isn't really practical...

I'll let you know how my test works out!
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)
Group: Forum Members
Posts: 9.1K, Visits: 61K
That could certainly be the issue, so that would be a good test.  I'm not sure how Cryptomator works.  I'm guessing it takes advantage of the Windows capability of mounting a volume within an empty NTFS folder, which can be done in Windows Disk Management even with normal disk volumes.  But even if I did know that for sure, I'm not sure whether that makes a difference in terms of how the VSS snapshot engine treats such files.  But I'm curious to hear your results, so please do report back!

Edited 24 February 2021 3:37 PM by jphughan
Beardy
Beardy
Proficient Member
Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)Proficient Member (363 reputation)
Group: Forum Members
Posts: 299, Visits: 1.2K

First observation, probably a typo, but the type is REG_MULTI_SZ not REG_SZ_MULTI as reported.
Can you confirm you're actually using:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshotMacriumImage

A screenshot of Regedit would have stopped me nit-picking those details.

Assuming that key behaves the same as:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot

Then both Registry keys for backup and restore and Excluding files from shadow copies from Microsoft are interesting reads,
The latter contains the following please note the final bullet point:
Note

The FilesNotToSnapshot registry key is intended to be used only by applications. Users who attempt to use it will encounter limitations such as the following:

  • It cannot delete files from a shadow copy that was created on a Windows Server by using the Previous Versions feature.
  • It cannot delete files from shadow copies for shared folders.
  • It can delete files from a shadow copy that was created by using the DiskShadow utility, but it cannot delete files from a shadow copy that was created by using the Vssadmin utility.
  • Files are deleted from a shadow copy on a best-effort basis. This means that they are not guaranteed to be deleted.

Also the first linked page has this, I've added some bold:

Note

Applications that perform volume-level backups generally do so by copying the entire volume at the block level, so they cannot honor the FilesNotToBackup registry key at backup time. Instead, they wait until restore time to delete the files that were not to be backed up. In most cases, this is a reasonable strategy. However, in the case of Single Instance Storage files, the SIS Common Store files must not be deleted at restore time.


If that's what Macrium is doing, which seems reasonable, @jphughan might know for certain, or someone actually from Macrium. Then only a test restore will tell you if they're excluded, not simply browsing the image.

If you don't want them there at all, then I'd suggest modifying the process for backing up non VSS aware databases here & using the batch files to temporarily dismount those virtual filesystems during snapshot creation, assuming Cryptomator has a command-line interface for mounting & unmounting them.


wbrells
wbrells
New Member
New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)
Group: Forum Members
Posts: 14, Visits: 37
I've inserted an image of the relevant Registry entry. More significantly, I determined that files that are in a "normal" directory are indeed blocked from being backed up. It appears that files in the Crypomator virtual directory are considered shared files (or similar) and are therefore not being excluded. It looks like that I'll need a different approach to "protect" the backup. I'll look into dismounting the Crptomator directories before making the backup...

Thanks to everyone for their help!

Wayne



jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)
Group: Forum Members
Posts: 9.1K, Visits: 61K
Well at least the problem is now clear.  If you don't want to unmount, there's still that secondary partition idea, and you could dedicate that partition purely to these mounts.  Just shrink your C partition, create a new one in the freed up space, and have this volume mount there instead.  Then exclude that partition from your backups.  If you ever need a larger partition to mount your folder, delete the existing partition, shrink the C partition a bit more, and create a new single partition in that expanded free space.

One general note I'll add here that doesn't pertain to this exact scenario but does pertain to virtual disks is that not all virtual disk solutions support VSS.  For example, if you have a VeraCrypt container file on your C partition and have it mounted when you create a Reflect backup, the VeraCrypt container file itself might not get backed up in a consistent state since it was open for writes.  If it supports VSS, then this isn't an issue, but I don't believe VeraCrypt does as of this writing.  The bottom line is that having a virtual disk file actually mounted during a backup that will include the container file you've got mounted can be risky.  Again, I realize that's not precisely how Cryptomator works.  This is just general info for a similar use case.

wbrells
wbrells
New Member
New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)
Group: Forum Members
Posts: 14, Visits: 37
I've not seen any problems backing up open Veracrypt containers, but I realize there is a POTENTIAL problem. Just to be doubly safe I also make monthly backups with those containers closed... As far as Cryptomator containers are concerned, I believe the easiest approach is just to password protect the Macrium Reflect backups (which I probably should have been doing all along!) That way, I'll have a backup of the UNENCRYPTED files that could be used to restore the Cryptomator container (which they call the Vault) in case of disaster. It isn't totally clear to me, but it appears that with Macrium Reflect  7.3 at least, assigning a password also encrypts the contents of the backup (and doesn't just prevent the backup file from being opened).

Wayne
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)Macrium Evangelist (13K reputation)
Group: Forum Members
Posts: 9.1K, Visits: 61K
There are two separate options.  One is a password, and if you enable that, you can optionally also enable encryption.  Both options have been available at least since Reflect V6 when I started using it, meaning that even V6 could use encryption and even V7.3 can be configured to have a password without encrypting the data -- although prior to V7.2's release I suggested to Macrium that they change the default choice to 128-bit encryption rather than no encryption, and they did.

wbrells
wbrells
New Member
New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)New Member (18 reputation)
Group: Forum Members
Posts: 14, Visits: 37
jphughan - 25 February 2021 2:00 PM
There are two separate options.  One is a password, and if you enable that, you can optionally also enable encryption.  Both options have been available at least since Reflect V6 when I started using it, meaning that even V6 could use encryption and even V7.3 can be configured to have a password without encrypting the data -- although prior to V7.2's release I suggested to Macrium that they change the default choice to 128-bit encryption rather than no encryption, and they did.

Thanks for the clarification. In my case, since I don't "travel" with my backups (except to a safety deposit box), the 128-bit AES encryption should be more than adequate and doesn't seem to slow down the backup process to any noticeable degree.. Again, many thanks.
Wayne
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search