On 07/ 7/12 11:29 AM, Brian Wilson wrote:
On 07/ 6/12 04:17 PM, Ian Collins wrote:
On 07/ 7/12 08:34 AM, Brian Wilson wrote:
Hello,
I'd like a sanity check from people more knowledgeable than myself.
I'm managing backups on a production system. Previously I was using
another volume manager and filesystem on Solaris, and I've just switched
to using ZFS.
My model is -
Production Server A
Test Server B
Mirrored storage arrays (HDS TruCopy if it matters)
Backup software (TSM)
Production server A sees the live volumes.
Test Server B sees the TruCopy mirrors of the live volumes. (it sees
the second storage array, the production server sees the primary array)
Production server A shuts down zone C, and exports the zpools for
zone C.
Production server A splits the mirror to secondary storage array,
leaving the mirror writable.
Production server A re-imports the pools for zone C, and boots zone C.
Test Server B imports the ZFS pool using -R /backup.
Backup software backs up the mounted mirror volumes on Test Server B.
Later in the day after the backups finish, a script exports the ZFS
pools on test server B, and re-establishes the TruCopy mirror between
the storage arrays.
That looks awfully complicated. Why don't you just clone a snapshot
and back up the clone?
Taking a snapshot and cloning incurs IO. Backing up the clone incurs a
lot more IO reading off the disks and going over the network. These
aren't acceptable costs in my situation.
So splitting a mirror and reconnecting it doesn't incur I/O?
The solution is complicated if you're starting from scratch. I'm
working in an environment that already had all the pieces in place
(offsite synchronous mirroring, a test server to mount stuff up on,
scripts that automated the storage array mirror management, etc). It
was setup that way specifically to accomplish short downtime outages for
cold backups with minimal or no IO hit to production. So while it's
complicated, when it was put together it was also the most obvious thing
to do to drop my backup window to almost nothing, and keep all the IO
from the backup from impacting production. And like I said, with a
different volume manager, it's been rock solid for years.
So, to ask the sanity check more specifically -
Is it reasonable to expect ZFS pools to be exported, have their luns
change underneath, then later import the same pool on those changed
drives again?
If you were splitting ZFS mirrors to read data from one half all would
be sweet (and you wouldn't have to export the pool). I guess the
question here is what does TruCopy do under the hood when you re-connect
the mirror?
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
