[OT] Client data backup? On prem, not cloud based.

[mattware]

Hi all,

I'm currently looking for a solution to back up user data on our 50 or so macs. They currently do not back up that data at all. The users know to use network drives but we'd like to implement something because they do occasionally lose work. I'm only looking to back up user data, no applications or system files.

What I need is something on prem, not cloud based. LDAP integration is also necessary. The management is not wild about anything that puts company data in the hands of another company. So far I've got a Crashplan PROe server up and running, and I'm pretty happy with that so far. Reasonable user cost ($5/month/user) for on prem, and minimal server requirements (2 cores, 4gb memory) for under 100 users. And it handles interruptions no problem, as well as runs well in the background.

I've looked at Syncrify (Terrible client, no LDAP), owncloud (Stupidly overpriced), and experimented with Time Machine enough to know it won't work. Does anyone have any other suggestions?

Edit: Forgot to add, the solution must run on Windows as well, we need it to be able to be backed up by our Avamar/Data Domain backup appliance, and those do not support Mac.

[corbinmharris]

CrashPlan ProE from Code42

We looked at on-premise and hybrid options and went with their cloud hosting.

They do AD/LDAP integration and there is an admin guide at this link

http://resources.jamfsoftware.com/documents/white-papers/Administering-CrashPlan-PROe-with-the-Casper-Suite.pdf

Corbin

[RobertHammen]

End user, not server data? Sounds like you have your solution in place. CrashPlan, backing up to your own server, is perfect for this.

Just think about if any of the data is critical from a DR perspective (i.e. what would happen if a fire or theft affected the building and you lost all of your client machines AND your backup server). You may consider co-locating a secondary CPP server in the cloud at somewhere like MacMiniVault or something. A good backup strategy for mission-critical data will include onsite and geographically-diverse offsite backup.

[mattware]

@RobertHammen

The crashplan backup directory would be backed up by our Avamar which is then duplicated to an offsite DR. I'm already happy with crashplan but thought I should see if there were any other options.

And yes, end user data, not server data.

[znilsson]

I'm in the process of evaluating CrashPlan as well, and I think it's the best one out there. Since you can easily point it to on-prem storage instead of the cloud, that seems like it should work for you. I have Casper pushing the CrashPlan client installer completely silently, and I have a policy that enables the CrashPlan client in via Self Service if it's installed on that machine, which allows users to get to the client and restore files.

[mattware]

@znilsson

I'd be interested in hearing more about how you configured the package you push. I've played around with the custom installer that Crashplan has and I'm struggling a bit to get it to be completely silent. So far I haven't been able to get it to launch without needing a password, or without having the "new user" screen show up, even though I've preprogrammed the server address and other things. All our macs are in LDAP so you'd think it could automatically log in and start backing up that way, but I haven't figured that out yet.

[znilsson]

@mattware It took me a while to get it smoothed out too, I had a lot of help from David Ta at CrashPlan. That guy is a superstar. My CrashPlan install policy includes two packages: The standard Install CrashPlan PROe.pkg, and another one I called CrashPlanCustomInstall.dmg. The custom install one is the one that does the magic. NOTE: the custominstall dmg is set to priority 8 and the install crash plan pro pkg is set to priority 10, so that the custom install one runs first.

Inside the custominstall dmg there are two files that get installed into Library/Application Support/CrashPlan/.Custom - custom.properties and userinfo.sh

Here are the contents of both my files so you can see what we did. Our servers, hosts and IPs are anonymized to protect the innocent, but you get the idea.

###################################################################################################
##
## custom.properties
## Edit these properties to customize and/or simplify the user's experience.
## http://www.code42.com/r/support/custom.sh-3.6.1.4
##
###################################################################################################
## Authority properties
## Skip the register/login screens by providing address, registrationKey, username, and password.
##
## Authority Parameters
## ${username}
##     determined from the CP_USER_NAME command-line argument, the CP_USER_NAME environment variable, 
##     or "user.name" Java system property from the user interface once it launches.
## ${computername} - system computer name
## ${generated}    - random 8 characters, typically used for password
## ${uniqueId}     - a globally unique id, a large number
## ${deferred}
##     for LDAP and Auto register only! This allows them to register without password 
##     and requires user to login to CPD the first time.

## the primary address and port to the authority that manages the accounts and issues licenses
## Example:  internalhost:4282
address=server.domain.com:4282

