Snapshot Backup
A user asked whether IBM Informix (on Solaris) supports snapshot backups. The answer: Informix itself has no snapshot command — this is done as an "external backup" using SAN/disk snapshot or clone tools, bracketed by 'onmode -c block' (forces a checkpoint and blocks writes), the snapshot/pairsplit, then 'onmode -c unblock'. Logical logs can afterwards be applied with ontape -l or the onbar equivalent. Participants noted full clones/shadow images consume far more space than an ontape/onbar level-0 (which skips free pages, unallocated space and temp dbspaces), whereas copy-on-write SAN snapshots only store differences and split in seconds, keeping the block short. Art Kagel also discussed SAN replication options and argued conventional archives copied offsite are usually cheaper and less disruptive. No single decision was recorded for the second poster's DR plan.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, We are using IDS FC6 & IDS FC7 on Solaris Sparc. I want to know whether we can take (Snapshot) backup in Informix or not ? Can we use the complete features of Snapshot backup in Informix ? Thanks.
Are you referring to disk or SAN level archiving? If so, Informix calls
this an external archive. You can do this but you have to checkpoint the
Informix instance and block new transactions from being written to disk
while the snapshot is being written. Then once the snapshot is complete you
can release the block. This is done as follows:
1. onmode -c block
2. snapshot
3. onmode -c unblock
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 Wed, Apr 13, 2011 at 5:33 PM, SHAHZAD SALAM KASI <skasi@i2cinc.com>wrote:
> Hi,
> We are using IDS FC6 & IDS FC7 on Solaris Sparc.
> I want to know whether we can take (Snapshot) backup in Informix or not ?
>
> Can we use the complete features of Snapshot backup in Informix ?
>
> Thanks.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--20cf307f3168f0ffd604a0d46c54
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.
Unless I'm totally crazy, a snapshot backup would always be larger than a lev-0. A snapshot backup would have to backup everything - including empty pages. A online backup would only backup non-empty pages. M.P. From: "SHAHZAD SALAM KASI" <skasi@i2cinc.com> To: ids@iiug.org Date: 04/13/2011 05: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.
Snapshots have to make a complete copy of all of the database's chunks (and
often even parts of the array that are not yet allocated to the instance, so
they take up considerably more space than an Informix archive.
Yes, you can apply the logical logs using ontape -l (or the equivalent onbar
command).
There is no Informix command to take a snapshot. These are not an Informix
operation but usually built into your SAN and each SAN uses a different
command. That is unless I am completely thinking of something different
than what you are thinking of.
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 Wed, Apr 13, 2011 at 6:45 PM, SHAHZAD SALAM KASI <skasi@i2cinc.com>wrote:
> 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.
>
>
--bcaec54862f0230abe04a0d580da
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. >
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.
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.
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.
> > >
> >@@N
Rob
There are many ways to achieve external backups with means of SAN
storage. Currently we do a so called shadow image. The whole space of
your database instances are copied (cloned) once. As a result you have
to halves of a mirror. After all LUNS are in pair you may split the
mirror. From that moment the mirror halves will develop differences. If
you want to use your cloned image as an external backup you may never
ever mount it or use it for another informix instance. If you want to
sychronize your original and backup image you join the mirror halves
again until they are pair. Only the differences will be sychronizised.
Before splitting the mirrors you have to do a blocking checkpoint:
onmode -c block. Then do the pairsplit command. Then release theblocking checkpoint: onmode -c unblock. The pairsplit takes only seconds
if you do it after all LUNS are in pair. So the block of the datebase
server is very short. That is important because otherwise you couldn't
use that technique in a productive environment.
Our future looks a bit different: The shadow image will be replaced by
those snapshots I described before. They won't spend time aside from
some seconds and they won't spend space. Space will be consumed by the
differences that will develop over time. The oftener you create a
snapshot (and delete the previous) the lesser space you will need. I see
a great chance for external backups to be very close-by to the original
without consuming much space.
Sorry, it not very easy for me to express it in English. Hope it's
understandable.
Reinhard.
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Konikoff,
> R....
> Sent: Thursday, April 14, 2011 3:43 PM
> To: ids@iiug.org
> Subject: RE: Snapshot Backup [23416]
>
> 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.
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/
<blockedhttp://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 ?
>
Reinhard:
No problem. Your English is better than most US English speakers :)
Ok, that does make a bit of sense (considering I'm not really an expert in
SAN technology).
Rob
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Habichtsberg, Reinhard
Sent: Thursday, April 14, 2011 10:40 AM
To: ids@iiug.org
Subject: RE: Snapshot Backup [23418]
Rob
There are many ways to achieve external backups with means of SAN
storage. Currently we do a so called shadow image. The whole space of
your database instances are copied (cloned) once. As a result you have
to halves of a mirror. After all LUNS are in pair you may split the
mirror. From that moment the mirror halves will develop differences. If
you want to use your cloned image as an external backup you may never
ever mount it or use it for another informix instance. If you want to
sychronize your original and backup image you join the mirror halves
again until they are pair. Only the differences will be sychronizised.
Before splitting the mirrors you have to do a blocking checkpoint:
onmode -c block. Then do the pairsplit command. Then release theblocking checkpoint: onmode -c unblock. The pairsplit takes only seconds
if you do it after all LUNS are in pair. So the block of the datebase
server is very short. That is important because otherwise you couldn't
use that technique in a productive environment.
Our future looks a bit different: The shadow image will be replaced by
those snapshots I described before. They won't spend time aside from
some seconds and they won't spend space. Space will be consumed by the
differences that will develop over time. The oftener you create a
snapshot (and delete the previous) the lesser space you will need. I see
a great chance for external backups to be very close-by to the original
without consuming much space.
Sorry, it not very easy for me to express it in English. Hope it's
understandable.
Reinhard.
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Konikoff,
> R....
> Sent: Thursday, April 14, 2011 3:43 PM
> To: ids@iiug.org
> Subject: RE: Snapshot Backup [23416]
>
> 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.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
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 its 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.
>
>
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:
>>>>@@
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
> >@@N
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 o
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 i