Hi all,

I have an Informix DB server where in backups is taken to a file using
ontape utility.
Total size is around 330 GB. Unix Large files enabled here. Backups
are successful using ontape.
Customer not willing to invest on onbar/veritas solution.

My question: Is there a limit for taking backup to file?
I can't test the restore. Will the restore successful if required?

Backup takes around 2 days to finish. How to make the backup complete
faster?


Thank you,

With Best regards,
Jo

Hi,

large file (> 2 GB) support for utilities (ontape, onunload/onload,
dbexport/dbimport, etc.) depends somewhat on the version of
IDS and in some versions even on the OS platform.

I think in IDS 9.40 and newer, large file support is implemented
on all platforms, at least the UNIX and Linux flavours.

With large file (> 2 GB) support, 330 GB should be safe.

With this size of data/backup, you may want to look into
external backup/restore and the mirror-splitting method.
I described this with some more detail in a developerWorks
article:

http://www.ibm.com/developerworks/db...rer/index.html

in section "External backup and advanced storage techniques".

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland GmbH
Chairman of the Supervisory Board: Hans Ulrich Märki
Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
Diemer
Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940


informix-list-bounces (AT) iiug (DOT) org wrote on 08.11.2007 14:43:43:

Martin Fuerderer wrote:
If you are gzip'ing the file then lots of smaller files seems to give a
shorter overall backup time i.e you can gzip 10x 2GB faster than you can
gzip 1x 20GB.


--
Paul Watson
Tel: +1 913-400-2620
Mob: +1 913-387-7529
Web: www.oninit.com

Failure is not as frightening as regret.
If you want to improve, be content to be thought foolish and stupid.

Martin Fuerderer wrote:
If you are gzip'ing the file then lots of smaller files seems to give a
shorter overall backup time i.e you can gzip 10x 2GB faster than you can
gzip 1x 20GB.


--
Paul Watson
Tel: +1 913-400-2620
Mob: +1 913-387-7529
Web: www.oninit.com

Failure is not as frightening as regret.
If you want to improve, be content to be thought foolish and stupid.

On 8 Nov, 15:08, Paul Watson <p... (AT) oninit (DOT) com> wrote:
Also be mindful of where your database and backup storage space are
located on the server's storage subsystem if you are really interested
in improving the
backup's performance as using the same controller / disks to do the
disk backup and compression as you are using for the database itself
will cause more I/O contention.

Make sure your I/O is monitored at an OS level to ensure you give
yourself the best possible chance of decreasing the backup window.

I hope this helps.

On Nov 8, 8:43 am, Jo <joseph... (AT) gmail (DOT) com> wrote:
This makes a daily backup kind of hard to do.

Do you have a SAN? I have heard about and read a case study (but have
not done it) where a company would

onmode -c block
snapshot the disk space Informix is using
onmode -c unblock

You can then use the snapshot to do a backup or as your backup.
Oh Martin has more detail on this.