Hi Colin
I really like your idea, if I may twist it just a bit. Instead of solving
the problems of mounting one LUN on two different systems at the same time,
instead insert the idea of taking a snapshot of the primary volume, and
mounting this snapshot on the secondary/backup server. This works great, is
supported, and isn't inherently dangerous. As you said, this removes the
burden of performing the backup from the application server.
But wait, there's more: you can perform your backups on the
secondary/backup system, using the snapshot, and still have NetWorker
catalog the backup as having come from the primary system. How? By
exploiting standard features of the 'save' command that allow you to specify
the nodename and 'saveset' (=source LUN/partition of the backup).
You mentioned that you are using an EMC CLARiiON FCxxxx array. If that
happens to be the EMC FC4700 array, then such a deal I have for you! EMC
and Legato teamed to create "NetWorker PowerSnap(tm) Module for Oracle for
EMC CLARiiON(tm)" (http://www.legato.com/products/powersnap/clariion.cfm),
which integrates EMC CLARiiON's SnapView technology with the idea that you
have of tasking some other server to actually perform the backup. This new
product became available last quarter, and is currently for sale from
Legato.
In addition, EMC has begun making available software products that leverage
storage array features to accomplish backups. The first two for CLARiiON
storage systems, 'CLARiiON Exchange Integration Module' and 'CLARiiON SQL
Integration Module', are currently available through EMC sales channels.
You'll find a white paper describing the 'CLARiiON Exchange Integration
Module' at http://www.emc.com/pdf/products/clariion/h684_xchange2k_san.pdf.
Sorry for the EMC plug, but I include this to illustrate the kinds of
exciting techniques that are becoming available.
Hope this helps, and thanks for asking the question!
tl
Terry Lemons
CLARiiON Application Solutions Engineering
EMC²
where information lives
4400 Computer Drive, MS D239
Westboro MA 01580
Phone: 508 898 7312
Email: Lemons_Terry AT emc DOT com
-----Original Message-----
From: Stuckless, Colin 709 778-3815 [mailto:cstuckless AT PETRO-CANADA DOT CA]
Sent: Thursday, October 31, 2002 12:34 AM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: [Networker] "LAN free" backup with Legato (but no Celestra)
For those folks with file servers and backup servers / storage
nodes sitting on a SAN...
Since Legato supports directed restores, for an environment
of all Solaris servers, is it feasible to use LUN masking to
make your volumes viewable to both your file server (read/write)
and your backup server (mounted read only), and have the
backup server consider these files as it's own? I.E. the
indexes would appear to belong to the backup server, but
in fact you would always do directed restores back to the file
server, since you can only mount the filesystem read/write
on one box to prevent filesystem corruption.
Conceptually, it seems like this could work. Bare metal
recovery might pose a challenge, but for simple SDS mirrored
OS disks, having a root disk ufsdump handy for such scenarios
isn't such a bad thing anyway. I'm more concerned about the
1TB+ data volumes and avoiding the hassle of setting up
single or multi-gigabit data paths to try to keep the tape
drives streaming and the backup windows manageable.
It's basically the same idea as putting your tape library and
file services on the same box connected to the disk, but
without the bad dependencies that creates. Since the backup
server only needs read access to perform the backup (indexes
would be maintained separate from the SAN volumes in question)
what risk (if any) exists in allowing concurrent read/write
and read-only mounts of the same volume on two different Solaris
boxes? Will a SAN switch (assume Brocade) and EMC FC-array
(assume Clariion) even allow it?
I apologise in advance for the lengthy disclaimer that will no
doubt be attached to this message.
Regards,
Colin Stuckless
cstuckless AT petro-canada DOT ca
Unix/G&G Support Specialist
********************
This email communication is intended as a private communication for the sole
use of the primary addressee and those individuals listed for copies in the
original message. The information contained in this email is private and
confidential and if you are not an intended recipient you are hereby
notified that copying, forwarding or other dissemination or distribution of
this communication by any means is prohibited. If you are not specifically
authorized to receive this email and if you believe that you received it in
error please notify the original sender immediately. We honour similar
requests relating to the privacy of email communications.
Cette communication par courrier électronique est une communication privée à
l'usage exclusif du destinataire principal ainsi que des personnes dont les
noms figurent en copie. Les renseignements contenus dans ce courriel sont
confidentiels et si vous n'êtes pas le destinataire prévu, vous êtes avisé,
par les présentes que toute reproduction, tout transfert ou toute autre
forme de diffusion de cette communication par quelque moyen que ce soit est
interdit. Si vous n'êtes pas spécifiquement autorisé à recevoir ce courriel
ou si vous croyez l'avoir reçu par erreur, veuillez en aviser l'expéditeur
original immédiatement. Nous respectons les demandes similaires qui
touchent la confidentialité des communications par courrier électronique.
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
