Ok I agree with you for non clustered resources but should be
different for clustered resources ! In worst case, if during the week, your
services
are moved to the other cluster node, you will have to backup 3 times same
HDD ?
1X for the real data, 1X with DR of member #1, 1X with DR of member#2.
In a cluster of 4 nodes, as each node may have a different list of
features,
5 time same data ?
Now, something more : the recovery :
if I backup my clustered HDDs together with DR of member 1 and member2
(let's even assume once a month),
assume now member 1 is dead . All are online on member2.
I will have to recover DR of member1, including clustered hdds aged of 1
month THEN last full and
diff of clustered HDDs overwritten by DR of member1... A Joke ?
Should be something to do.
Th
-----Message d'origine-----
De : EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] De
la
part de Michael Leone
Envoyé : mardi 13 mars 2012 13:26
À : NETWORKER AT LISTSERV.TEMPLE DOT EDU
Objet : Re: [Networker] Win2008R2 Cluster & DR-WSB & NSR 7.6.2.3.Build.663
> Why are these cluster-service hdds be part of DR backups ?
>
> Why are they considered as critical by WSB ?
>
> Bug ? Feature ?
>
> Did I miss something somewhere ?
Feature.
It depends on the application, as to whether it decides to register what
directories/disks as "critical". Example: we run Lotus Notes for a mail
server. It is installed on it's own drive E:, since the mail store is on
the order of 400G.
Well, Notes registered itself as a "critical" feature, essential to the
normal operation of this server, and so is included in the
DISASTER_RECOVERY: saveset. And naturally, Notes needs its entire mail
store. So my DR backup is 400+ G. This is *separate* from the backup of E:
drive.
So using saveset ALL gets me 400G of DR, and 400G of drive E: (so the info
is duplicated). But you can't use the DR backup for normal recoveries,
because you can't extract just individual files (yet).
So what I do is have 2 jobs and a SKIP directive. One job lists *just* the
folders on E: (i.e., the mail store), and the other job lists all the
other savesets, excluding the DR):
VSS SYSTEM BOOT:
VSS SYSTEM FILESET:
VSS SYSTEM SERVICES:
VSS USER DATA:
VSS OTHER:
C:
E:
With a SKIP directive to skip the folders enumerated in the other job.
It means I don't get an actual DR backup, but I backup all the data, and I
can recover individual mail files. This is only workable because Notes
still uses an INI file configuration system. So in an actual disaster, we
would re-install Windows and Notes (also on a drive E:), then recover all
the folders on drive E:.
Far from ideal, but the only other way to do is is to backup well over a
TB every day. And since we backup to AFTD device, we couldn't keep our
required 2 days retention on disk (we don't have that much space).
Sounds like you've got a similar problem ...
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
