1. Backup & Restore Load & Unload
Presentation notes go here.
Backup & Restore Load & Unload

2. Backup & Restore What does DBA stands for ? Why a backup ?
Default and Backup for Anything.
Why a backup ?
Disaster Recovery.
High Availability Data Replication (HDR) setup.
Cloning (Testing, development, QA, etc).
Backup and Restore is, too often, either not done at all or not done properly … and commonly not tested until there is an emergency! It isn't just for recovering from disaster but is also used for setting up HDR/RSS secondaries and for cloning a database for use in a test/dev environment.
A recovery system enables you to back up your database server data and later restore it if your current data becomes corrupted or inaccessible. The causes of data corruption or loss can range from a program error to a disk failure to a disaster that damages the entire facility. A recovery system enables you to recover data that you already lost due to such mishaps.
A backup is a copy of one or more dbspaces (also called storage spaces) and logical logs that the database server maintains. You can also back up blobspaces and sbspaces. The backup copy is typically written to a secondary storage medium such as disk, magnetic tape, or optical disk. We recommend that you store the media offline and keep a copy off site if possible.
Important: Database backups do not replace ordinary operating-system backups, which back up files other than Informix database files.

3. Backup & Restore Why a database backup? – Disaster recovery
When a disaster strikes, you need a way to recover the data. The recovery process requires procedures and processes in place ahead of time that allow for data recovery when needed. A backup.
What might cause you a need to recover?
Unintended deletion of a database object (rows, columns, tables).
Unintended deletion of a server object (databases, chunks, dbspace).
Data corruption or incorrect data created.
Hardware failure (such as when a disk that contains chunk files fails).
Database server failure.
Natural disaster.
What to backup ?
Depending on the recovery plans.
No notes needed.

4. Backup & Restore – Disaster Recovery
Goals and Objectives:
How much data loss, if any, is acceptable?
How long can your business function without the data?
How long can your production system be down during a restore?
How much transaction time can be lost?
How much budget is available for a recovery plan?
Recovery strategy requires planning with an understanding of the business critical data, and comprehension of the backup tools available and their capabilities.
The first step in planning your recovery is to outline recovery goals based on the understanding of the business data. Define what is a successful recovery for your system in terms of tolerance for data loss and acceptable time loss. Some key questions that can help you accomplish that can be: (as shown above in the slides)
Knowing the type or usage of data can help you determine how quickly it needs to be recovered. Why was this data backed up to begin with? Here are some reasons for needing the data:
Is this data “business critical”?
Does loss of this data impact my revenue and cash flow?
Does loss of this data impose legal or tax liabilities?
Is this data shared by various business groups?
Is it used for business planning?
Data that impacts revenue may need to be recovered far more quickly than data used for business planning.

5. Backup & Restore – Disaster Recovery
Type –Time
Type:
Knowing the type or usage of data can help you determine how quickly it needs to be recovered.
Why was this data backed up to begin with?
Time:
How much transaction time can be lost?
Can we re-apply the transactions / load data via other means?
Type
Is this data “business critical”?
Does loss of this data impact my revenue and cash flow?
Does loss of this data impose legal or tax liabilities?
Is this data shared by various business groups?
Is it used for business planning?
Data that impacts revenue may need to be recovered far more quickly than data used for business planning.
Time
How much transaction time can be lost? Also, how long might it take to re- enter lost transactions manually? For example, can you afford to re-enter all transactions that occurred over the past four hours?

6. Backup & Restore – Disaster Recovery
Quantity – Distribution:
Quantity
What quantity of data has been lost? (e.g., we lost 25% of our customer profiles).
Distribution
What is the extent of the loss? (e.g., we lost the entire Midwest regional sales figures, but
the East/West coast and international figures are intact).
Quantity and Distribution
How much data can you afford to lose? This decision could depend on the amount of data lost or it could depend on the specific nature of the data lost
Ask the following questions to assist in deciding how often and when you want to
back up the data:
v Does your business have down time where the system can be restored?
v If your system is 24x7 (no down time), is there a non-peak time where a restore
could occur?
v If a restore must occur during a peak period, how critical is the time?
v Which data can you restore with the database server online (warm restore)?
Which data must be restored offline (cold restore)?
v How many storage devices are available to back up and restore the data?.

7. Backup & Restore Disaster Recovery – Right, Fast, or Cheap
There are three ways to implement recovery:
right, fast, or cheap.
Choose the two highest on your priority list. These choices should directly relate to your data and time-loss recovery goals.
Most people will choose the right option as their first priority. The difficult step is to weigh the advantages and disadvantages of speed and cost.
In determining the recovery strategy it is essential to intelligently balance the criticality of different elements of your data.

8. Backup & Restore Recovery strategies and scheduling backups:
Recovery strategy requires planning with an understanding of the business critical data, and comprehension of the backup tools available and their capabilities.
The first step in planning your recovery is to outline recovery goals based on the understanding of the business data.
Define what is a successful recovery for your system in terms of tolerance for data loss and acceptable time loss. Use key questions presented earlier.
Have a recovery checklist in place.
After you determine your recovery goals, create your recovery plan. Develop a recovery plan for multiple levels of failure.
Failure severity Data loss Suggested recovery plan
Small Noncritical data is lost. Restore of the data can wait until a nonpeak time. Use a warm restore.
Medium The data that is lost is Perform a warm restore of this data as soon as possible.
critical for your business
but does not reside in a
critical dbspace.
Large Critical dbspaces are lost. Use a mixed restore to restore the
critical data right away and a warm
restore to restore noncritical data during
off-peak hours.
Disaster All data is lost. Perform a cold or mixed restore as soon as possible.

