Offsite Storage of MLS Backups

[RossEvans]

The latest policy that came out explicitly declared that storing MLS backups off-site is prohibited.

Can you point that out? Because I've missed that. What I have seen is "4.8.4 The use of cloud-based services for storing and/or backing up MLS or any membership related data is prohibited." But that doesn't apply here.

Not only is offsite backup not prohibited (except for the prohibition against using "cloud-based services" for this purpose, as russellhltn points out), it is still required by Handbook 1, Section 13.3.3. At least that is the way I read it.

[aclawson]

So the choices are:

* STS goes to each meetinghouse on a regular basis, grabs the backup and takes it with him

* Rely on local clerks to always remember to make a backup on a USB drive, take it home, never lose it or send it through the washer or break it

Meanwhile there are perfectly good commercial systems with high levels of encryption with user-retained keys (the companies themselves cannot access the data, ever) to backup the MLS data files which are already encrypted. One account can easily keep all of the meetinghouses backed up in real time, in a fashion that is a LOT more secure than a USB stick that can be lost and can never be forgotten.

But that's the recommendation that IT made to the leaders then so we'll just speak to the stake presidents and get an ok to do things another way.

The only secure, reliable way of getting this done in a method that even vaguely resembles the best practice of the last five years is to set up a VPN from each meetinghouse to a system somewhere else (stake clerk's computer would be a good choice) and run a backup that way. The stake clerk's computer isn't on the cloud and an encrypted volume is trivial to configure. $29/year gets you 32 client licenses - far more than enough for any stake in the US.

[russellhltn]

Meanwhile there are perfectly good commercial systems with high levels of encryption with user-retained keys (the companies themselves cannot access the data, ever) to backup the MLS data files which are already encrypted.

Keep in mind the church is already doing a backup once a month.

But that's the recommendation that IT made to the leaders then so we'll just speak to the stake presidents and get an ok to do things another way.

As far as "use of cloud-based services for storing and/or backing up MLS or any membership related data", that's not a recommendation. That's policy. The stake president has no authority to override it.

[aclawson]

The stake clerk's machine is not a cloud-based service.

[russellhltn]

The stake clerk's machine is not a cloud-based service.

The question is how do you get there from another chapel?

I think having the clerk do it is the best plan. Tell him that if he fails to do it, then he gets to re-enter all the information.

[aclawson]

My last paragraph:

set up a VPN from each meetinghouse to a system somewhere else (stake clerk's computer would be a good choice) and run a backup that way. The stake clerk's computer isn't on the cloud and an encrypted volume is trivial to configure. $29/year gets you 32 client licenses - far more than enough for any stake in the US.

Set up a shared volume on the SCs machine, one folder per ward. Each ward maps an X: to their folder on the stake clerk's machine and use task scheduler to copy the most recent files across the VPN to the SC's computer. No ward can access any other ward's backup data. Users at the SC's keyboard would need a password to access the shared volume even if they knew it was there, which they wouldn't because the partition's drive letter would be hidden and never shows up anywhere.

[russellhltn]

The question is: is a VPN considered a "cloud-based service"? It's most certainly is being used for backup.

But this level of backup is really unnecessary. If the worst happens, the computer will be replaced and the work will move on. At this point the only part of MLS that isn't backed up weekly is the HT/VT and custom fields.

[RossEvans]

The question is: is a VPN considered a "cloud-based service"? It's most certainly is being used for backup.

A more relevant policy question is whether the suggested remote access to the stake computer violates the prohibition against remote access under section 4.9 of the new Meetinghouse Technology Policy.

As for the technical merits, I do not find the suggested remote use of the stake's low-end desktop computer, which would have to be left running unattended, to be an attractive idea at all. (And in our building, which happens to be a stake center, it wouldn't even qualify as offsite.) Technically, using a proper backup server in a remote data center, professionally administered, is a good solution. It seems that the church is moving toward that solution with its own central servers, but that solution is not yet complete and comprehensive so local backups are still a good idea.

[russellhltn]

Technically, using a proper backup server in a remote data center, professionally administered, is a good solution. It seems that the church is moving toward that solution with its own central servers, but that solution is so local backups are still a good idea.

When you say "not yet complete and comprehensive" is it because you don't think once a month is enough or because it's only for MLS?

[RossEvans]

Technically, using a proper backup server in a remote data center, professionally administered, is a good solution. It seems that the church is moving toward that solution with its own central servers, but that solution is so local backups are still a good idea.

When you say "not yet complete and comprehensive" is it because you don't think once a month is enough or because it's only for MLS?

I was only talking about MLS. There still are some holes in the content being uploaded to headquarters (HT/VT, etc.). And the frequency of the MLS backup-set file monthly is insufficient to be the primary backup, only a last-ditch fallback. We really need daily backups whenever MLS data changes, which is most days that MLS is accessed.

It would be nice if the backup files created by MLS were always uploaded automatically to headquarters servers upon exit from the application. But for whatever reason (growth of that file, server-side bandwidth on Sundays, perhaps?) that solution has not been implemented. So the local backups still fill that void:

1) Backup from MLS to C: to handle simple content-level restores of MLS application data.
2) Copy that to a secured USB drive (in case the C: drive fails).
3) Copy that redundantly to another USB drive carried offsite by a clerk (in case the building burns down).
4) Fall back to the headquarters backups and reenter data as needed (in case that clerk was in the building when it burned down).

But since you mention it, some solution to back up the non-confidential stuff on the C: drive, while not as mission-critical, would also be nice. In our case. we really should at least do a simple copy or zip archive of the relatively small Documents folder to the USB drive, but we haven't been doing that.