--0__=86256A55007A559F8f9e8a93df938690918c86256A55007A559F
Content-type: text/plain; charset=us-ascii
Sorry, I don't want to mislead anyone.
The restore I mentioned in #1 that requires an alternate server restore is
only if you want to do the restore through the attached Storage Unit (e.g.
restoring the entire partition during a DR).
For normal restores you don't need this. Whether you are doing a restore from
Node A or Node B it is still a restore to a client (Alias1). If Node A owns
Alias 1, the restore from Node A to Alias 1 will be local (sort of... it will
still go through the network redirector on Node A, but won't go out over the
wire). If Node A owns Alias 1 and the restore is from Node B to Alias 1, it
will go over the network like a normal client/server restore. This works fine
for every day restore requests.
- Scott
Scott A
Kendall/LAKE/HPD/ABBOTT@ABBOT To: "Lundy, Mark"
<mlundy02 AT sprintspectrum DOT com>
T cc: "'Veritas
Support List Server'"
Sent by: <veritas-bu AT
mailman.eng.auburn DOT edu>
veritas-bu-admin AT mailman DOT eng. Subject:
Re: [Veritas-bu] Backing up Virtual Servers
auburn.edu
05/23/2001 04:52 PM
This works well in an active/active configuration. I have done something
similar before. One class for the cluster nodes with a file list of C: or C:
& System_State: for Win2K. And then a separate class for each alias. If you
have more than one alias in a cluster, e.g. active/active cluster, create a
class for each alias. If you have more than one cluster you can keep using
the cluster node class for all of the clusters.
This creates a lot of classes, but there are two reasons for doing this:
1.) During restores you don't have to know which cluster node owned the
alias. If you back up the disk (e.g. your E: & F:) through the cluster node
and then a failover occurs, then a few days later you move the resource group
back to the first node the restore can be really ugly. You may have to
restore the Full and a few Incrementals from node A, then a few Incrementals
from node B, then a few more Incrementals from node A.
Instead, with the above scenario and the separate alias class, if node A owned
the alias and node B had owned it for some time during the period you are
going to restore from, you just need to setup for an alternate media server
restore (media host override from node B to node A). The backup/restore
window shows you all of the files in one window (regardless of the owning
nodes) and the alternate server restore takes care of any files coming from
when node B owned the alias.
2.) If you are using the cluster node as a media server with an on-demand
Storage Unit, you can select the appropriate Storage Unit for that alias (the
preferred owner of that resource group within the cluster). Another alias on
the cluster may have the other node as the preferred owner of the resource
group and will use the on-demand Storage Unit configured on the other node.
When an alias is not owned by the server that hosts its class's Storage Unit,
the backup will still work if you have the server lists configured properly,
but it will go over the network instead of being local.
If you are only backing up an active/passive cluster and this is a media
server, you may want to look at using two classes, but having the alias's
class use a Storage Unit that belongs to a Failover Media Server instead of a
Storage Unit that belongs to one of the nodes. Failover Media Servers are
covered in the back of the Admin guide. This would keep you from having to
setup for an alternate server restore when restoring stuff from the alias.
- Scott
"Lundy, Mark"
<mlundy02 AT sprintspectrum DOT com> To:
"'Veritas
Support List Server'"
Sent by:
<veritas-bu AT mailman.eng.auburn DOT edu>
veritas-bu-admin AT mailman DOT eng. cc:
auburn.edu Subject:
[Veritas-bu] Backing up Virtual Servers
05/23/2001 02:24 PM
We have an application that wants their clustered WindowsNT environment
backed up by us creating two separate classes.
Class 1 contains the two physical server, A and B with a file list
containing only the "C:" drive. Class 2 contains the virtual server C with
a file list of common drives, "E:" and "F:"
Is this the best way to set these up? What would you/have you done to back
up a cluster? TIA.
-
Mark W. Lundy
I.T. Recovery Management
Work: 816.965.1131
FAX: 816.965.1042
<mailto:mlundy02 AT sprintspectrum DOT com> mlundy02 AT sprintspectrum DOT com
(See attached file: SprintLogo.gif)
(See attached file: SprintLogo.gif)
--0__=86256A55007A559F8f9e8a93df938690918c86256A55007A559F
Content-type: image/gif;
name="SprintLogo.gif"
Content-Disposition: attachment; filename="SprintLogo.gif"
Content-transfer-encoding: base64
R0lGODdhbAAbAPcAAAAAAAAAVQAAqgAA/wAkAAAkVQAkqgAk/wBJAABJVQBJqgBJ/wBtAABtVQBt
qgBt/wCSAACSVQCSqgCS/wC2AAC2VQC2qgC2/wDbAADbVQDbqgDb/wD/AAD/VQD/qgD//yQAACQA
VSQAqiQA/yQkACQkVSQkqiQk/yRJACRJVSRJqiRJ/yRtACRtVSRtqiRt/ySSACSSVSSSqiSS/yS2
ACS2VSS2qiS2/yTbACTbVSTbqiTb/yT/ACT/VST/qiT//0kAAEkAVUkAqkkA/0kkAEkkVUkkqkkk
/0lJAElJVUlJqklJ/0ltAEltVUltqklt/0mSAEmSVUmSqkmS/0m2AEm2VUm2qkm2/0nbAEnbVUnb
qknb/0n/AEn/VUn/qkn//20AAG0AVW0Aqm0A/20kAG0kVW0kqm0k/21JAG1JVW1Jqm1J/21tAG1t
VW1tqm1t/22SAG2SVW2Sqm2S/222AG22VW22qm22/23bAG3bVW3bqm3b/23/AG3/VW3/qm3//5IA
AJIAVZIAqpIA/5IkAJIkVZIkqpIk/5JJAJJJVZJJqpJJ/5JtAJJtVZJtqpJt/5KSAJKSVZKSqpKS
/5K2AJK2VZK2qpK2/5LbAJLbVZLbqpLb/5L/AJL/VZL/qpL//7YAALYAVbYAqrYA/7YkALYkVbYk
qrYk/7ZJALZJVbZJqrZJ/7ZtALZtVbZtqrZt/7aSALaSVbaSqraS/7a2ALa2Vba2qra2/7bbALbb
Vbbbqrbb/7b/ALb/Vbb/qrb//9sAANsAVdsAqtsA/9skANskVdskqtsk/9tJANtJVdtJqttJ/9tt
ANttVdttqttt/9uSANuSVduSqtuS/9u2ANu2Vdu2qtu2/9vbANvbVdvbqtvb/9v/ANv/Vdv/qtv/
//8AAP8AVf8Aqv8A//8kAP8kVf8kqv8k//9JAP9JVf9Jqv9J//9tAP9tVf9tqv9t//+SAP+SVf+S
qv+S//+2AP+2Vf+2qv+2///bAP/bVf/bqv/b////AP//Vf//qv///yH5BAAAAAAALAAAAABsABsA
QAj/AP8JHEiwoMGD5eQdXMiwocOHECNGLEcInMWLGDH6Uyixo8ePIAkCA5Sx5MV4zR4CAPBvpUCW
LWHGfMlyZU2ZA3HOfMlzZ0iH4OL9HEq06MNyiEpuNMq0qVOJLlsajZoz582eM3UWHVkS5UebT8OG
pGhxqdizaP+RNVmWY9q3cCHa1LqQqsq5MsHmBRs3Il+9NKO6BOzTql66hYuCIsk2aKuGeLPCtBtZ
Mk6+BOcGtut0scV4j/uKHk26dEOKZk2rhohUo9vVsAm2Npk6turZjcHVti1Wnz15wOO1I4cut3GL
vI3quqcveLvnx42/FuwXcWKpkmlq53xQH3Pn7dhFVs/9OrD5wYNjakbPebJmg9wZNpcn/Hm58SZB
O0Tfk6rgydoVpFN8ASrGWG761WVVdpRdpV56C2bWYIFGcZVfaFBZl1xIFn6G4Ya2gQNGO0KBaOKJ
RgUEADs=
--0__=86256A55007A559F8f9e8a93df938690918c86256A55007A559F--
|
