IDS Forum

RE: Snapshot Backup

Posted By: Habichtsberg, Reinhard
Date: Thursday, 14 April 2011, at 11:26 a.m.

In Response To: Re: Snapshot Backup (Art Kagel)

Art wrote:

> The only reason I see for using external archives is that they can be
faster
> than ontape/onbar for very large servers. This is what Rheinhardt is
trying
> to describe, using mirror breaking or incremental copies as external
> archives.

Exactly that is the reason we are using those mirror-, clone-, snapshot
or whatever technique. We have an onbar tape backup additional. Another
word to the spaceless snapshots: That technique works only on the same
SAN storage. If you want a clone on a remote storage system at a second
location you have to create a clone first. Futher snaps to that clone
are incremental.

Reinhard.

> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Art
> Kagel
> Sent: Thursday, April 14, 2011 4:57 PM
> To: ids@iiug.org
> Subject: Re: Snapshot Backup [23421]
>
> 11.50 or 11.70 is the same. External archives have been possible since
7.31
> and actively supported (through the addition of log only restores)
since
> 10.00 or 11.10 (I forget).
>
> I mean using ontape or onbar to perform a level 0 archive to disk. We
> typically have our clients keep two archives and the logical logs
since both
> on disk. Prior archives and logical log backups are included in the
> filesystem archives taken offsite on removable media and can be
retrieved if
> a restore to before the 2nd newest archive is required.
>
> The only reason I see for using external archives is that they can be
faster
> than ontape/onbar for very large servers. This is what Rheinhardt is
trying
> to describe, using mirror breaking or incremental copies as external
> archives.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own
opinions and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other
> organization with which I am associated either explicitly, implicitly,
or by
> inference. Neither do those opinions reflect those of other
individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Thu, Apr 14, 2011 at 10:42 AM, Konikoff, Robert W Mr CIV US USA AMC
<
> rob.konikoff@us.army.mil> wrote:
>
> > Art:
> >
> >
> >
> > When you say, '... archive to a local disk (or SAN)...' do you mean
like a
> > level 0 sent to disk or copying the SAN space that the database
resides in,
> > in real time?
> >
> >
> >
> > Also, the future platform is 11.7 on HPUX 11.iv3
> >
> >
> >
> > I originally thought 11.5, but it's 11.7; does that make a big
difference?
> >
> >
> >
> > Rob
> >
> >
> >
> > *From:* Art Kagel [mailto:art.kagel@gmail.com]
> > *Sent:* Thursday, April 14, 2011 10:09 AM
> > *To:* ids@iiug.org
> > *Cc:* Konikoff, Robert W Mr CIV US USA AMC
> > *Subject:* Re: Snapshot Backup [23416]
> >
> >
> >
> > Yes. A couple of additional points:
> >
> > - The best SAN snapshots keep a local log of changes since the last
> > snapshot and just send the changes to the remote copy when you
enable the
> > snapshot. In this case the snapshots are rather fast, however, there
is
> > additional bandwidth and processing power of the SAN itself being
used up to
> > keep track of the changes.
> > - The best SAN snapshots can stream changes to the remote in near
> > real-time. This makes the snapshot even faster as the SAN just needs
to
> > send the last sync packets and a 'checkpoint' of sorts to the remote
> > triggering a local application of the incremental changes to the
previous
> > snapshot to bring it up-to-date. The downside is that this method
uses lots
> > of WAN bandwidth constantly rather than in a burst at snapshot time
so it
> > may require additional dedicated WAN resources beyond what you need
for
> > system networking to the remote site.
> > - If your SAN does not support either of these "instant" snapshot
> > optimizations you will need a VERY FAST link to the remote SAN in
order to
> > not block the Informix instance for so long that transactions must
be
> > blocked because the logical and physical log spaces have filled up.
> > - In addition to not archiving unallocated space, an Informix
archive
> > (using ontape or onbar) only copies pages that are actually used for
data,
> > indexes, and server overhead. Pages within the chunks that are not
used are
> > not archived. Also not archived are tempdb dbspace chunks since
their
> > contents are by definition temporary and never need to be restored.
> >
> > How and why does management think that using Informix archiving
software is
> > more expensive than using SAN snapshot or SAN replication to archive
the
> > instance? I've heard the argument about SAN replication versus using
> > HDR/MACH11 replication, but have not heard a strong argument versus
> > archives.
> >
> > At most sites our clients archive to a local disk (or SAN) and then
use
> > rcp/scp to move the archive file(s) to a remote system for safety
> > (alternatively you could write the archive to a filesystem that the
SAN is
> > replicating to a remote twin). Finally the archive file(s) are
picked up on
> > both the local and remote systems in the normal filesystem archiving
> > overnight to be send offsite. This is safe and efficient, faster
than tape,
> > uses less storage on the remote system than snapshots, and it is all
done
> > without disturbing the operations of the server at all.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own
opinions
> > and do not reflect on my employer, Advanced DataTools, the IIUG, nor
any
> > other organization with which I am associated either explicitly,
implicitly,
> > or by inference. Neither do those opinions reflect those of other
> > individuals affiliated with any entity with which I am affiliated
nor those
> > of the entities themselves.
> >
> >
> > On Thu, Apr 14, 2011 at 9:42 AM, Konikoff, R....
<rob.konikoff@us.army.mil>
> > wrote:
> >
> > We are wrestling with SAN level backup strategies now.
> >
> > Our next platform:
> > HP-UX 11.iv3
> > IDS 11.5
> >
> > I want transaction level strategy for offsite disaster recovery, but
> > 'management' thinks it costs too much. They are leaning towards SAN
copies.
> >
> > Check me out here... To synthesize this conversation then on SAN
level
> > archiving:
> >
> > Informix calls SAN level archives an external archive. To do this,
you have
> > to checkpoint the Informix instance and block new transactions from
being
> > written to disk while the SAN copy is being written. Then once the
copy is
> > complete, release the block. This is done as follows:
> >
> > 1. onmode -c block
> >
> > 2. snapshot
> >
> > 3. onmode -c unblock
> >
> > In this case, the snapshot can be 3rd party software. INFORMIX
doesn't do
> > 'snapshots' since they take more space than a level 0 archive.
Clones will
> > copy all of the database's chunks, and even the array spaces that
are not
> > yet allocated to the instance. Vendor products that do database
snapshots
> > may be more efficient in taking only the used space, with minimal
overhead,
> > but that requires product evaluation to determine the overhead and
copy
> > parameters.
> >
> > Am I tracking?
> >
> > Thanks...
> >
> > Rob
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
Of
> > Habichtsberg, Reinhard
> > Sent: Thursday, April 14, 2011 3:55 AM
> > To: ids@iiug.org
> > Subject: Re: Snapshot Backup [23415]
> >
> > What you are talking about is what I would call a clone. A snapshot
in
> > contrast taken with the means of some of the storage distributors
takes
> > only the space of the administrative overhead. That is minimal.
Simply
> > spoken the snapshot points to the same blocks as the original.
Updates
> > of the original will be only reflected there because the snap blocks
> > will not be overwritten but new blocks and pointers will be created.
> > Only the differences between original and snapshot will consume
space.
> >
> > The snapshot can be used as external backup as said by the
foreposters.
> >
> > I have to confess that I have no practical knowledge with that
spaceless
> > snapshots. We will implement a new SAN soon so I had to look into
some
> > features of storage technology of today.
> >
> > Reinhard.
> >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
Of
> > John
> > > Miller iii
> > > Sent: Thursday, April 14, 2011 8:52 AM
> > > To: ids@iiug.org
> > > Subject: Re: Snapshot Backup [23414]
> > >
> > > Snapshot backup generally consume allot more space than an
Informix
> > > Level 0 backup. This is because Informix understand what is free
space
> > > both inside and outside of tables and does not back this up. That
> > being
> > > said there are many fancy disk based snap/flash technologies which
> > > can do some pretty impressive work.
> > >
> > > Yes you can apply logical logs after executing a snapshot backup
> > > (or as Informix calls it an External Backup)
> > >
> > > John F. Miller III
> > > STSM, Embedability Architect
> > > miller3@us.ibm.com
> > > 503-578-5645
> > > IBM Informix Dynamic Server (IDS)
> > >
> > > ids-bounces@iiug.org wrote on 04/13/2011 03:45:21 PM:
> > >
> > > > From:
> > > >
> > > > "SHAHZAD SALAM KASI" <skasi@i2cinc.com>
> > > >
> > > > To:
> > > >
> > > > ids@iiug.org
> > > >
> > > > Date:
> > > >
> > > > 04/13/2011 03:46 PM
> > > >
> > > > Subject:
> > > >
> > > > Re: Snapshot Backup [23411]
> > > >
> > > > Sent by:
> > > >
> > > > ids-bounces@iiug.org
> > > >
> > > > Thanks for the response.
> > > >
> > > > Is Snapshot backup consumes less space than Level-0 backup ?
> > > > Also, can we apply logs after re-storing using Snapshot backup ?
> > > >
> > > > What is the command to take snapshot backup ?
> > > >
> > > > Thanks.
> > > >
> > > >
> > > >
> > >
> > >
> >
************************************************************************
> > *******
> > >
> > > > Forum Note: Use "Reply" to post a response in the discussion
forum.
> > > >
> > >
> > >
> > >
> >
************************************************************************
> > *******
> > > Forum Note: Use "Reply" to post a response in the discussion
forum.
> >
> >
> >
************************************************************************
****
> > ***
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
************************************************************************
*******
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
>
> --bcaec54862f017cbb904a0e221c3
>
>
>
************************************************************************
*******
> Forum Note: Use "Reply" to post a response in the discussion forum.