9. Backup & Restore Recovery planning cycle:
Plan Recovery Goals – Decide what you need.
Select Tools – Decide how you are going to do it.
Implement the Strategy – Test it.
Analyze the Strategy – See how well it meets your requirements.
Tune the Strategy – Refine.

10. Backup & Restore Why a database backup – HDR setting: How it works?
Database Logging (DDL, DML)
Logical log transmission
The need for a backup / restore to set it up
Physical
Logical
HDR as backup solution in itself
Primary
Secondary
HDR maintains two identical IDS server instances on servers with similar configurations and operating systems. HDR employs a log record shipping technique to transfer the logical log records from the primary server to the secondary server. The secondary server is in perpetual roll-forward mode so that data on the secondary server remains current with data on the primary server. The secondary server supports read access to data, allowing database administrators to spread workload among servers.
To create the HDR Secondary server, a Level 0 backup must be taken from the server which will be the Primary server of the pair. This backup must then be used to perform a physical restore to create the HDR Secondary server instance. A logical restore is not used because HDR copies the log data from the Primary to the Secondary as part of standard HDR operations. HDR replication can then be started between the two servers.

11. Backup & Restore Why a database backup – Cloning: Testing DevelopmentQA
etc
Another purpose for using backup and restore is to clone an instance of Informix so that it can be restored to another server for uses such as testing, development and quality assurance assessment.

12. Backup & Restore Informix concepts: Database Server or Instance
Dbspace
Database
Tablespace
Logical Logs
A backup is a copy of one or more dbspaces (also called storage spaces) and logical logs that the database server maintains. You can also back up blobspaces andsbspaces. The backup copy is typically written to a secondary storage medium such as disk, magnetic tape, or optical disk. We recommend that you store the media offline and keep a copy off site if possible.
Important: Database backups do not replace ordinary operating-system backups, which back up files other than IBM Informix database files.
A logical-log backup is a copy to disk or tape of all full logical-log files. The logical-log files store a record of database server activity that occurs between backups. To free full logical-log files, back them up. The database server reuses the freed logical-log files for recording new transactions.
Manual and continuous logical-log backups - A manual logical-log backup backs up all the full logical-log files and stops at the current logical-log file. If you turn on continuous logical-log backup, the database server backs up each logical log automatically when it becomes full. If you turn off continuous logical-log backup, the logical-log files continue to fill. If all logical logs are filled, the database server hangs until the logs are backed up.

13. Backup & Restore rootdbs ONINIT VPs Backup Media sbspace dbs1 dbs2
onconf ig
Emergency
Boot file
ONINIT VPs
rootdbs
reserve pages
online log
Backup Media
sysutils
sysmaster
Physical Log
sbspace
dbs1
dbs2
Logical Logs
You do not always have to back up all the storage spaces. If some tables change daily but others rarely change, it is inefficient to back up the storage spaces that contain the unchanged tables every time that you back up the database server. You need to plan your backup schedule carefully to avoid long delays for backing up or restoring data.
Restriction: Even if you do not specify logging for databases or tables, you need to back up the logical logs because they contain administrative information such as checkpoint records and additions and deletions of chunks. When you back up these logical-log files, you can do warm restores even when you do not use logging for any of your databases.
/informix/rootchunk1
/informix/rootchunk2
/informix/sbck1
/informix/sbck2
/informix/s1ck1
/informix/s1ck2
/informix/s2ck1
/informix/s2ck2

14. Backup & Restore Informix Backup
A backup occurs when all or some server database objects are copied to storage media
Physical
backup
Dbspaces Or
A backup is the process of copying either all or some subset of the server dbspaces and logical log files to a secondary storage location, either disk, tape, or optical device. The backup process ensures that a consistent image of the data is created even while the system is in an online, multi-user mode receiving ongoing transactions.
The Backup process is divided in two components: the physical backup and the logical log backup. The physical backup is the process of backup dbspaces and blobspaces to a storage space with different level of backups. The logical log backup is the process of copying the contents of use logical log files to storage space.
Depending upon the backup utility selected, you may be able to back up a single object, multiple objects, or the entire instance. The ability to back up individual dbspaces or groups of dbspaces allows maximum flexibility to meet business demands. Since dbspaces can contain multiple databases, a single database, a single table, or even a single partition of a table, dbspace backups provide even better than table level granularity for backups and restores.
Logical Logs
Logical
backup

15. Backup & Restore Physical and Logical Backup: Physical Logical
Focuses on current contents of storage spaces (dbspaces, blobspaces, smart blobspaces).
Foundation of all backup and restore operations.
Works on page level.
Backup only used pages.
Logical
Focuses on transactions stored in logical log files.
Backup can be continuous (as log files fill) or manual.
How we can restore as much data as possible, even data updated between backups.
A physical backup backs up just the storage spaces. You can back up specific or all storage spaces.
Using -p for a dbspace backup with ON-Bar will only back up the storage spaces, but it will not start an implicit logical log file backup. Instead, a warning message will be written to the ON-Bar activity log file to let the user know, that log file backup was not initiated. The message will also contain the log unique ID of the latest log file that will be required for a restore of the storage spaces. This is the log file that contains the archive checkpoint of the last dbspace backed up.
A logical-log backup is a copy to disk or tape of all full logical-log files. The logical-log files store a record of database server activity that occurs between backups. To free full logical-log files, back them up. The database server reuses the freed logical-log files for recording new transactions.

