Putting Checkpoints on Tape in Linux
In Linux, the backup system uses an operating system utility, such as tar or cpio, to create checkpoints. Both tar and cpio are limited to handling files that fit on a single tape. Because checkpoints of larger databases abort at the end of the first tape, you must estimate both the checkpoint size and the tape capacity before checkpointing these databases. If you estimate that the checkpoint exceeds the tape size, follow instructions in
Checkpointing to Multiple Tapes in Linux.
How to Estimate Checkpoint File Size in Linux
A separate checkpoint file is created for each location to which a database has been extended.
Follow these steps to estimate the size of checkpoint files:
1. Issue the following command at the operating system prompt:
du ii_database/ingres/data/default/dbname
where ii_database is the value of the environment variable II_DATABASE displayed by the ingprenv command.
For other locations, substitute the name of the directory associated with the location name.
2. If your operating system uses tar, increase the resulting block size of the directory by 5%.
3. The du command displays the directory size in blocks. To get the file size in bytes, multiply the block size by the number of bytes in a block on your operating system.
For information on the number of bytes in a block on your system, see your operating system manual.
Tape Capacity in Linux
The capacity of a tape depends on the following:
• Density at which the tape is written
• Length of the tape
• Size of the blocks written on the tape
• Length of the inter-record gap (IRG)
Standard 9-track tape drives write at either 800, 1600, or 6250 bits per inch (bpi), so the bits per inch specification is the same as bytes per inch. The standard tape length is 2400 feet.
Block sizes, which are not standardized, are important because of what is between the blocks—the IRG. A typical IRG is .75 inches of empty tape separating each block from the next.
Estimate Tape Capacity in Linux
You can use the following formula to estimate the size of the file in bytes that a tape can accommodate:
F = (B + (I * D))/(12 * B * D * L)
where:
• F is the file size in bytes
• B is the block size in bytes
• D is the density in bits per inch
• L is the length of the tape in feet
• I is the IRG in inches
The sample file sizes in the following table were calculated for a standard 2400 foot tape, assuming an IRG of .75:
After using this formula to calculate the file size, you need to add an arbitrary amount to allow for miscalculations. You do not want a tape to run off the reel because you miscalculated the size of the file that fits. A reasonable amount to add is 5% of a tape’s capacity.
If your system uses a cartridge tape or other storage media, contact the vendor for the specifications that allow you to make the calculations described above.
Checkpointing to a Single Tape in Linux
To checkpoint a database to a single tape:
1. Mount a tape reel.
2. In the Checkpoint dialog, enter the name of the tape drive in the Tape Device edit control.
The equivalent ckpdb command at the operating system prompt is as follows with a tape drive named “/dev/rmt8”:
ckpdb -m/dev/rmt8 dbname
The backup created by this checkpoint writes over everything that was on the tape previously.
Checkpointing to Multiple Tapes in Linux
When checkpoint files exceed the tape size, follow the appropriate procedure depending on whether the file fits on a disk.
When Checkpoint File Fits on a Disk
If the checkpoint file exceeds the size of the tape, but fits on a disk, follow these steps:
1. Follow normal procedures for checkpointing to disk.
2. Have your operating system administrator move the checkpoints from disk to tape. Use a standard system backup method, such as cpio or dump.
If some of the database’s tables are stored in alternate locations, separate checkpoint files are created for them in the checkpoint location. These files are small enough to be moves to single tapes.
Caution! To System V Users: It is possible for large checkpoints to exceed the ulimit on your system. (The ulimit is a tunable operating system parameter that sets a limit on file size.)
When Checkpoint File Does Not Fit on a Disk
If the checkpoint file exceeds the size of the tape and does not fit on a disk, you must checkpoint the database using the operating system. To successfully checkpoint a database, you have to lock all users out during the entire process.
To lock out all users and take the checkpoint, follow this procedure:
1. To synchronize journaling, checkpoint the database to a null device by specifying the following options in the Checkpoint dialog:
• Exclusive Lock
• Wait
• Delete Previous
• Tape Device: /dev/null
The Wait option causes the checkpointing to wait until all user locks have been released before beginning the checkpoint.
The Delete Previous option removes all previous checkpoints and journals.
The Tape Device specification causes the checkpoint to be placed in /dev/null, which is a nonexistent device. This makes the database “think” it is being checkpointed and causes journaling to be correctly synchronized. At this time, all changes to the database are guaranteed to be on disk.
2. To lock the database, start a new process:
Log in at another terminal immediately after the checkpoint begins.
Start the new process by issuing the following command at the operating system prompt:
ingres -l +w dbname
The +w flag causes a wait until that lock is granted.
3. After the checkpoint finishes:
Wait for the process to complete.
4. Have your operating system administrator use standard system backup methods to back up the database directory to tape.
Make sure that the backup method used allows you to save the files and recover them to their original places on the system. Some backup methods have limitations. The volcopy command, for instance, requires that the database disk device be unmounted and unavailable for use by any users during the copy. Additionally, it saves files by saving the entire file system.
5. Leave the second process at the SQL prompt (*) until the backup is complete.
6. Quit from the SQL prompt held by the second process.