Messages In This Thread

• Snapshot Backup
  SHAHZAD SALAM KASI -- Wednesday, 13 April 2011, at 5:33 p.m.
  • Re: Snapshot Backup
    Art Kagel -- Wednesday, 13 April 2011, at 6:35 p.m.
    • Re: Snapshot Backup
      SHAHZAD SALAM KASI -- Wednesday, 13 April 2011, at 6:45 p.m.
      • Re: Snapshot Backup
        Madison Pruet -- Wednesday, 13 April 2011, at 6:53 p.m.
      • Re: Snapshot Backup
        Art Kagel -- Wednesday, 13 April 2011, at 7:52 p.m.
      • Re: Snapshot Backup
        John Miller iii -- Thursday, 14 April 2011, at 2:51 a.m.
        • Re: Snapshot Backup
          Habichtsberg, Reinhard -- Thursday, 14 April 2011, at 3:54 a.m.
          • RE: Snapshot Backup
            Konikoff, Robert W Mr CIV US USA AMC -- Thursday, 14 April 2011, at 9:42 a.m.
            • Re: Snapshot Backup
              Art Kagel -- Thursday, 14 April 2011, at 10:09 a.m.
              • Re: Snapshot Backup
                David Zinder -- Thursday, 14 April 2011, at 10:59 a.m.
                • Re: Snapshot Backup
                  Art Kagel -- Thursday, 14 April 2011, at 2:19 p.m.
                  • RE: Snapshot Backup
                    Bruce Simms -- Thursday, 14 April 2011, at 2:53 p.m.
            • RE: Snapshot Backup
              Habichtsberg, Reinhard -- Thursday, 14 April 2011, at 10:39 a.m.
              • RE: Snapshot Backup
                Konikoff, Robert W Mr CIV US USA AMC -- Thursday, 14 April 2011, at 10:49 a.m.
            • RE: Snapshot Backup
              Konikoff, Robert W Mr CIV US USA AMC -- Thursday, 14 April 2011, at 10:44 a.m.
            • Re: Snapshot Backup
              Art Kagel -- Thursday, 14 April 2011, at 10:56 a.m.
              • RE: Snapshot Backup
                Habichtsberg, Reinhard -- Thursday, 14 April 2011, at 11:26 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.