IDS Forum

RE: Snapshot Backup

Posted By: Bruce Simms
Date: Thursday, 14 April 2011, at 2:53 p.m.

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

You can depending on the san utilities you can make the snapshot/mirror and the issue the onmode -c block command then follow this up with the finish or break of the mirroring and then issue the onmode -c unblock which will gratly reduce the time the system is blocked.

See you at the 2011 IIUG Informix Conference May 15-19, In Overland Park (Kansas City), KS
www.iiug.org/conf

Bruce Simms
IIUG Conference 2011
IIUG Conference Planning Committee

Phone (314) 214-7703
Celll (314) 496-6883
Fax (314) 983-3238
bsimms@iiug.org

-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel
Sent: Thursday, April 14, 2011 1:19 PM
To: ids@iiug.org
Subject: Re: Snapshot Backup [23425]

OK, I don't remember what I told you last time. However, IFF you use onmode
-c block/copy/onmode -c unblock you can successfully restore a disk level
archive, yes, even if users are accessing the server and making updates.
Just make sure that the copies do not take so long that you run out of logs
before unblocking or transactions will start to block.

Personally, unless there is a good reason not to, I prefer to use native
Informix tools for something as critical as an archive. If you are using a
disk copy in addition to ontape, more power to you. I will never dissuade a
properly paranoid DBA. ;-)

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:59 AM, David Zinder <zinder@ztechz.com> wrote:

> Art,
>
> IDS 11.50.FC7IE
> RHEL 5.6
>
> After reading these backup related posts, I have a question. A while
> back I asked the forum about an OS backup/restore of my chunk files vs
> OS backup/restore of my ontape backups. You said to never trust a chunk
> file restore. No one accesses my databases during my backup window.
> Would it be OK to restore my file chunks if I did my backups with
> "onmode -c block", OS chunk file backup, "onmode -c unblock"? I would
> still continue to do ontape backups before the OS backup. Seems to me,
> having two restore options is better than one.
>
> Thanks
> David
>
> On 4/14/2011 10:09 AM, Art Kagel wrote:
> > 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.
> >>
> >>
> > --20cf3071c67ee3662104a0e178fc
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--bcaec54862f093821104a0e4f4c0

*******************************************************************************
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.