Backup3G FAQ
This page was last modified 04:13, 14 September 2007.From Documentation
Revision as of 06:17, 21 July 2006 Mike (Talk | contribs) (→How can I get a background backup job to output the log to standard out?) ← Previous diff |
Current revision Moff (Talk | contribs) (→Recovery Commands) |
||
Line 1: | Line 1: | ||
- | == How do I perform a recovery from a backup without the COSmanager Framework? == | + | == How do I perform a recovery from a backup without Backup3G? == |
- | Performing a restore without COSmanager can be easily accomplished as all backup methods provided make use of common Unix commands. The formats involved are cpio, tar and dump. However, because of the flexabilty in setting up backups through COSmanager, a backup may be comprised of multiple format tape files, and even accross multiple volumes. Then the main issue in recovering files at the command line level is not so much knowing the commands, but knowing what the layout of a given tape, or set of tapes is. Following are the commands required to recover in full a tape file as backed up using a provided backup method. | + | Performing a restore without Backup3G can be easily accomplished as all backup methods provided make use of common Unix commands. The formats involved are cpio, tar or dump. However, because of the flexibility of setting up backups through Backup3G, a backup may be comprised of multiple format tape files, and even across multiple volumes. Then the main issue in recovering files at the command line level is not so much knowing the commands, but knowing the layout of a given tape, or set of tapes, and hence the number of tape files that must be skipped. Following are the commands required to recover in full a tape file as backed up using a provided backup method. |
== Recovery Commands == | == Recovery Commands == | ||
Line 8: | Line 8: | ||
mt -f <no-rewind device> fsf 3 | mt -f <no-rewind device> fsf 3 | ||
or | or | ||
- | mt -t <no-rewind device> fsf 3if | + | mt -t <no-rewind device> fsf 3 |
on HP/UX or | on HP/UX or | ||
dd if=<no-rewind device> of=/dev/null | dd if=<no-rewind device> of=/dev/null | ||
- | three times. Then recover the tape file according to the backup format as follows. For the standard cpio backup using the FS-wrapper FScpio use the following command to recover in full: | + | three times. Then recover the tape file according to the backup format as follows. First change into the directory into which you want to restore the files. For a cpio backup use the following command to recover in full: |
- | dd if=$Device_nr ibs=<bs> | cpio -icdum | + | dd if=<no-rewind device> ibs=<bs> | cpio -icdum |
- | For the standard tar backup using the FS-wrapper FStar use the following command to recover in full: | + | For a tar backup use the following command to recover in full: |
- | dd if=$Device_nr ibs=<bs> | tar xpf - | + | dd if=<no-rewind device> ibs=<bs> | tar xpf - |
- | For the standard dump backup using the FS-wrapper FSdump use the following command to recover in full: | + | For a dump backup use the following command to recover in full: |
- | dd if=$Device_nr ibs=<bs> | ufsrestore xf - | + | dd if=<no-rewind device> ibs=<bs> | ufsrestore -xf - |
for SVR4 versions of Unix, or | for SVR4 versions of Unix, or | ||
- | dd if=$Device_nr ibs=<bs> | restore xf - | + | dd if=<no-rewind device> ibs=<bs> | restore -xf - |
for SVR3 and Berkley versions of Unix. Where <bs> is the blocksize associated with the media type multiplied by 1024. For example, if your DAT media type has a blocksize of 32 kbytes associated with it then <bs> will be 32768. | for SVR3 and Berkley versions of Unix. Where <bs> is the blocksize associated with the media type multiplied by 1024. For example, if your DAT media type has a blocksize of 32 kbytes associated with it then <bs> will be 32768. | ||
Line 98: | Line 98: | ||
#audit trail directory /usr/spool/log | #audit trail directory /usr/spool/log | ||
- | Have on hand the hardcopy catalogue of this tapes contents. | + | Have on hand the hardcopy catalogue of this tape's contents. |
- | Initially recover the root file system, then COSmanager and the audit trail directory. See FAQ How do I perform a recovery from backup without COSmanager? to do this. | + | Initially recover the root file system, then COSmanager and the audit trail directory. See FAQ How do I perform a recovery from backup without Backup3G to do this. |
- | After recovering COSmanager, you must acknowledge the backup job that performed this backup so that the status tables are cleared. For version 2.4.x this done by performing the option Unload media from drive on the Manage removable media jobs menu. For version 2.5.x this is done by performing the option Acknowledge job completion on the Manage removable media jobs menu. This will return COSmanager to the status just after the above backup was completed. | + | After recovering COSmanager, you must acknowledge the backup job that performed this backup so that the status tables are cleared. This is done by performing the option Acknowledge job completion on the Manage removable media jobs menu. This will return Backup3G to the status just after the above backup was completed. |
- | You can now use COSmanager to perform the recovery of the rest of your system. This may mean applying incremental backups to full backups. | + | You can now use Backup3G to perform the recovery of the rest of your system. This may mean applying incremental backups to full backups. |
== How do I perform an interactive dump recovery? == | == How do I perform an interactive dump recovery? == | ||
Line 138: | Line 138: | ||
setpgrp runback ${load_now:+-L} "$Drive" $ID "$Job" 2>&1 | tee $LOG | setpgrp runback ${load_now:+-L} "$Drive" $ID "$Job" 2>&1 | tee $LOG | ||
+ | |||
+ | == CPIO versus TAR versus DUMP (draft) == | ||
+ | Advantages of CPIO: | ||
+ | |||
+ | *allows file/pathnames of up to 1024 characters | ||
+ | *streaming, ie. non-blocked, output is good for non-blocking devices (networks, disk files, some tape drives) | ||
+ | *uses wildcards to match filenames upon restore | ||
+ | *can interactively rename files during restore | ||
+ | *reads list of filenames to backup from stdin; this allows for precise control of files backed up, but can be an inconvenience as well since more thought has to go into using the command | ||
+ | *flexible use at the beginning or end of a shell pipeline, or as a filter (read filenames from stdin, send archive to stdout, or vice versa) | ||
+ | *preserves hard links and symbolic links, as selected by options | ||
+ | *SVR4 (and Solaris) support multiple volumes | ||
+ | *backup and restore special device files | ||
+ | *supports incremental backups | ||
+ | |||
+ | Disadvantages of CPIO: | ||
+ | *recovering files from a damaged archive can prove difficult if the archive contains other cpio archives, since the embedded archive trailer will cause recovery to become out-of-sync | ||
+ | *filesystems being backed up *must* be mounted; a file could be modified while being written to media | ||
+ | *no built-in method for incrementals (must use "find -mtime" technique, which has crude granularity) | ||
+ | *format is not portable from SVR4 to SVR3 | ||
+ | |||
+ | Disadvantages of TAR: | ||
+ | *may not handle very long filenames | ||
+ | *filesystems being backed up *must* be mounted; a file could be modified while being written to media | ||
+ | |||
+ | Advantages of DUMP: | ||
+ | *maintains an index on the tape | ||
+ | *supports backup of unmounted filesystems | ||
+ | |||
+ | Disadvantages of DUMP: | ||
+ | *does not read through the filesystem, but reads the raw device. Therefore dump backups can be out of sync with the in memory copy of the filesystem | ||
+ | *filesystems should be unmounted before performing a dump backup | ||
+ | *restore will not work remotely because it opens /dev/tty | ||
+ | *format not portable across all platforms | ||
+ | *not available on all platforms/filesystems |
Current revision
How do I perform a recovery from a backup without Backup3G?
Performing a restore without Backup3G can be easily accomplished as all backup methods provided make use of common Unix commands. The formats involved are cpio, tar or dump. However, because of the flexibility of setting up backups through Backup3G, a backup may be comprised of multiple format tape files, and even across multiple volumes. Then the main issue in recovering files at the command line level is not so much knowing the commands, but knowing the layout of a given tape, or set of tapes, and hence the number of tape files that must be skipped. Following are the commands required to recover in full a tape file as backed up using a provided backup method.
Recovery Commands
Let us assume that the format and layout of the backup tape is known. Firstly you need to change directory to the base directory you are about to recover.
cd <base directory>
Secondly, you need to skip to the to the beginning of the appropriate tape file. Remember that the electronic media label is the first tape file. For example, you need to recover /usr which is the third step in your backup, therefore you need to skip to the beginning of the fourth tape file.
mt -f <no-rewind device> fsf 3
or
mt -t <no-rewind device> fsf 3
on HP/UX or
dd if=<no-rewind device> of=/dev/null
three times. Then recover the tape file according to the backup format as follows. First change into the directory into which you want to restore the files. For a cpio backup use the following command to recover in full:
dd if=<no-rewind device> ibs=<bs> | cpio -icdum
For a tar backup use the following command to recover in full:
dd if=<no-rewind device> ibs=<bs> | tar xpf -
For a dump backup use the following command to recover in full:
dd if=<no-rewind device> ibs=<bs> | ufsrestore -xf -
for SVR4 versions of Unix, or
dd if=<no-rewind device> ibs=<bs> | restore -xf -
for SVR3 and Berkley versions of Unix. Where <bs> is the blocksize associated with the media type multiplied by 1024. For example, if your DAT media type has a blocksize of 32 kbytes associated with it then <bs> will be 32768.
How do I print a catalogue of my backup tapes?
COSmanager can simplify this by automatically printing a log of a media set contents immediately after a backup has completed. To do this place the following command in the At-end cmd for the backup job definition.
( medrep -d 0 ; FSdrive $Drive list ) | asuser cosmos $PRINTCMD
Or you can key in the script shown at the end of this section called ~cosmos/local/bin/medcat and use the following command in either the At-end cmd or the At-unload cmd of the backup job definition. Remember to make the script executable.
( banner $Set_ID ; medcat $Set_ID ; FSdrive $Drive list ) | asuser cosmos $PRINTCMD
An example of this media contents log is shown below. The printout also shows the tape drive operations commands for the backup drive. Knowing these and the devices involved will be useful when, for example, you need to recover /var/spool - the fifth tape file.
Media written in the last 0 days. #1054 DAT-hi Written: 17/08/94 Expires: 24/08/94 Location: FS Full backup of gomez using portable cpio File 2 17/08/94-00:01 full dump gomez:/ Full backup of / File 3 17/08/94-00:13 portable full cpio gomez:/usr Full backup of /usr File 4 17/08/94-00:18 portable full cpio gomez:/opt Full backup of /opt File 5 17/08/94-00:53 full tar gomez:/var/spool Full backup of /var/spool File 6 17/08/94-02:00 portable full cpio gomez:/local Full backup of /local
Drive dat (Sun DAT unit) Type DAT-hi Host gomez Device /dev/rmt/1 No-rewind device /dev/rmt/1n Drive name dat Operator message DAT drive needs attention Drive class mt_tape (Tape operations via MT(1) command) ----- Operations ---------------------------------------------------- Status mt -f $Device_nr status Rewind mt -f $Device_nr rewind Skip forward mt -f $Device_nr fsf $N Skip backward mt -f $Device_nr bsf $N Unload media mt -f $Device_nr offline Where $Device refers to the device /dev/rmt/1 above and $Device_nr refers to the no-rewind device /dev/rmt/1n. In the Skip forward and Skip backward operation, $N refers to the number of tape files to be skipped.
Script ~cosmos/../backup_3.2/local/bin/medcat
#! /bin/sh # # medcat.sh # # Copyright (c) 1991-1994 Functional Software # All Rights Reserved # # Media reports # # ident "@(#)medcat.sh 1.1 (Functional Software - FSadmin) 94/08/30" # USAGE="Usage: medcat Set_ID" if [ -z "$1" ]; then echo $USAGE >&2 exit 1 fi SORTPARMS="Written Set_ID Sequence File" RPTPGM=msetrep.awk db_sel media "Set_ID == \"$1\" && Usage != \"scratch\"" | \ db_join -n - medcont Number | \ db_sort - $SORTPARMS | \ db_rpt - $APPL_HOME/report/$RPTPGM
How do I accomodate for disaster recovery? (draft)
A backup must contain the following:
- file system
- COSmanager directory structure
- audit trail directory /usr/spool/log
Have on hand the hardcopy catalogue of this tape's contents.
Initially recover the root file system, then COSmanager and the audit trail directory. See FAQ How do I perform a recovery from backup without Backup3G to do this.
After recovering COSmanager, you must acknowledge the backup job that performed this backup so that the status tables are cleared. This is done by performing the option Acknowledge job completion on the Manage removable media jobs menu. This will return Backup3G to the status just after the above backup was completed.
You can now use Backup3G to perform the recovery of the rest of your system. This may mean applying incremental backups to full backups.
How do I perform an interactive dump recovery?
Setup new recovery method as follows:
Method: dump interactive Description: Recover interactive from dump Format: dump Index Command: Full Recovery: cd $Directory ; ufsrestore -ivf $Device_nr < /dev/tty Selected Rcvry: Use STDOUT? no Remote support? no Run on host: file_host
How can I get a report detailing steps of all backup jobs run across my Data Center?
Setup an at-request duty that calls the following script:
for host in `db_sel -h hostinfo "Admintype != \"\"" Hostname`; do for bujob in `FSremote $host "db_proj -h backup Job"`; do echo "Host: $host\n\n" FSremote $host "showback $bujob" echo "\n\n" done done | scroll -H0
How can I get a background backup job to output the log to standard out?
Some people wish to capture the backup log to other than the log file itself. Either for it to be mailed to a user or to be captured by a task/batch scheduler system. This can be done by a minor change to backup_3.2/bin/FSbackup. Change the line (around line 206 in the background portion of the case statement)
setpgrp runback ${load_now:+-L} "$Drive" $ID "$Job" >$LOG 2>&1
to
setpgrp runback ${load_now:+-L} "$Drive" $ID "$Job" 2>&1 | tee $LOG
CPIO versus TAR versus DUMP (draft)
Advantages of CPIO:
- allows file/pathnames of up to 1024 characters
- streaming, ie. non-blocked, output is good for non-blocking devices (networks, disk files, some tape drives)
- uses wildcards to match filenames upon restore
- can interactively rename files during restore
- reads list of filenames to backup from stdin; this allows for precise control of files backed up, but can be an inconvenience as well since more thought has to go into using the command
- flexible use at the beginning or end of a shell pipeline, or as a filter (read filenames from stdin, send archive to stdout, or vice versa)
- preserves hard links and symbolic links, as selected by options
- SVR4 (and Solaris) support multiple volumes
- backup and restore special device files
- supports incremental backups
Disadvantages of CPIO:
- recovering files from a damaged archive can prove difficult if the archive contains other cpio archives, since the embedded archive trailer will cause recovery to become out-of-sync
- filesystems being backed up *must* be mounted; a file could be modified while being written to media
- no built-in method for incrementals (must use "find -mtime" technique, which has crude granularity)
- format is not portable from SVR4 to SVR3
Disadvantages of TAR:
- may not handle very long filenames
- filesystems being backed up *must* be mounted; a file could be modified while being written to media
Advantages of DUMP:
- maintains an index on the tape
- supports backup of unmounted filesystems
Disadvantages of DUMP:
- does not read through the filesystem, but reads the raw device. Therefore dump backups can be out of sync with the in memory copy of the filesystem
- filesystems should be unmounted before performing a dump backup
- restore will not work remotely because it opens /dev/tty
- format not portable across all platforms
- not available on all platforms/filesystems