Disaster Recovery

Not applicable

I'm looking into implementing Disaster Recovery and wanted to see how users
on this list go about doing this for JSS. Currently have two servers
dedicated for JSS use. One is the production server running JSS and
repository for all data/packages. The other is in stand by in case case
primary goes down. What I like to learn is how quickly you can recover if
your primary goes down and how you go about backing up/sync to your 2ndry
server if any.

Thanx in advance
Cyrus

9 REPLIES 9

dustydorey
Contributor III

How about using Lingon to setup an rsync job to copy over a bootable
drive periodically to a free drive. That way your down time is pretty
much the time it takes you to reboot.

information can be found here for lingon to schedule the job for you
http://www.tuppis.com/lingon/

And here on concepts for rsyncing from our fav Bombich
http://www.bombich.com/mactips/image.html

-Dusty-

milesleacy
Valued Contributor

I'd say your DR machine ought to serve as a secondary repository that is
regularly synched. You should be running regular backups of your JSS,
scheduled through JSS Setup Utility and then backed up via whatever backup
system you have in place.
When disaster strikes, you can run the JSS Setup utility on the DR machine,
and import your last backup.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

ernstcs
Contributor III

I have our second Mac server setup as a secondary distribution point that gets synchronized automatically each night. I actually have a folder in the same CasperShare folder for the database backups to save to as well so they too get replicated to the other server.

In theory, if my primary server bit the dust I should be able to run the JSS Setup Util against the second server, get it installed, then install the most recent nightly JSS Backup already saved up to the server, update the DNS pointer and it's done. Might need to fiddle with user accounts and permissions for the file share as well. Shouldn't take more than 10 minutes though.

Someone let me know if my logic is off here. I know I brought up this discussion before as well.

Craig E

milesleacy
Valued Contributor

Craig's setup sounds great. If you use LDAP (OD, AD or other) accounts in
your JSS, you can avoid any account issues.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

tlarkin
Honored Contributor

I have an ODM back up, that is sync'd and is set to a replica. In the
case of failure I would demote the ODM to a stand alone via server
admin, and promote the replica to the Master server. It is a server
that just sits there and does nothing besides sync LDAP.

For my casper servers, I would just load the JSS on one of my xserve
distribution points and then create a policy that edits the
/etc/jamf.conf and points it to the new JSS master while the other one
is being worked on.

Not applicable

I've got a similar setup to Craig, but I have 3 DPs (one xserve and two g5 powermacs running client) that i've setup a cron job to copy the nightly backups to. In case of failure we just run Setup Util on the secondary server and import the latest nightly and then we still have 3 distro points while we fix the other server.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

talkingmoose
Moderator
Moderator

So far, I've heard a lot about recovering from server failures but nothing
really yet about Disaster Recovery, which assumes a natural or man-made
disaster to infrastructure.

Copying/replicating/moving information from one server to another locally is
ideal for when servers fail but what about when tornados or terrorists
strike and destroy the entire site?

True Disaster Recovery needs to include methods for securely moving and
maintaining data offsite and having hardware available (renting if
necessary) to set up the server(s) again. It also needs to include the
business's tolerance for downtime. For some this could be a week and for
others this could be just a few hours. For Casper Suite this means you not
only have to back up the JSS but also your repository, which in our case is
several GB.

This is especially tricky to do if you don't have a second site in your
organization. However, if you do then copying/replicating/moving to a second
site that can assume the core responsibilities of the first site would be
ideal.

Single site companies may benefit from having a service in the cloud for
storing encrypted data. This isn't ideal but it would be the easiest to
automate. A firewire hard drive that is synced daily and taken home by a
company IT admin might do just as well depending on the distance between
work and home.

--

bill

William M. Smith, Technical Analyst
MCS IT
Merrill Communications, LLC
(651) 632-1492

milesleacy
Valued Contributor

When I discuss DR, I am assuming that any "DR box" exists at a secondary
location.
Having a DR site, or a general DR plan is a big issue, especially for for
smaller, single-site organizations.

Moving backups to an off-site location is part of any worthwhile backup
strategy, and I generally assume this is being done. There
are services that will handle this for you, or in the case of a small
organization, having an employee take backup media home with them could be a
workable solution.

Getting a co-located server or servers can provide a DR site without the
expense of maintaining a second facility.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

ernstcs
Contributor III

You are very right in that it really does mean something that is off-site. Right now we don't really have that for anything we have on our campus that I'm aware, although we know we need to do that. We are starting to partner with one of our neighbor universities.

Playing the odds game right now, the two servers are in two different buildings on-campus. The likelyhood is not there that something will happen, but I imagine if both these locations are gone I'll have more important things to worry about...

So, I do agree with you, and it could be as simple as another system sitting at another institution doing nightly or weekly syncs.

Craig E