Wasn't the last sentence in your last paragraph (before my post) "When the sync software realized that 90% och the photos had gone missing, they were removed from the Google Drive as well :-(". How is it NOT related to that what I wrote? Are you having trouble parsing my simple post (I really can't make it simpler for somebody who can't even see how it's related to syncing to Google Drive) or are there multiple people using your account?
If you're using the official backup&sync client (which sucks big time) there's an option to remove things everywhere once removed here (whatever the wording is) - you need to uncheck that if you want a backup, for obvious reasons. Still probably you should find in the trash everything that was removed on the drive. If using rclone it is highly recommended to use "backupdir" option (preferably with a different folder each run generated from the timestamp) - this would make removed/changed (think of...
Generally speaking unless you are using autosave the progress of a sync will be lost if interrupted unexpectedely. autosave SIZE_IN_GIGABYTES Automatically save the state when syncing or scrubbing after the specified amount of GB processed. This option is useful to avoid to restart from scratch long "sync" commands interrupted by a machine crash, or any other event that may interrupt SnapRAID.
Generally speaking we have deduplication (at least but not only) for NTFS and btrfs. Snapraid as a normal user-space app just sees the files as normal files and works fine, except for using more parity space than really "needed". Sure, normally you should use parity drives that are a bit bigger than your bigger disk but if your deduplication is any good you might end up needing MUCH larger disks. It's clear that's a major undertaking but some way to have this duplicated data take space only once...
I would investigate first without changing anything, this way you're sure to get the root cause instead of assuming something fixed it. Run procmon from the link above (note it's a microsoft.com freeware, not some possible trojan or something), you'll need to do some filtering probably but it's very easy to use - and if something is hitting your disk C: so much it should be very clear what. Yes, removing the content file should be just commenting out in snapraid.conf (and a sync just to see everything...
From what I see you just have one content file on C: so if you don't have any swapping that should be your issue. It's very easy to use "one less" content file; just do a sync, make sure all files are updated (you can even checksum them) and then remove the one from C: and the same from config. That's it. Before that maybe you can run https://docs.microsoft.com/en-us/sysinternals/downloads/procmon to confirm this is where snapraid is writing. Edit: now that I'm thinking actually the content file...
From what I see you just have one content file on C: so if you don't have any swapping that should be your issue. It's very easy to use "one less" content file; just do a sync, make sure all files are updated (you can even checksum them) and then remove the one from C: and the same from config. That's it. Before that maybe you can run https://docs.microsoft.com/en-us/sysinternals/downloads/procmon to confirm this is where snapraid is writing. It is NOT the case for snapraid (unless you find something...
Yes, the only thing you need is to enable the time stamp thingy in veracrypt and everything will work fine with snapraid BUT: how do you use your containers? Do you use them as some kind of archives (like you put all the documents from 2017 and keep them in one container) and usually don't change anything in them? That is fine. However if you have your "working drive" with many things that change all the time, with a lot of documents, maybe browser profile and so on then having snapraid include such...