that's all ok if you have backups that arent also corrupted, i would have thought there was a way that you could regenerate them from SM 

This turned out to be the accounts.json file, and they were quite empty! Most (aside from one domain who likely had this occurring for some time now) domains were corrected by way of a restore of this file from the backup for the night before via the Archived Data directory.

We had exactly this problem after a power outage last week. Several users' calendars and contacts (including mine) disappeared - the problem was figuring out which json files were affected. I ended up by restoring ALL the json files from the Archived Data files. This worked without any apparent problems, but is it safe to restore ALL the json files?

@Robert: Power failures are unfortunately one of the most common causes of this behavior since we have these JSON files open throughout the day under standard operation, and when our access to them is terminated improperly we end up with damaged versions of the file. 

It is safe to restore all of the JSON files, but any changes to folder lists, contacts, calendars, etc since the day of that backup file will be lost during that restore. The only place I can see this truly introducing trouble is in synced clients.

For example; if a user has an Outlook client syncing an account via MAPI, the user adds a folder, then the files become corrupt and have to be restored to a previous version, this could result in the Outlook client trying to sync this missing folder repeatedly. To correct something like that we'd just need to have the user do a full re-sync (including removal of the sync key in Settings>Connectivity>Synchronized Devices) then allow the customer to recreate their missing folder once Outlook is back in sync.

When we ran into this issue I used this powershell command to look for corrupted accounts:

select-string -path D:\SmarterMail\Domains\*\Users\*\settings.json -pattern "{`"settings`":{`"" -simplematch -notmatch | format-table path

It just lists the full path for all the settings.json files that are blank. You could easily adapt this to look for other corrupted json files.

That's a great little script! A good way to check for corrupted settings.json files is to check the Error logs for the pattern password encrypted is null as well, as this will return any accounts with an invalid password configuration, frequently pointing to a corrupted JSON.

Kyle, if this is a known issue, wouldn't it make sense to make a copy of the files before opening them and then update that copy whenever closing them.  Then if you start and the .json is empty you can just re-copy the copy and use that?

Seems a simple solution to what sounds like a common problem.

Good point Rod, and we already have this in place. You can see evidence of that in the Archived Data folder found in the system, domain, and user level directories. That said, when this takes place its because we were in the process of swapping those files (.json and .json.tmp) at the time of the lock, failure, or disk corruption.