16. Backup & Restore Physical Backup
Performed while server is On-Line or Quiescent:
To reduce impact on production.
Off-Line backup is possible, but is not supported because data consistency can’t be guaranteed.
Incremental Backup
To save time and space on backup media.
Backup only the pages that have changed since the last backup.
Three levels:
0 - backup all used pages.
1 - backup all changes since the last level 0 backup.
2 - backup all changes since the last level 1 backup.
You do not always have to back up all the storage spaces. If some tables change daily but others rarely change, it is inefficient to back up the storage spaces that contain the unchanged tables every time that you back up the database server. You need to plan your backup schedule carefully to avoid long delays for backing up or restoring data. To provide a more flexible backup environment, ON-Bar and ontape support the following three backup levels:
Level 0 - Level 0 backs up all used pages that contain data for the specified storage spaces. You need all these pages to restore the database to the state that it was in at the time that you made the backup.
Level 1 - Level 1 backs up only data that has changed since the last level-0 backup of the specified storage spaces. All changed table and index pages are backed up, including those pages with deleted data. The data that is copied to the backup reflects the state of the changed data at the time that the level-1 backup began.
Level 2 - Level 2 backs up only data that has changed since the last level-1 backup of the specified storage spaces. A level-2 backup contains a copy of every table and index page in a storage space that has changed since the last level-1 backup.
Important: If disks and other media are destroyed and need to be replaced, you need at least a level-0 backup of all storage spaces and relevant logical logs to restore data completely on the replacement hardware.

17. Backup & Restore Logical Backup
A logical-log backup is the process of copying the contents of a logical log file to secondary storage media. This allows the logical log to be reused. ……
Log ‘n’
The Informix ontape and ON-Bar backup/restore utilities are not interchangeable. A backup created by ontape cannot be restored using ON-Bar … and vice versa.
In order to successfully complete a logical restore, the logical-log backup must have been created with the same backup utility used to create the physical backup.

18. Backup & Restore Logical Backup Log salvage:
Log file cannot be re-used before it is backed up.
No log backup:
Set LTAPEDEV to /dev/null or NUL
Continuous log backup.
Manual log backup.
Log salvage:
Backup logical log files when server is off-line.
Can only backup undamaged files still on disk.
The logical-log files store a record of database server activity that occurs between backups. To free full logical-log files, back them up by using a logical-log backup to copy them to disk or tape. The database server reuses the freed logical-log files for recording new transactions.
The ONCONFIG configuration file parameter LTAPEDEV is used to set the logical log backup device. If you don't require logical logs to be backed up then set this value to /dev/null (unix/linux) or NUL (Windows). If you are using the ON-Bar backup utility and you do want logical logs backed up then make sure LTAPEDEV is set meaningfully, otherwise ON-Bar will think the logical logs have already been backed up!
A manual logical-log backup backs up all the full logical-log files and stops at the current logical-log file. If you turn on continuous logical-log backup, the database server backs up each logical log automatically when it becomes full. If you turn off continuous logical-log backup, the logical-log files continue to fill. If all logical logs are filled, the database server hangs until the logs are backed up.
Log Salvage - When the database server is offline, you can perform a special logical-log backup, called a log salvage. In a log salvage, the database server accesses the log files directly from disk. The log salvage backs up any logical logs that have not yet been backed up and are not corrupted or destroyed. The log salvage enables you to recover all of your data up to the last available and uncorrupted logical-log file and the last complete transaction.

19. Backup & Restore Physical & Logical restore
A restore recreates database server data from backed-up storage spaces and logical-log files. A restore recreates database server data that has become inaccessible because of any of the following conditions:
v You need to replace a failed disk that contains database server data.
v A logic error in a program has corrupted a database.
v You need to move your database server data to a new computer.
v A user accidentally corrupted or destroyed data.
To restore data up to the time of the failure, you must have at least one level-0 backup of each of your storage spaces from before the failure and the logical-log files that contain all transactions since these backups.

20. Backup & Restore Physical Restore Cold: Warm: Server is off-line.
Must restore all critical media.
Salvage logical log files still on disk, physical restore, logical restore.
Warm:
Server is On-Line or Quiescent.
Restore of critical media not allowed.
Small impact on production in most cases.
Physical restore of storage spaces, followed by logical log backup, then logical log restore.
Cold Restore – A cold restore salvages the logical logs, and restores the critical dbspaces (root dbspace and the dbspaces that contain the physical log and logical-log files), other storage spaces, and the logical logs.
You can perform a cold restore onto a computer that is not identical to the one on which the backup was performed by giving any chunk a new path name and offset during the restore. When restoring a whole-system backup, it is not necessary to restore the logical logs. A whole-system backup contains a snapshot of the entire instance at the moment the backup was performed, which is logically consistent across all dbspaces. When restoring a standard backup, you must restore the logical logs by performing a logical restore.
Warm Restore - A warm restore restores non-critical storage spaces. A warm restore consists of one or more physical restores, a logical-log backup, and a logical restore.

21. Backup & Restore Physical Restore (cont’d) Mixed
Get back to production as soon as possible.
First step: Cold restore all critical and application significant spaces to bring server On-Line.
Second step: At a later time complete the restore with a warm restore of the remaining spaces.
Overall restore takes longer because there are 2 logical restores, one for each step.
A mixed restore is a cold restore of some storage spaces (critical ones) followed by a warm restore of the remaining storage spaces.

