IRIX Base Documentation 2002 November

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / a_man / cat1 / dump.z / dump

Wrap

Text File | 2002-10-03 | 19.8 KB | 397 lines

dddduuuummmmpppp((((1111MMMM)))) dddduuuummmmpppp((((1111MMMM)))) NNNNAAAAMMMMEEEE dump, rdump - incremental filesystem backup for EFS filesystems SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS dddduuuummmmpppp [ key [ argument ... ] ] filesystem rrrrdddduuuummmmpppp [ key [ argument ... ] ] filesystem DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _d_u_m_p and _r_d_u_m_p are applicable only to EFS filesystems, use _x_f_s_d_u_m_p(1m) for XFS filesystems. _d_u_m_p backs up all files in _f_i_l_e_s_y_s_t_e_m or files changed after a certain date to magnetic tape or files. The _k_e_y specifies the date and other options about the dump. _k_e_y consists of characters from the set 0000111122223333444455556666777788889999ffffuuuussssCCCCccccddddbbbbWWWWwwwwnnnn. Any arguments supplied for specific options are given as subsequent words on the command line, in the same order as that of the options listed. If no key is given, the _k_e_y is assumed to be 9999uuuu and the _f_i_l_e_s_y_s_t_e_m specified is dumped to the default tape device /_d_e_v/_t_a_p_e. 0000----9999 This number is the _d_u_m_p _l_e_v_e_l. All files modified since the last date stored in the file /_e_t_c/_d_u_m_p_d_a_t_e_s for the same _f_i_l_e_s_y_s_t_e_m at lesser levels are dumped. If no date is determined by the level, the beginning of time is assumed; thus the option 0000 causes the entire filesystem to be dumped. For instance, if you did a level 2 dump on Monday, followed by a level 4 dump on Tuesday, a subsequent level 3 dump on Wednesday would contain all files modified or added to the _f_i_l_e_s_y_s_t_e_m since the level 2 (Monday) backup. A level 0 dump copies the entire filesystem to the dump volume. ffff Place the dump on the next _a_r_g_u_m_e_n_t file instead of the default tape device /_d_e_v/_t_a_p_e. If the name of the file is ``-'', _d_u_m_p writes to standard output. If the name of the file is of the format _m_a_c_h_i_n_e:_d_e_v_i_c_e, the _f_i_l_e_s_y_s_t_e_m is dumped across the network to the remote machine. Since _d_u_m_p is normally run by root, the name of the local machine must appear in the ._r_h_o_s_t_s file of the remote machine. If the filename _a_r_g_u_m_e_n_t is of the form _u_s_e_r@_m_a_c_h_i_n_e:_d_e_v_i_c_e, _d_u_m_p attempts to execute as the specified user on the remote machine. The specified user must have a ._r_h_o_s_t_s file on the remote machine that allows root from the local machine. _d_u_m_p creates a remote server, /_e_t_c/_r_m_t, on the client machine to access the tape device. uuuu If the dump completes successfully, write the date of the beginning of the dump on file /_e_t_c/_d_u_m_p_d_a_t_e_s. This file records a separate date for each filesystem and each dump level. The format of /_e_t_c/_d_u_m_p_d_a_t_e_s is readable by people, consisting of one free format record per line: filesystem name, increment level, and _c_t_i_m_e(3C) format dump date. /_e_t_c/_d_u_m_p_d_a_t_e_s can be edited to change any of the fields, if necessary. PPPPaaaaggggeeee 1111 dddduuuummmmpppp((((1111MMMM)))) dddduuuummmmpppp((((1111MMMM)))) ssss The size of the dump tape is specified in feet. The number of feet is taken from the next _a_r_g_u_m_e_n_t. It is recommended that the CCCC option be used instead, as it is more predictable. When the specified size is reached, _d_u_m_p prompts the operator and wait for the reel/volume to be changed. dddd The density of the tape, expressed in BPI (bytes per inch), is taken from the next _a_r_g_u_m_e_n_t. This is used in calculating the amount of tape used per reel. It is recommended that the CCCC option be used instead, as it is more predictable. bbbb The blocking factor (number of 1-kilobyte blocks written out together) is taken from the next _a_r_g_u_m_e_n_t. The default is 10. The default blocking factor for tapes of density 6250 BPI and greater is 32. For some network, tape type, and server combinations, there may be a significant throughput improvement by using a blocking factor of 32, rather than the default of 10, when using rdump. If values larger than 32 are used, _r_e_s_t_o_r_e does not correctly determine the block size unless the bbbb option is also used. To maximize tape utilization, use a blocking factor that is a multiple of 8. For most types of supported tape drives, the greatest capacity and tape throughput is obtained using a blocking factor of 128 or even larger; note that _r_e_s_t_o_r_e(1M) automatically determines the blocking factor only if it is 32 or less. CCCC This specifies the total tape capacity in 1-kilobyte blocks, overriding the cccc, ssss, and dddd arguments if they are also given. Unlike the size and density arguments, the capacity is used as specified, no correction factors are applied. Since capacity lost to retries or underruns (by the drive), are not taken into account, you should be conservative when specifying capacity. The _a_r_g_u_m_e_n_t is parsed with _s_t_r_t_o_u_l(3C), so it can be in any base (for example, a 0x prefix specifies a hexadecimal value, a 0 prefix specifies octal, no prefix is decimal). The argument can have a kkkk, KKKK, mmmm, or MMMM suffix. The first two multiply the value by 1024, the third and fourth multiply by 1048576, so a tape with a 2.2 Gbyte capacity might be specified as CCCC 2222mmmm allowing 10% loss to retries, and so on. When the specified capacity has been written, _d_u_m_p prompts the operator and wait for the reel/volume to be changed. It is not currently possible to specify different capacities for different volumes of multi-volume backups. cccc Indicates that the tape is a cartridge tape instead of the standard default half-inch reel. This should always be specified when using cartridge tapes, unless the CCCC option is used. The values for blocking factor, size, and density are taken to be 10 (1-kilobyte blocks), 5400 feet, and 1000 BPI respectively unless overridden with the bbbb, ssss, or dddd option. PPPPaaaaggggeeee 2222 dddduuuummmmpppp((((1111MMMM)))) dddduuuummmmpppp((((1111MMMM)))) WWWW _d_u_m_p tells the operator what filesystems need to be dumped. This information is gleaned from the files /_e_t_c/_d_u_m_p_d_a_t_e_s and /_e_t_c/_f_s_t_a_b. The WWWW option causes _d_u_m_p to print out, for each filesystem in /_e_t_c/_d_u_m_p_d_a_t_e_s, the most recent dump date and level and highlights those filesystems that should be dumped. The _m_n_t__f_r_e_q field in the /_e_t_c/_f_s_t_a_b entry of the filesystem must be nonzero for _d_u_m_p to determine whether the filesystem should be dumped or not. If the WWWW option is set, no other option must be given and _d_u_m_p exits immediately. wwww Is like WWWW, but prints only those filesystems that need to be dumped. nnnn Whenever _d_u_m_p requires operator attention, notify by means similar to a _w_a_l_l(1) all of the operators in the group ooooppppeeeerrrraaaattttoooorrrr. _d_u_m_p reads the character device associated with the _f_i_l_e_s_y_s_t_e_m and dumps the contents onto the specified tape device. It searches /_e_t_c/_f_s_t_a_b to find the associated character device. NNNNOOOOTTTTEEEESSSS _r_d_u_m_p is a link to _d_u_m_p. OOOOppppeeeerrrraaaattttoooorrrr IIIInnnntttteeeerrrrvvvveeeennnnttttiiiioooonnnn _d_u_m_p requires operator intervention on these conditions: end of tape, end of dump, tape write error, tape open error, or disk read error (if there are more than a threshold of 32). In addition to alerting all operators implied by the nnnn key, _d_u_m_p interacts with the operator on _d_u_m_p's control terminal at times when _d_u_m_p can no longer proceed or if something is grossly wrong. All questions _d_u_m_p poses must be answered by typing yyyyeeeessss or nnnnoooo, appropriately. Since making a dump involves a lot of time and effort for full dumps, _d_u_m_p checkpoints itself at the start of each tape volume. If writing that volume fails for some reason, _d_u_m_p, with operator permission, restarts itself from the checkpoint after the old tape has been rewound and removed and a new tape has been mounted. _d_u_m_p reports periodically, including usually the percentage of the dump completed, low estimates of the number of blocks to write in 1-kilobyte blocks (or, more strictly, TP_BSIZE units from _p_r_o_t_o_c_o_l_s/_d_u_m_p_r_e_s_t_o_r_e._h), the number of tapes it will take, the time to completion, and the time to the tape change. The estimated time is given as hours:minutes and is based on the time taken to dump the blocks already on tape. It is normal for this estimate to show variance, and the estimate improves over time. The output is verbose, so that others know that the terminal controlling _d_u_m_p is busy and will be for some time. SSSSuuuuggggggggeeeesssstttteeeedddd DDDDuuuummmmpppp SSSScccchhhheeeedddduuuulllleeee It is vital to perform full level 0 dumps at regular intervals. When performing a full dump, bring the machine down to single-user mode using sssshhhhuuuuttttddddoooowwwwnnnn ----iiiissss. Otherwise the dump may not be internally consistent and may not restore correctly. While preparing for a full dump, it is a good PPPPaaaaggggeeee 3333 dddduuuummmmpppp((((1111MMMM)))) dddduuuummmmpppp((((1111MMMM)))) idea to clean the tape drive and heads (most types of drives require head cleaning for approximately every 30 hours of tape motion). Incremental dumps allow for convenient backup and recovery of active files on a more frequent basis, with a minimum of media and time. However, there are some trade-offs. First, the interval between backups should be kept to a minimum (once a day at least). To guard against data loss as a result of a media failure (a rare but possible occurrence), it is a good idea to capture active files on (at least) two sets of dump volumes. Keep unnecessary duplication of files to a minimum to save both operator time and media storage. A third consideration is the ease with which a particular backed up version of a file can be located and restored. The following four-week schedule offers a reasonable trade-off between these goals. Sun Mon Tue Wed Thu Fri Week 1: Full 5 5 5 5 3 Week 2: 5 5 5 5 3 Week 3: 5 5 5 5 3 Week 4: 5 5 5 5 3 Although the Tuesday through Friday incrementals contain extra copies of files from Monday, this scheme assures that any file modified during the week can be recovered from the previous day's incremental dump. DDDDuuuummmmpppp PPPPaaaarrrraaaammmmeeeetttteeeerrrrssss Since it is suggested that the CCCC option be used instead of the density and size options, and since those values are almost never really correct for any tape drive except 9 track tapes, recommended values for these parameters are no longer suggested in this man page. As an example of the capacity, a typical QIC150 cartridge would use CCCC 111144440000kkkk, a DDS1 90 meter DAT or 112 meter 8mm (8200 mode) cartridge would use CCCC 1111888800000000kkkk, and a DDS2 120 meter cartridge would use CCCC 3333888800000000kkkk. EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS /dev/usr /usr efs rw,raw=/dev/rdsk/dks0d1s6 0 0 Here are a few examples on how to dump the /_u_s_r filesystem with the above /_e_t_c/_f_s_t_a_b entry. _dddd_uuuu_mmmm_pppp _0000_CCCC_ffff_uuuu _1111_4444_0000_kkkk _gggg_uuuu_eeee_ssss_tttt_@@@@_kkkk_eeee_ssss_tttt_rrrr_eeee_llll_::::_////_dddd_eeee_vvvv_////_tttt_aaaa_pppp_eeee _////_uuuu_ssss_rrrr does a level 0 dump of /_u_s_r onto a remote cartridge tape device /_d_e_v/_t_a_p_e on host kestrel using the guest account. _d_u_m_p also updates the file /_e_t_c/_d_u_m_p_d_a_t_e_s. _dddd_uuuu_mmmm_pppp _2222_CCCC_uuuu _1111_4444_0000_kkkk _////_uuuu_ssss_rrrr does a level 2 dump of /_u_s_r to the local cartridge tape device /_d_e_v/_t_a_p_e and also updates the file /_e_t_c/_d_u_m_p_d_a_t_e_s. PPPPaaaaggggeeee 4444 dddduuuummmmpppp((((1111MMMM)))) dddduuuummmmpppp((((1111MMMM)))) dump 0Cb 140k 128 /usr does a level '0' dump of /_u_s_r to the local tape device /_d_e_v/_t_a_p_e using a blocking factor of 128. The tape is specified to have a capacity of 140 megabytes in the second, which allows for retries, space lost to repositioning, and so on. It is also appropriate for a QIC 150 quarter- inch tape drive. The ordering of the arguments depends on the ordering of the key. _dddd_uuuu_mmmm_pppp _1111_CCCC_ffff _1111_4444_0000_kkkk _////_dddd_eeee_vvvv_////_mmmm_tttt_////_tttt_pppp_ssss_0000_dddd_7777 _////_uuuu_ssss_rrrr _dddd_uuuu_mmmm_pppp _1111_CCCC_ffff _1111_4444_0000_kkkk _////_dddd_eeee_vvvv_////_mmmm_tttt_////_tttt_pppp_ssss_0000_dddd_7777 _////_dddd_eeee_vvvv_////_rrrr_dddd_ssss_kkkk_////_dddd_kkkk_ssss_0000_dddd_1111_ssss_6666 both do a level 1 dump of /_u_s_r to the local cartridge tape. _dddd_uuuu_mmmm_pppp _////_uuuu_ssss_rrrr does a level 9 dump of /_u_s_r to the local tape device /_d_e_v/_t_a_p_e and updates the file /_e_t_c/_d_u_m_p_d_a_t_e_s. dump 9uCf 2048k /dev/mt/tps0d6nrnsv /os dump 9uCf 2m /dev/mt/tps0d6nrnsv /os Both do a level 9 dump of /_o_s to the local tape device /_d_e_v/_m_t/_t_p_s_0_d_6_n_r_n_s_v where the tape device being used is an 8mm tape drive, and we are being somewhat optimistic about the capacity. _dddd_uuuu_mmmm_pppp _WWWW prints out, for each filesystem in /_e_t_c/_d_u_m_p_d_a_t_e_s, the most recent dump date and level and highlights those filesystems that should be dumped. FFFFIIIILLLLEEEESSSS /dev/tape default tape unit to dump to /etc/dumpdates new format dump date record /etc/fstab dump table: filesystems and frequency /etc/group to find group _o_p_e_r_a_t_o_r SSSSEEEEEEEE AAAALLLLSSSSOOOO restore(1M), rmt(1M), shutdown(1M), xfsdump(1M), xfsrestore(1M), wall(1), ctime(3C), fstab(4), group(4), rhosts(4), dump(5), mtio(7). DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS While running, _d_u_m_p emits many verbose messages. The exit codes are 0 Normal exit 1 Startup errors encountered 3 Abnormal termination PPPPaaaaggggeeee 5555 dddduuuummmmpppp((((1111MMMM)))) dddduuuummmmpppp((((1111MMMM)))) BBBBUUUUGGGGSSSS Fewer than 32 read errors on the filesystem are ignored. Each reel requires a new process, so parent processes for reels already written just hang around until the entire tape is written. _d_u_m_p with the WWWW or wwww options does not report filesystems that have never been recorded in /_e_t_c/_d_u_m_p_d_a_t_e_s, even if listed in /_e_t_c/_f_s_t_a_b. It would be nice if _d_u_m_p knew about the dump sequence, kept track of the tapes scribbled on, told the operator which tape to mount when, and provided more assistance for the operator running _r_e_s_t_o_r_e. It is recommended that incremental dumps also be performed with the system running in single-user mode. _d_u_m_p needs accurate information regarding the length and density of the tapes used. It can dump the filesystem on multiple volumes, but since there is no way of specifying different sizes for multiple tapes, all tapes used should be at least as long as the specified/default length. If _d_u_m_p reaches the end of the tape volume unexpectedly (as a result of a longer than actual length specification), it aborts the entire dump. This can be a problem when writing multiple dumps to the same physical tape, or when the tape drive supports hardware compression, and it is not possible to determine the average compression ratio ahead of time. Currently the only solution to this problem in this version of _d_u_m_p is to be conservative in specifying capacity. PPPPaaaaggggeeee 6666