Proposed method of off-site backups

Discussions around the setup, operation, replacement, and disposal of clerk computers, not to include using MLS
aclawson
Senior Member
Posts: 712
Joined: Fri Jan 19, 2007 6:28 pm
Location: Commerce Twp, MI

Proposed method of off-site backups

Postby aclawson » Sun Jan 04, 2015 4:29 pm

All units should be maintaining an off-site backup of their administrative computers, but many units do not. Those who do take the flash drives home may forget to bring them back, or they may be damaged or accidentally overwritten, or may get sick and not attend church one Sunday, or perhaps aren't always the person making updates on the machine during the week. Additionally, having the data offsite like this is not the most secure method of backups as the flash drive is easily lost or stolen. In a nutshell, lugging a physical copy of the backup around is less than optimal, is inefficient, inconvenient and reconsideration of the policies and methods of storing this off-site backup is long overdue.

I propose a standardized solution that is secure, easy to deploy and maintain, can be automated, results in no data being stored off of church premises, provides redundancy and results in total annual costs to the stake of only $29/year.

This method uses a product called Hamachi which is provided by LogMeIn.com, a well known, well established company with a long, proven track record of reliability and security. Hamachi is a VPN client that provides secure, point to point connections between computers that will allow for each ward to directly back up their data to a remote system, thus satisfying the goal of offsite backup, but without relying on an easy to lose, easy to damage USB stick that has to be physically schlepped around. Licensing for this product is $29/year for 32 client computers - more than sufficient for any stake I've ever seen.

My proposed configuration is as follows:

1. The stake clerk/STS, on the stake administrative computer installed the Hamachi client. This results in a private IP address in the 25.x.x.x space which can not be reached by any client that is not also running Hamachi **AND** is not authorized to join this specific private network.

2. Hamachi is configured to create a hub and spoke network with the stake clerk's computer being the hub. In this configuration (also called a one to many network) no client machine can communicate with any computer except for the hub.

3. On the stake computer a series of users are created, one for each ward, with a secure and unique password.

4. On the stake computer a data folder is created for each individual ward.

5. Each ward's folder is configured as a separate share. Access is granted to each folder via Windows permissions so that each ward has access to their own data folder but no others.

6. On each ward's computer the Hamachi client is installed. Since the $29/yr license cost covers 32 devices in total there is no additional expense for this.

7. Each ward PC is added to the stake's private Hamachi network (this must be approved by the network administrator - this is a secure network and unauthorized clients cannot be added to the network).

8. A local drive (X: or S: or G: or whatever) is mapped to connect to that ward's backup folder on the stake computer. The general format for this would be

net use x: \\25.x.x.x\123456 password /user:123456 /persistent:yes

This results in the local computer showing drive X: to which files can be copied/read just as with a local drive, but is actually kept on the stake administrative computer.

9. When MLS prompts to create a file backup simply specify the X: drive as the location and your off-site backup is complete.

As for the off-site backup for the stake computer, map a drive from the stake computer to point to the unit admin computer for either the stake clerk or the STS and schedule a batch that runs every night and copies all of the ward files from the stake machine to a hidden, protected directory on that macine. Or the STS could make a backup onto a flash drive and physically maintain the offsite backup of the stake clerk's machine.

russellhltn
Community Administrator
Posts: 20750
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Re: Proposed method of off-site backups

Postby russellhltn » Sun Jan 04, 2015 6:02 pm

I see a couple of problems:

First, the Meetinghouse Policy "4.13.2: Only Church-approved, licensed software is permitted for installation on Church computers." Prior versions of the policy indicated that the Stake President could approve software, but there is no such language in the current policy. And I'd question if "Stake President approved" could be considered "Church-approved". Normally, I'd consider "Church-approved" to be something approved at at least the Area Office level.

Second, the same Meetinghouse Policy "4.9.4 The use of cloud-based services for storing and/or backing up MLS or any membership related data is prohibited." While it may not be stored in the cloud, I'd suggest that it's using cloud services to connect the computers together.

