To back up Vector you can use the following methods:

The logging system keeps track of all database transactions automatically. It is comprised of the following facilities and processes:

Each installation has an installation-wide transaction log file that keeps track of all transactions for all users. The installation-wide log file can be distributed among up to sixteen partitions (locations), but the files are treated as one logical file.

With dual logging enabled, the installation has an alternate log file. With dual logging, a media failure on one of the logs does not result in the loss of data or the interruption of service. If one of the log file disks fail, the logging system automatically switches to the other log without interrupting the application.

When log files are properly configured, the use of dual logging has a negligible impact on system performance.

In addition to the installation-wide log file every database has its own wal directory. The wal directory files contain an up-to-date representation of the memory structures required for database recovery.

The recovery process (dmfrcp) handles online recovery from server and system failures. The logging system writes consistency points into the installation-wide transaction log file to ensure that all databases are consistent up to that mark and to allow online recovery to take place when a problem is detected.

The archiver process (dmfacp) removes completed transactions from the transaction log file and, for journaled databases, writes them to the corresponding journal files for the database. Each database has its own journal files, which contain a record of all the changes made to the database after the last checkpoint was taken.

The archiver process “sleeps” until the last user exits the database or, if specified, the acp_timer interval has occurred. acp_timer is a Recovery Server parameter in config.dat that defines the archiver cycle interval.

A checkpoint is a snapshot of an entire database. Up to 99 checkpoints can be maintained at any time.

Checkpointing can be performed at the database level only.

Each time you take a checkpoint, a set of files in the ckp and dmp directories is created. In addition, if journaling is enabled, a set of journal files, created in the jnl directory, is associated with the checkpoint at the start of the journal interval.

To use the checkpoint operation, you must be a privileged user (operator privilege or system administrator).

To ensure that a valid database checkpoint is always available, we recommend that you use the infodb command to verify the status of the database and checkpoints.

To make full backups of your entire database use checkpoints.

To make a dynamic incremental backup of your database, use checkpointing in combination with journaling.

These backup methods enable you to restore data up to the last checkpoint, or the last journaled transaction, respectively.

Checkpoints can be performed online or offline.

An online checkpoint, which is the default, can be performed while users are connected to the database. A full online checkpoint stalls until any transactions running against the database are committed. Any new transactions started during the stall phase of the online checkpoint cannot run until the stall phase is completed.

Incremental online checkpoints can proceed while DML transactions are active.

An offline checkpoint can be performed when no one is using the database.

Only database-level backup is supported.

The ckpdb operation does not support the following:

DDL operations are not allowed during an online checkpoint.

A checkpoint is a snapshot of the database. Checkpoints can be taken when the database is either offline (no one is using the database) or online.

Issue the following command at the operating system prompt of the master node:

A new online checkpoint for the specified database is created.

Issue the following command at the operating system prompt of the master node:

A new offline checkpoint for the specified database is created. The -l flag causes the checkpoint to be taken offline. When using the -l flag, you can also use the “wait” flag, which waits (+w) as long as necessary for the database to be free before taking the checkpoint or returns an error message if the database is busy (-w, the default).

A file called the checkpoint template file, cktmpl.def, drives the checkpoint and roll forward operations. The cktmpl.def file allows you to customize backup and recovery processes and provides additional information tracking.

The II_CKTMPL_FILE environment variable overrides the default cktmpl.def file for a particular user. This override must be used when testing modifications to the cktmpl.def file before it is made available to the entire installation so that other users in the installation are not affected.

For checkpoint template codes and parameters, see Checkpoint Template File Description.

You must manage the files in the checkpoint, journal, and dump locations for each database.

Each time you take a checkpoint, a set of files in the ckp and dmp directories are created. In addition, between checkpoints, for each journaled database, more files are created in the jnl (journal) location. Each set of journal files is associated with the checkpoint at the start of the journal interval.

So, for backup and restore purposes, a checkpoint consists of checkpoint file(s) and associated journal and dump files.

References to the ckp and associated files are stored in the configuration file for the database. These references must be present to be used by backup and restore operations. To see this information, issue the following command at the operating system prompt:

Most of the commands used to back up and restore data create or destroy the complete set of files and references associated with a checkpoint.

When you checkpoint a database, a checkpoint file is created for each location on which the database is stored. The names of the checkpoint files are in the format shown by the following example:

where v shows the version number of the checkpoint sequence and l shows the location number of the data directories. The most recent checkpoint file has the highest version number.

In the common case where the database has only one location, there will be one checkpoint file for each checkpoint called c000v001.ckp.

Vector can manage up to 99 checkpoints. If this limit is exceeded, the oldest checkpoint will be unusable because the database configuration file will contain no references to it. Before you reach this point, you may run out of disk space for either the checkpoints or journals. In most cases keeping 99 checkpoints on disk is not useful.

The easiest way to manage checkpoints and their associated files is to decide how many checkpoints you want to be referenced in the database configuration file (so that you can restore the database directly from files on disk or from files restored from backup).

Add the following command after your routine checkpoint command:

The specified number of latest valid checkpoints is preserved, and all older checkpoints are deleted.

This command is sufficient for most purposes. Occasionally, however, you may need other commands, described next.

If you do not have sufficient disk space for N sets of checkpoint and journal files, you must back up these files and manually delete them from disk.

In the context of a live database, the checkpoint, the associated files (with the same checkpoint number) in the dmp directory, and all subsequent journal files are required to be able to restore that database. So, you should remove only the set of files associated with the oldest checkpoint each time.

In addition, if the live database configuration file is lost or broken, you will also need the aaaaaaaa.cnf file from the dmp directory. Because the files in the dmp directory are usually small, it is easiest to simply back up the entire dmp directory.

If you do not have disk space for all the checkpoints referenced in the database configuration file, or if some of the files are not referenced (as indicated by infodb dbname), you must delete these files manually.

Use an operating system command, as follows:

Use the Linux rm command from the ii_checkpoint/ingres/ckp/dbname directory, where ii_checkpoint is the value of II_CHECKPOINT as displayed by the ingprenv command.

Here are other commands for managing checkpoints and their associated files.

To destroy your database and recreate it, use the unloaddb command.