|
concept for backup server replication
2008-03-05 22:01:23
This idea hit me while I was cross-country skiing through the woods this
last weekend (one way of renewing and reviving one's mental capacities
;-) gliding silently on 30 year old Norwegian wooden skis [Bonna 1800]
on packed powder under spruce-fir ).
Anyway, I'm wondering if anyone else has done this, or if anyone sees
any issues with it.
I have two departments that, for budgetary & other reasons, each need
their own separate backup server. One is still trying to come up with
the pieces of money. My intention has been to have them each back up the
other. They will be essentially identical. Same tape library, etc.
Two things struck me (last weekend). One is that I could have a job
running after the backup that would grab the relevant portion of the
amanda home directory and rsync it to the other server (I'm already
archiving the configuration this way). Suppose one server is using a
configuration for bio-daily, and the other is using a configuration for
geo-daily. Each server would have both configurations but only use its
own. After the geo server completed its amanda run it would rsync the
geo-daily configuration (with its indexes and logs) over to the bio
server. The bio server would rsync its bio-daily configuration to the
geo server after completing its backup. Now, since the tape libraries
and tape drives are identical, and I have the configuration, including
indexes, for the other server's backups, I can do a recovery on the bio
server for something that was backed up on the geo server. All I need is
the tape.
The second thing that occured to me is that the internal drives in all
my departmental servers are an identical type of hot swappable drive.
So, rather than do a disaster recovery over the net, I can put a drive
into the backup server I'm going to do the recovery from, recover all
the partitions on that drive locally on the backup server, install
bootblocks if necessary, umount all partitions, pull the drive, and move
it to the server that needs recovering (these are all Sun Enterprise
servers).
That would result in my backup servers being doubly backed up (each
backs up itself and the other), redundant (each can function as the
other), and easily recoverable. It also means, in a pinch, I could be
doing twice the volume of recovery by using both servers (e.g. server x
in bio gets totally fried, boot drive gets recovered in bio backup
server while data drive is recovered in geo backup server -- obviously
have to be using different tapes, but just as an example). This seems
rather obvious, but hadn't occurred to me because I haven't had to face
any disaster recoveries yet. I have built systems on one machine (A) and
then moved the drives into another machine (B) to minimize the downtime
of upgrading the machine (B) when the OS and all the software was being
upgraded and reconfigured.
Comments, criticisms, suggestions welcome.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
|
| <Prev in Thread] |
Current Thread |
[Next in Thread>
|
- concept for backup server replication,
Chris Hoogendyk <=
|
|
|