## the secondary address and port to the authority that manages the accounts and issues licenses. 
## Note: This is an advanced setting. Use only if you are familiar with its use and results.
## Example:  externalhost:4282
secondaryAddress=externalserver.domain.com:4282

## Do not prompt or allow user to change the address (true or false)
hideAddress=false

## Lock server address setting so that user cannot change server address (true or false)
lockedAddress=false

## The organization registration key, when specified the field is hidden in the register/login screen
## Example: AAAA-BBBB-CCCC-DDDD
registrationKey=AAAA-BBBB-CCCC-DDDD

## The username to use when authorizing the computer.
## Accepts any authority parameters listed above.
username=${username}

## The password used when authorizing the computer.
## Accepts any authority parameters listed above.
password=${deferred}


##################################################################################################
## Proxy properties
## Enable the use of a proxy server when devices running the CrashPlan app must use a proxy server 
## to connect to a Code 42 enterprise server instance that is external to the LAN. 
## The proxy server must be accessible to all devices running the CrashPlan app.
proxy.enable=false

## The URL for the proxy server
proxy.pacUrl=test


##################################################################################################
## Sigle Sign-on properties

## SsoAuth will not be available unless this is true. Default is false.
ssoAuth.enabled=false

## Login via sso is enforced, the login with sso button is hidden. SSO must be enabled. Default is false.
ssoAuth.required=false

## Name of the SsoAuth identity provider. Only used if ssoAuth.enable=true. Default is "Shibboleth".
ssoAuth.provider=single sign-on


###################################################################################################
## Language properties
## Any properties listed here will override the default language properties (see lang/txt.properties), 
## but will take effect only for CrashPlan apps that use an English-language locale.


###################################################################################################
## END
###################################################################################################

And here's the content of the userinfo.sh script - no need to anonymize here, this is the exact script I'm using based on how our AD is set up, YMMV depending on how your AD environment is set up.

#!/bin/sh

#
# Optional script by which you can control the user installation.
#
# Variables to set:
#   startDesktop: set to false if you don't want the desktop to start up immediately after installation 
#      CP_USER_HOME: Allows the app to start scanning the user's home folder immediately after installation
#      user:         Used to properly set file permissions
#      userGroup:    Also used for file permissions
#      CP_USER_NAME: This will become the unique ID for the user in the PROe Server database.
#                    Leave CP_USER_NAME blank to require the user to enter it.
#                    If set this value, you'll want to set the username="" attribute of <authority ... /> tag in default.service.xml to username="${username}"
#

#
# Set to false if you don't want the desktop UI to start up.
#
startDesktop=false

#
# When installing from the root account (for example) you will need to populate
# some or all of these variables differently than is done below. 
# Note: whoami *always* returns "root" for this package so we had to get creative to find the installing user.
# Also: You will want to populate CP_USER_NAME with the right email address unless you don't want your users or admins receiving reports and alerts. 
# 
user=`defaults read /Library/Preferences/com.apple.loginwindow lastUserName`
CP_USER_HOME=/Users/$user
userGroup=`id -gn "$user"`
CP_USER_NAME=$user


# 
# Users have suggested alternate ways of finding the user name and email address.
# The following examples may work better for your situation.
# 
#user=`last -1 | awk '{print $1}'`

# This assumes the username is the last part of the home folder name
#user=`basename "$CP_USER_HOME"`

# This parses the user from the computer hostname
# Because the APL naming convention uses the name of the owner in the computer name we will use this
# to derive the primary user name. So the primary user does not have to be logged in for this to work.
#computerName=`scutil --get ComputerName`
#user=${computerName%%-*}

# This finds the email address from AD or LDAP
#dsclEmail=`dscl /Search read /Users/$user mail`
#CP_USER_NAME=${dsclEmail##*mail: }

# Run As User
# Uncomment the following line if you want the service to run as user instead of root.
#touch "${TMPDIR}/.cpRunAsUser"

So in addition to those two files being configured correctly, you also need to configure CrashPlan Admin > Settings > Security > LDAP, and make sure all that info is correct for your environment, and you have an AD account you can use that has access to read AD. My settings in this area probably wouldn't do you any good because they're specific to my environment but if you want to see them anyway let me know and I'll post them. Once CP Admin has been set up so that it's reading your AD database and can lookup people in your org by name, then running your policy with these pkgs should be completely silent and the user's name will also automatically show up in CrashPlan Admin under Users.

Hope this was helpful.

[pblake]

@mattware plus+1 for Crashplan. Big fan.