22. Backup & Restore Restore Options Point in Time / Point in Log:
Restore to a specific time or to the end of a specific log.
All changes to data after the point in time are lost.
MUST restore all storage spaces to the same time.
Imported
Restore on one server a backup taken from another.
Intended for testing or to start up replication.
Creates a new server instance:
You cannot merge data from two servers into one.
All storage spaces:
This is not the way to get rid of old data.
Restartable and Suspended.
Redirected:
Allows chunk pathnames to be changed while doing the restore.
A point-in-time restore enables you to restore the database server to the state it was in at a particular point in time. A point-in-time restore is typically used to recover from a mistake. For example, if you accidentally dropped a database, you can restore the server to a point in time just before you dropped the database. You must restore all storage spaces to the same point in time.
A point-in-log restore is similar to a point-in-time restore. The point-in-log restorestops at the time of the last committed transaction listed in the logical log. Youmust use point-in-log restore in a cold restore only and you must restore allstorage spaces. You can specify any log ID from any timeline to restore to a specific logical log. If the specific logical log applies to more than one timeline, then ON-Bar uses the latest one.
ON-Bar allows you to restore objects to a different database server instance than the one from which the data was backed up. This type of restore is called an imported restore. You can perform imported restores using whole-system, serial, or parallel backups. You must use compatible versions of XBSA and storage managers for both operations. If you perform a parallel imported restore, it must include all storage spaces, logical logs, and administrative files from the source database server to synchronize the instance.
If a failure occurs with the database server, media, or ON-Bar during a restore, you can restart the suspended restore from the place that it failed. You do not have to restart the restore from the beginning. The RESTARTABL E_RESTORE parameter controls whether ON-Bar is able to keep track of the storage spaces and logical logs that were restored successfully.
A redirected restore allows you to rename chunks by specifying new chunks paths and offsets during a cold restore with ON-Bar. This option is useful if you need to restore storage spaces to a different disk from the one on which the backup was made. You can rename any type of chunk, including critical chunks and mirror chunks.

23. Backup & Restore Logical Restore Logical restore has 2 parts:
Copy the backed up log file to disk.
Read the data in the log file and replay the transactions.
Logical restore is performed only on the spaces just physically restored:
Can’t do logical restore by itself, must do physical restore first.
A Logical Restore requires that, first, the log files are backed up to disk or removable media such as tape. Then, secondly, the database server replays the logical logs to reapply any database transactions that occurred after the last backup.
The logical restore applies only to the physically restored storage spaces.
A logical restore must follow a physical restore.

24. Backup & Restore Select Tools:
Now that recovery goals have been set, it is time to identify the IBM Informix backup and recovery tools. In addition, other useful features and utilities that provide added data redundancy and high availability will be discussed.
A recovery plan should not be limited to simply a backup and restore system but should also consider wider system availability and disaster recovery aspects including fault tolerance methods and data load/unload utilities.

25. Backup & Restore Utilities - ontape
Backup and restore utility for Informix that provides:
Backup at the server level.
Support for incremental backup.
Manual or continuous logical-log backup.
Restore at the system or dbspace level.
The ontape utility logs, backs up, and restores data, and enables you to change the logging status of a database. It does not use a storage manager. Ontape can:
Back up all database server data
Back up logical-log files
Perform continuous logical-log backups
Perform continuous logical-log restore
Back up while the database server is online
Back up while the database server is in quiescent mode
Restore all database server data
Restore selected storage spaces
Back up and restore storage spaces serially
Perform cold restores with the database server offline
Initialize high availability data replication
Perform separate physical and logical restores
Rename a chunk path name or device during a cold restore
Perform imported restores
Perform external backups and restores
Change logging mode for databases
Transform data with external programs
Back up to or restore from cloud storage

