Kbase P10318: How to perform unattended backups for databases with capacities larger than the tape/file capacity?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
05/12/2008 |
|
Status: Verified
GOAL:
How to backup databases that are larger than the tape/file capacity
GOAL:
How to perform unattended backups to multiple tapes/files
GOAL:
Automating PROBKUP to Multiple Tapes/files
GOAL:
How to manipulate the tape when Progress (using a probkup) asks for the next tape/file
GOAL:
How to perform unattended backups for databases with capacities larger than the tape/file capacity?
GOAL:
How to avoid "SYSTEM ERROR: write to <device-name> failed, errno = 6 (1049) when the end of the tape is reached ?
GOAL:
How to backup to volumes probkup -vs
GOAL:
How to probkup database > 2GB to specific volume sizes ?
GOAL:
How to define a multi-volume for probkup 2GB
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
Progress Versions earlier than 9.1B will not create backup files larger than 2Gb. Since Progress 9.1B, the probkup utility can create files on disk that are larger than 2Gb, if large files are supported by the operating system and the file system to which the backup files are directed. The Progress database does not have to be largefiles enabled in order to achieve this. The limitation of filesize is entirely filesystem or userlimit related. Linux platforms are an exception: on this platform, the 2Gb limit on probkup has been lifted only in OpenEdge 10 and later.
The resulting 2 GB+ backup volumes may not be portable to other file systems if these file systems do not handle files larger than 2 GB, so they cannot be restored. The limitation for the size of backup files is set by the operating system or file system. For this reason, Progress recommends that backup files are kept smaller than 2 GB in size.
When the situation arises that:
- a backup is about to exceed the capacity of the largest backup media available to that user (for example: a 40/80GB DLT), or
- when backing up the database, it will span more then one tape or file,
implementation of of a multi device backup needs to be considered.
To manipulate the tape or specify the next file, when Progress (using a probkup) asks for the next volume however, Progress simply waits for confirmation that it can proceed. Manually entering the next device or switching tapes, is not always possible, as this process is (usually) unattended.
In cases such as these, it is necessary to automate scripts so that it is not necessary to manually enter the key strokes that are needed to continue with the backup procedure. Arranging the unattended load of the second media is discussed in this Solution.
To assist in automating this procedure, the probkup utility must be run interactively (at least once) so that the necessary keystrokes can be captured and recorded. Once the keystrokes have been recorded, they can be entered into a text file and redirect into the probkup procedure as follows:
$ probkup dbname /dev/dbname1.bak -vs n < input.file
WHERE:
+ dbname is your database name,
+ /dev/dbname1.bak is the first backup volume to be created
+ -vs parameter indicates the volume size - that is, the number of blocks that can be written to each volume.
In Progress 7.x and earlier versions, the default block size on the OS dictated the database block size, hence, the OS blocksize was the database blocksize. The introduction of variable block size in V8 (and higher), the -vs parameter value now references the database block size, where units are in in database blocks, not in Kb or Mb. In the case of tape devices, the value of n should be set lower than the size of the tapes that are being used and greater than the blocking factor (-bf) depending on the database block size (and the number of Storage Areas in Version 9 and above). In the case of files to disk, it should be set to the considered available physical file size divided by the database block size, not exceeding 2GB, user or file limits.
Similarly, in cases where the first tape or volume size (if backing up to a file to disk) has been filled and it is necessary to use a new device name or file name, this methodology can also be employed. In such a circumstance, a new device/file name will be prompted for as follows:
Please enter next device/file name or type "quit" to exit:
At this point, either a different file name or a device name needs to be indicated. CAUTION: If the same device name is entered without changing tapes, the backup will be overwritten. It is therefore also necessary to change tapes or enter a different device name that has been prepared for the remaining portion of the b.ackup. Please note, that once this procedure has passed its first run, it is HIGHLY recommended to follow this proofing by restoring this backup to ensure that it was successful.
The next device/file name is supplied by an input.file and could be as simple as a one line entry. There is no harm and it is recommended to have more than one 'next device/file name' defined in the event it is needed. In the following example, assume that the database backup is going to span 4 tapes/files and there are 4 different tape/file drives that the backup volmes can be written to.
The input.file would then read as follows:
************************ input.file ******************************
/dev/dbname2.bak (hard return)
/dev/dbname3.bak (hard return)
/dev/dbname4.bak (hard return)
(hard return)
************************ End of File: input.file *******************
In other words, after the initial probkup command (as displayed above) has been executed, the next device or file name has been prompted for 3 additional times. By including the NEXT 3 devices, the input file will send the input to the next prompt made by the probkup utility. Bear in mind that after each new device/file name a hard return must be included in the input.file in order to continue. The first device/file name is provided on the command line when executing the probkup utility initially.
Continuing above example:
Say the database blocksize = 4KB
The database needs 3.5GB of backup media (NOTE: this will include both the bi and the data files in the case of an online probkup)
$ probkup dbname /dev/dbname1.bak -vs 500000 < input.file
will create backup volumes in 2000000 KB increments:
2,048,000,000 /dev/dbname1.bak
1,710,096,384 /dev/dbname2.bak
/dev/dbname3.bak will not be created, as it is not needed. Should it eventually be needed, it is already in place.
To restore the multivolume probkup, the exact reverse methodology is employed, viz:
$ prorest dbname /dev/dbname1.bak -vs n < input.file
Please note, if restoring over an existing database, a "y" yes prompt will need to be added to the "input.file" to automate the response.
Please keep in mind that it is highly recommended that this procedure is fully tested and documented prior to implementing it into a production environment..