Last, I really don't see this as that big a problem. The policy of off-site backups was before CHQ started doing monthly backups as part of send/receive. That, along with CUBS means that there isn't all that much information on the local PC that could be lost. A quick search for "Backup" at clerk support doesn't show any requirement to make off-site backups.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

aclawson
Senior Member
Posts: 712
Joined: Fri Jan 19, 2007 6:28 pm
Location: Commerce Twp, MI

Re: Proposed method of off-site backups

Postby aclawson » Sun Jan 04, 2015 6:14 pm

Which is why this is only a proposal. I'm hoping that somebody in SLC will notice this and at least give it a fair review and hopefully take action on it, rather than relying on insufficient operating procedures that have been obsolete for over a decade.

Although, it is fair to ask that all terms be clearly defined. What is "church-approved"?

VPNs predate cloud-based services by many, many years. Cloud services involve actual storage, Hamachi is nothing more than a brokered point to point connection. At no point is the data actually stored anywhere other than on the two endpoints.

russellhltn
Community Administrator
Posts: 20750
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Re: Proposed method of off-site backups

Postby russellhltn » Mon Jan 05, 2015 12:41 am

Out of curiosity, can you find a current policy that says off-site backups need to be made? I know that was the policy at one time, but I can't find it now.

Also, what is in the backup that isn't in a Unit Refresh? The only thing on the membership side I know of is HT/VT. I'm not sure what there is on the financial side.
Have you searched the Wiki?

Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

aclawson
Senior Member
Posts: 712
Joined: Fri Jan 19, 2007 6:28 pm
Location: Commerce Twp, MI

Re: Proposed method of off-site backups

Postby aclawson » Mon Jan 05, 2015 7:04 am

Handbook 1, 13.3.3

russellhltn
Community Administrator
Posts: 20750
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Re: Proposed method of off-site backups

Postby russellhltn » Mon Jan 05, 2015 10:12 am

aclawson wrote:Handbook 1, 13.3.3

Good answer. The question then becomes if the built-in MLS backup is sufficient.
Have you searched the Wiki?

Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

aclawson
Senior Member
Posts: 712
Joined: Fri Jan 19, 2007 6:28 pm
Location: Commerce Twp, MI

Re: Proposed method of off-site backups

Postby aclawson » Mon Jan 05, 2015 10:22 am

There is other data on those machines that needs to be backed up besides just the MLS (which currently has the HT/VT data and custom calling information that needs to be backed up anyway).

davismaloy
New Member
Posts: 1
Joined: Sat Jan 31, 2015 6:23 pm

Re: Proposed method of off-site backups

Postby davismaloy » Sat Jan 31, 2015 7:00 pm

I agree that a better policy is needed.. Backing up to a flash drive is archaic and if the flash drive is not encrypted, a serious issues to data privacy.
In general, I think it is time to revisit some of the policies.

On one hand, we have backup to flash drive is allowed:
Flash drives can be lost easily, and if not encrypted, could be a loss of financial and personal data.
They are easily forgotten or backing up manually is easily forgotten.
and they can be damaged or corrupted easily.

On the other hand, you have a cloud service like One Drive for Business, which is against policy:
Data is stored in transit and at rest on the cloud servers
The service meets ISO27001, FISMA and a list of other industry standards compliances
Data is backed up/Sync'd automatically
Set up properly, removed the human component which is typically the biggest issue.

Not to mention, One Drive for business comes along with a host of other services as part of O365.

At an absolute minimum, a single account would be necessary per unit to get these benefits.. O365 for NP E1 could get you unlimited users.. (I am assuming the church is a qualifying non-profit)..

Even if they aren't it is still not that expensive..

aclawson
Senior Member
Posts: 712
Joined: Fri Jan 19, 2007 6:28 pm
Location: Commerce Twp, MI

Re: Proposed method of off-site backups

Postby aclawson » Sat Jan 31, 2015 7:16 pm

With my proposal there is no cloud storage and one license covers all units.


Return to “Clerk Computers”

Who is online

Users browsing this forum: No registered users and 1 guest