26. Backup & Restore Utilities - ontape
Advantages
Reliability - Data can be restore up to point of failure because of logical-log backups.
Ability to restore at the system or dbspace level .
(restore not backup at dbspace level.
Support for remote tape devices.
Support for external backup and restore.
Simple configuration.
Easy to use command syntax.
Generally used for small database servers.
The most significant benefits of ontape are that it is simple to use and does not require the complexity of setting up Informix Storage Manager and possibly a third party storage manager.
Ontape's benefits over ON-Bar also include:
* Change logging mode for databases
* Back up to or restore from cloud storage

27. Backup & Restore Utilities - ontape
Disadvantages:
Backup can only be done at the system level.
Each dbspace is backed up serially to a single device. For large systems, this can mean very slow backups.
Requires user input when device media must be changed.
No media management.
The most significant disadvantages of ontape are that it is relatively simple and lacks the flexibility to perform complex backup and restore operations, particularly where a storage manage is used.
Ontape's disadvantages compared with ON-Bar include the following functionality which ontape lacks:
* Use a storage manager to track backups and storage media
* Back up selected storage spaces
* Restore data to a specific point in time or log
* Back up and restore different storage spaces in parallel
* Use multiple tape drives concurrently for backups and restores
* Restart a restore
* Monitor performance.

28. Backup & Restore Utilities - onbar
Backup & Restore Utility for Informix that provides:
Parallel backup and restore.
System level and dbspace level backup and restore.
Support for incremental backups.
Manual or automatic backup of logical logs.
Point-in-time recovery for an instance.
An open interface for communication with storage manager (XBSA).
Third-party storage managers may provide support for sophisticated tape stacker and jukebox devices.
ON-Bar allows you to:
* Use a storage manager to track backups and storage media
* Back up all database server data
* Back up selected storage spaces
* Back up logical-log files
* Perform continuous logical-log backups and restore
* Back up while the database server is online
* Back up while the database server is in quiescent mode
* Restore all database server data
* Restore selected storage spaces
* Back up and restore storage spaces serially
* Perform cold restores with the database server offline
* Initialize high availability data replication
* Restore data to a specific point in time and log
* Perform separate physical and logical restores
* Back up and restore different storage spaces in parallel
* Use multiple tape drives concurrently for backups and restores
* Restart a restore
* Rename a chunk path name or device during a cold restore
* Perform imported restores
* Perform external backups and restores
* Monitor performance
* Transform data with external programs.

29. Backup & Restore Utilities - onbar
Backup & Restore Utility for Informix that provides:
Advantages
Parallel backup and restore provides speed.
Reliability-Data can be restore up to point of failure because of logical-log backups.
Support for multiple devices.
Ability to restore at the server or dbspace level. This means the server can be made available to users once the critical dbspaces, i.e. root, logs, etc., have been restored:
Non-critical dbspaces can then be restored in order of importance.
The most significant advantages of ON-Bar are that it is functionally very rich and supports the use of integrated storage managers. It has the flexibility to perform complex backup and restore operations.
ON-Bar's advantages compared with ontape include the following functionality which ontape lacks:
* Use a storage manager to track backups and storage media
* Back up selected storage spaces
* Restore data to a specific point in time and log
* Back up and restore different storage spaces in parallel
* Use multiple tape drives concurrently for backups and restores
* Restart a restore
* Monitor performance.

30. Backup & Restore Utilities - onbar
Disadvantages:
Requires configuration and use of the IBM Informix Storage Manager or an additional cost third-party storage manager.
The disadvantage of using ON-Bar is that it requires configuration of the Informix Storage Manager and (if used) the integration with a third party storage manager.
This additional configuration is worthwhile because of the feature rich backup and restore functionality it provides.

31. Backup & Restore - onbar
onbar enhancements over ontape:
High-speed parallel backup and restore.
Unattended operations.
Automatic backup of logical logs via the ALARMPROGRAM parameter.
Support for sophisticated backup storage devices through a storage manager.
Backup of selected dbspaces.
Restartable restore.
ON-Bar's advantages compared with ontape include the following functionality which ontape lacks:
* Use a storage manager to track backups and storage media
* Back up selected storage spaces
* Restore data to a specific point in time and log
* Back up and restore different storage spaces in parallel
* Use multiple tape drives concurrently for backups and restores
* Restart a restore
* Monitor performance.

32. External Backup & Restore
Methods of backing up data at the O/S level
UNIX commands such as:
cpio
tar od
File system snapshots.
3rd mirror break off.
Storage manager “raw” backup.
External backup/restore feature of ON-Bar allows logical recovery.
Can be taken from a MACH-11 RSS of logged objects.
An external backup and restore eliminates the downtime of systems because the backup and restore operations are performed external to the Informix system. ON-Bar does not move the data during the backup or physical restore. An external backup allows you to copy disks that contain storage-space chunks without using ON-Bar. When disks fail, replace them and use vendor software to restore the data, then use ON- Bar for the logical restore.
The following are typical scenarios for external backup and restore:
* Availability with disk mirroring - If you use hardware disk mirroring, you can get your system online faster with external backup and restore than with conventional ON-Bar commands.
* Cloning - You can use external backup and restore to clone an existing production system for testing or migration without disturbing the production system.
You can perform an external backup of an RS secondary server. Performing a backup of an RS secondary server blocks that RS secondary server, but does not block the primary server. You can perform a logical restore from the logs backed up from the primary instance. The backup obtained from the secondary server cannot be restored with level-1 or level-2 backups.

33. External Backup & Restore
Advantages:
Availability, speed-Data can be backed up and restored more quickly, making the data available sooner.
Multiple copies of the same data can be kept.
Ability to copy raw physical devices.
Logical restore available if combined with ON-Bar External Restore.
To perform an external backup when chunks are not mirrored:
1 Block the database server with the onmode -c block command. The system takes a checkpoint and suspends all update transactions. Users can access the database server in read-only mode.
2 Back up the storage spaces and administrative files: use a copy command, such as cp, dd, or tar on UNIX or copy on Windows, or a file-backup program. You must back up all chunks in the storage spaces.
3 Unblock the database server with the onmode -c unblock command.
4 Back up all the logical logs including the current log so that checkpoint information is available for the external restore.
Important: You must ensure that you have a backup of the current logical log from the time when you execute the onmode -c block command. Without a backup of this logical-log file, the external backup is not restorable.
5 After you perform an external backup, back up the current log with the onbar -b -l -c command.
To perform an external backup when chunks are mirrored:
1 Block the server with onmode -c block command. The system takes a checkpoint and suspends all update transactions. Users can access the database server in read-only mode.
2 Break Mirroring
3 Unblock the server with onmode -c unblock
4 Backup the logical logs with onbar -b -l -c
5 Backup data from mirror disks to backup media
6 Resume mirroring.
In this configuration, the database server is running continuously, except for the short time when the database server is blocked to break the mirror. The mirrored disks contain a copy of the database server storage spaces. To create a backup, block the database server to stop transactions and disable mirroring. The mirrored disks now contain a copy of the consistent data at a specific point in time. After disabling mirroring, unblock the database server to allow transactions to resume and then backup the logical logs. Copy the data from the offline mirrored disks to backup media using external commands. Now you can resume mirroring.

34. External Backup & Restore
Disadvantages:
No logical recovery available when using external backup utilities unless you use the ON-Bar External Backup/Restore feature.
Greater costs associated with third mirror break off solutions.
No media tracking for external backups is done by ON-Bar.
Because external backup is not done through ON-Bar, you must ensure that you have a backup of the current logical log from the time when you execute the onmode -c block command. Without a backup of this logical-log file, the external backup is not restorable.
The database server and ON-Bar do not track external backups. To track the external backup data, use a third-party storage manager or track the data manually. Because the external backup is outside the control of ON-Bar, you must track these backups manually
ON-Bar does not support mixed external restores. For example, the following sequence of commands might fail:
* onbar -r -e rootdbs
* onbar -r -e other_dbspaces
When you perform a cold external restore, ON-Bar does not first attempt to salvage logical-log files from the database server because the external backup has already copied over the logical-log data. To salvage logical logs, perform onbar -l -s before you copy the external backup and perform the external restore (onbar -r -e).
Before you begin an external restore, know the following rules:
* You must externally restore from an external backup. Although the external backup is treated as a level-0 backup, it might actually be a incremental backup not related to Informix.
* A warm external restore restores only noncritical storage spaces.
* You cannot externally restore temporary dbspaces.
* You cannot externally restore from regular ON-Bar backups.
* You cannot verify that you are restoring from the correct backup and that the storage media is readable with ON- Bar.
* If the external backups are from different times, the external restore uses the beginning logical log from the oldest backup.

35. Backup & Restore – High Performance Loader
Load / Unload utilities – High Performance Loader (HPL):
Enables rapid loading/unloading of large amounts of data in parallel.
Performs data conversion.
Supports a variety of devices.
Stores load/unload operations as reproducible jobs.
The HPL is a database server tool that allows you to load and unload large quantities of data efficiently to or from a database. The HPL lets you exchange data with tapes, data files, and programs, and converts data from these sources into a format compatible with Informix databases. The HPL also allows you to manipulate and filter the data as you perform load and unload operations.
The HPL offers two load modes, deluxe mode and express mode. The express mode is faster, and the deluxe mode is more flexible.
The HPL express mode - Loads are significantly faster than deluxe-mode loads, but less flexible. In express mode you cannot update the table or read the new data entries until the load is complete. The express mode disables indexes, constraints, and triggers during the load. After the load, HPL rebuilds and re-enables indexes, evaluates and re-enables constraints, if possible, and re-enables triggers. (HPL does not evaluate triggers with respect to the loaded data.) You must perform a level-0 backup after an express-mode load.
The HPL deluxe mode - Loads are not as fast as express-mode loads, but are more flexible. In deluxe mode, you can access and update the table that is being loaded. The deluxe mode updates indexes, performs constraint checking, and evaluates triggers as data is inserted into the table.

36. Backup & Restore – High Performance Loader
Load / Unload utilities – High Performance Loader (HPL)
Advantages:
Enables rapid unloading/loading of large quantities of data. I/O to the devices and the server is performed in parallel.
Supports a variety of devices.
Supports multiple formats for load/unload files.
Data can be loaded from multiple sources.
Recovery at the table and row level.
Reusability of load/unload definition. Load/unload jobs are defined and stored in a database for reuse.
Could be used as a backup utility for a database with a few static tables.
HPL:
v Supports COBOL, ASCII, multibyte, delimited, or binary data.
v Can load and unload data of a different GLS locale from that of the database server.
v Provides synonym support for tables that are valid for the local database server. You can use synonyms for both the load and unload operations.
v Provides support for unloading data with a query that accesses a view in its SELECT statement.
v Supports loading of raw tables in express mode.
The data-load process reads a source data file, converts the data to a different format, and inserts the converted data into a database table. The source data can come from one or more of the following sources:
v Files
v Tapes
v Pipes (application-generated data) [UNIX Only]
During conversion, the source data is often manipulated so that the converted data displays different characteristics. Examples of this manipulation include:
v Changing lowercase letters to uppercase letters
v Loading default values, loading certain table columns, or replacing nulls
v Masking the data to include only part of a value
v Converting from one data type to another, such as conversion of a numeric string to a float

37. Backup & Restore – High Performance Loader
Load / Unload utilities – High Performance Loader (HPL)
Disadvantages:
No transaction recovery available. Recovery only occurs up to the time data was last unloaded.
DBA must assure relational integrity of the database during the load and unload process.
Tool is more complex than other load/unload utilities.
Does not append to output devices.
HPL has no concept of logical log recovery, i.e. restore with HPL will only be able to restore data up to the point that the HPL unload was performed.
When you load records from a data file, some of the records might not meet the criteria that you established for the database table. For example, the data file might contain:
v Null values where the table specifies NOT NULL
v Values in an incorrect format (for example, alphabetic characters in a numeric field)
v Records that do not have the expected number of fields. The way that the HPL treats these errors depends on the mode (deluxe or express) and the type of job (load or unload).
The HPL separates errors into the following two classes:
v Rejected records from the input file. These records include Records that the filter rejected and Records that cannot be converted.
v Constraint violations
Due to its performance and the methods it uses to load data, HPL is more complex than some of the other simpler load and unload utilities.
During express-mode load, the database server writes the data to new extents on disk, but those extents are not yet part of the table. At the end of an express-mode load, the database server adds the new extents to the table. After the express-mode load, you must perform a level-0 backup before you can write to the target database. If you try to write to the table before you perform a level-0 backup, the database server issues ISAM error -197, as follows:
Partition recently appended to; can't open for write or logging.

38. Backup & Restore – dbimport/dbexport
Load / Unload utilities – dbimport / dbexport
dbimport:
Creates the database.
Imports ASCII data into the specified database.
Loads from disk or tape.
dbexport:
Unloads data and schema for an entire database.
Data stored in ASCII files.
Unloads to disk or tape.
The dbexport and dbimport utilities import and export a database to a text file that is stored on disk or tape.
The dbexport utility unloads an entire database into text files and creates a schema file. You can use the schema file with dbimport to re-create the database schema in another Informix environment, and you can edit the schema file to modify the database that dbimport creates.
You might want to use the dbexport and dbimport utilities if you cannot use the onunload and onload utilities and you want to unload a database with or without its schema file to disk or tape.
The dbexport and dbimport utilities support Informix 11.70, 11.50, 11.10, 10.00, 9.40, 9.30, and data types.
The dbexport utility supports the following destination options:
* Unload a database and its schema file to disk
* Unload a database and its schema file to tape
* Unload the schema file to disk and unload the data to tape.

39. Backup & Restore – dbimport/dbexport
Load / Unload utilities – dbimport / dbexport
Advantages:
Ability to capture data and schema.
ASCII files provide portability.
Recovery at the database level.
Inexpensive and easy way to backup small databases.
Dbexport is useful because it captures an entire database and schema definition.
It creates files which are plain text readable which are easy to move/copy and check their content.
Just as dbexport creates an entire export of a database, the dbimport utility reads the schema file created by dbexport and loads up the entire database exported by dbexport.

40. Backup & Restore – dbimport/dbexport
Load / Unload utilities – dbimport / dbexport
Disadvantages:
No transaction recovery available. Recovery only occurs up to the time the last export was taken.
Large databases will consume tape/disk resources; processing will be slow.
Requires an exclusive lock on the database when processing.
Dbexport/dbimport are purely about the data definition and data content at the time it is exported and consequently has no concept of reading log data to recover changes since it was exported.
Dbexport/dbimport are good for smaller databases but can be timely for large databases.
When dbexport creates the export it declares an exclusive lock on the whole database to be exported and so prevents changes to the database while the dbexport is in progess (another reason it is better for smaller databases.

41. Backup & Restore – SQL load/unload
Load / Unload utilities – SQL load / unload:
SQL statements for loading and unloading data from ASCII files.
Adds rows to existing tables.
Must be run through DB-Access or ISQL.
The SQL LOAD and UNLOAD statements
You can use the SQL LOAD and UNLOAD statements to move data. The LOAD statement is moderately fast and easy to use, but it only accepts specified data formats. You usually use the LOAD statement with data that is prepared with an UNLOAD statement.
You can use the SQL UNLOAD statement in DB-Access to unload selected rows from a table into a text file.
The SQL UNLOAD statement lets you manipulate the data as you unload it, but it requires that you unload to files on disk instead of to tape. If you unload to disk files, you might need to use UNIX, Linux, or Windows utilities to load those files onto tape.
To load tables, use LOAD or dbload. To manipulate a data file that you are loading or to access a database while it is loading, use the dbload utility. The cost of the flexibility is the time you spend creating the dbload command file and slower execution. When possible, use the LOAD statement, which is faster than dbload.

42. Backup & Restore – SQL load/unload
Load / Unload utilities – SQL load / unload
Advantages
Data is added to existing tables:
dbimport and onload create new tables.
Specific rows can be unloaded.
Data unloaded is based upon an SQL SELECT statement.
ASCII files provide portability.
Recovery at the table and row level.
SQL LOAD is useful for taking an input file of CSV data and adding it to an existing table, whereas dbimport loads the entire table afresh.
SQL UNLOAD is useful for selectively exporting data in a table into a CSV file so that it can be used elsewhere from the file system.

43. Backup & Restore – SQL load/unload
Load / Unload utilities – SQL load / unload
Disadvantages:
Dependent upon DB-Access or ISQL.
Does not load from tape.
No transaction recovery available.
Recovery only occurs up to the time the last export was taken.
Large amounts of data will be loaded and unloaded slowly.
You can only use load/unload within the dbaccess utility or the Informix SQL product.
SQL Load/Unload have no facility for reading log data to recover changes since it was last unloaded and it has no concept of transaction awareness..
SQL Load/Unload are good for smaller amounts of data but can be timely for large amounts of data.

44. Backup & Restore – onload/onunload
Load / Unload utilities – onload / onunload
onload
Creates database or tables in specified dbspaces.
Loads data created by onunload only.
Page size must be compatible.
onunload
Transfers data in binary pages.
Default write to tape unless –t option used to an existing file.
The onunload and onload utilities provide the fastest way to move data between computers that use the same database server on the same platform.
For example, your site purchases a more powerful UNIX computer to allow faster access for users. You need to transfer existing databases to the new database server on the new computer. Use onunload to unload data from the first database server and then use onload to load the data into the second database server. Both database servers must have the same version number, or they must have compatible version numbers. You can move an entire database or selected tables only, but you cannot modify the database schema.
The onunload utility can unload data more quickly than either dbexport or the UNLOAD statement because onunload copies the data in binary format and in page-sized units. The onload utility takes a tape or a file that the onunload utility creates and re-creates the database or the table.
The onunload and onload utilities are faster than dbimport, dbload, or SQL LOAD but are much less flexible and do not let you modify the database schema or move from one operating system or database server version to another.

45. Backup & Restore – onload/onunload
Load / Unload utilities – onload / onunload
Advantages
Efficient data transfer. Data is read and written in binary pages, providing speed.
Recovery at the database and table level.
The onunload and onload utilities provide the fastest way to move data between computers that use the same database server on the same platform.
For example, your site purchases a more powerful UNIX computer to allow faster access for users. You need to transfer existing databases to the new database server on the new computer. Use onunload to unload data from the first database server and then use onload to load the data into the second database server. Both database servers must have the same version number, or they must have compatible version numbers. You can move an entire database or selected tables only, but you cannot modify the database schema.
The onunload utility can unload data more quickly than either dbexport or the UNLOAD statement because onunload copies the data in binary format and in page-sized units. The onload utility takes a tape or a file that the onunload utility creates and re-creates the database or the table.
The onunload and onload utilities are faster than dbimport, dbload, or SQL LOAD but are much less flexible and do not let you modify the database schema or move from one operating system or database server version to another.

46. Backup & Restore – onload/onunload
Load / Unload utilities – onload / onunload
Disadvantages
Cannot be run for databases across a network.
Cannot be used for file I/O.
Loads data created by onunload only.
Binary data and page size limit portability. Page size varies from machine to machine (check your configuration file, onconfig, for the page size for your server system). You cannot use the utilities to transfer data from one server system to another with a different page size. Most server systems have either 4K or 2K pages.
No transaction recovery available. Recovery only occurs up to the time data was last unloaded.
You must read the file that onunload creates with the onload utility of the same version of your database server. You cannot use onunload and onload to move data from one version to another.
onunload does not preserve access privileges, synonyms, views, constraints, triggers, or default values that were associated with the original tables.
The onunload and onload utilities are faster than dbimport, dbload, or SQL LOAD but are much less flexible and do not let you modify the database schema or move from one operating system or database server version to another.
The onunload utility can unload data more quickly than either dbexport or the UNLOAD statement because onunload copies the data in binary format and in page- sized units. The following constraints apply to onunload:
You must load the data on the onunload tape into a database or table that your database server (excluding SE) manages.
You must load the tape that onunload writes onto a computer with the same page size and the same representation of numeric data as the original computer.
You must read the file that onunload creates with the onload utility of the same version of your database server. You cannot use onunload and onload to move data from one version to another.
When you unload a complete database, you cannot modify the ownership of database objects (such as tables, indexes, and views) until after you finish reloading the database.
When you unload and load a table, onunload does not preserve access privileges, synonyms, views, constraints, triggers, or default values that were associated with the original tables. Before you run onunload, use the dbschema utility to obtain a listing of the access privileges, synonyms, views, constraints, triggers, and default values. After you finish loading the table, use dbschema to re-create the specific information for the table.

47. Backup & Restore - dbload
Load / Unload utilities – dbload
Loads data from multiple ASCII files on disk into one or more existing tables.
ASCII files can be created by the UNLOAD utility or by another means (c program, text editor or any other unload utility file that unloads data to ASCII).
Dbload offers more flexibility than LOAD.
The dbload utility loads data into databases or tables that IBM Informix products created. It transfers data from one or more text files into one or more existing tables.

48. Backup & Restore - dbload
Load / Unload utilities – dbload
Advantages
Data can be loaded from multiple sources.
Data is added to existing tables:
dbimport and onload create new tables.
ASCII files provide portability.
Recovery at the table and row level.
Provides more flexibility than LOAD.
Specify a starting point in the load file.
Add transaction logic (commit after every x rows).
Limit the number of bad rows read, at which time dbload terminates.
When you use the dbload utility, you can manipulate a data file that you are loading or access a database while it is loading. When possible, use the LOAD statement, which is faster than dbload.
The dbload utility offers the following advantages over the LOAD statement:
* You can use dbload to load data from input files that were created with a variety of format arrangements. The dbload command file can accommodate data from entirely different database management systems.
* You can specify a starting point in the load by directing dbload to read but ignore x number of rows.
* You can specify a batch size so that after every x number of rows are inserted, the insert is committed.
* You can limit the number of bad rows read, beyond which dbload ends.

49. Backup & Restore - dbload
Load / Unload utilities – dbload
Disadvantages:
Doesn’t load from tape.
No transaction recovery available.
Recovery only occurs up to the time the last export was taken.
Large amounts of data will be loaded slowly.
DBA must assure relational integrity of the database during the load process.
Prerequisites: If the database contains label-based access control (LBAC) objects, the dbload utility can load only those rows in which your security label dominates the column-security label or the row-security label. If the entire table is to be loaded, you must have the necessary LBAC credentials for writing all of the labeled rows and columns. For more information about LBAC objects, see the IBM Informix Security Guide and the IBM Informix Guide to SQL: Syntax.
You cannot use the dbload utility on secondary servers in high-availability clusters.
The dbload utility gives you a great deal of flexibility, but it is not as fast as the other methods, and you must prepare a command file to control the input. You can use dbload with data in a variety of formats.
The cost of dbload flexibility is the time and effort spent creating the dbload command file, which is required for dbload operation. The input files are not specified as part of the dbload command line, and neither are the tables into which the data is inserted. This information is contained in the command file.

50. Backup & Restore - Summary
Informix provides different Backup & Restore options
ontape
onbar
External Backup & Restore
Load & Unload utilities:
Dbexport / dbimport
Dbschema
HPL
SQL load / unload
Onload / onunload
Dbload

51. Backup & Restore - Resources
The Online Informix Information Center:
One-stop shop for Informix product documentation.
Supports book marking favorite topics, narrowing the scope to refine searches, printing subsets of topics.
IBM Informix DeveloperWorks Technical Articles:
Premium technical resource site for DBAs and developers.
Features explained with examples/sample code.
Contributions from IBM experts as well as customers.