Unix Backup and Recovery phần 5 potx

Primary I-cache size: 16 Kbytes Primary D-cache size: 16 Kbytes Secondary cache size: 2048 Kbytes Memory size: 256 Mbytes Graphics: GR3-XZ SCSI Disk: scsi(0)disk(1) SCSI CD-ROM: scsi(1)CD-ROM(3) SCSI Tape: scsi(1)tape(4) Audio: Iris Audio Processor: version A2 revision 0.1.0 Next, boot the standalone fx program. The filenames of the sash and fx programs for the various SGI processor types are included in Table 11-1. Table 11-1. sash and fx Programs for Different Architectures CPU Architecture sash fx IP17 sash IP 17 fx.IP17 IP19, IP20, IP22, IP32 sashARCS fx.ARCS IP21, IP25, IP26, IP27, IP30 sash64 fx.64 To boot from a local CD-ROM drive, use a command like this: >> boot -f dksc(1,3,8)sashARCS dksc(1,3,7)stand/fx.ARCS x Replace dksc(1,3,8) and dksc(1,3,7) with the appropriate CD-ROM drive from the hinv output of the system being recovered, and sashARCS and fx.ARCS with the appropriate standalone program names from the table. Some of the sash and fx filenames have the processor type as a suffix, such as sashIP17 and fx.IP17. To boot fx from a remote machine, check to make sure the boot PROM variable netaddr is set to the system's IP address, then issue the boot command: >> printenv netaddr netaddr=192.0.2.1 >> boot -f bootp()remote:/CD-ROM/stand/fx.ARCS -x Page 312 The fx program will prompt you for the device name of the disk, the controller number, and the drive number; the default values are what most systems would use: fx: "device-name" = (dksc) fx: ctrl# = (0) fx: drive# = (1) You should check for any existing partition information using the /show/label/partition command. If the partition information appears to be correct, you can exit fx to return to the System Maintenance Menu; if not, you have to correct the partition information. Most standard SGI system disks use either the rootdrive or usrrootdrive partition template, which can be found in the repartition submenu of fx. Make sure to use the /label/sync command to ensure that the system disk partition table is written out, and then use the exit command to leave fx and return to the System Maintenance Menu. Now we can start the system recovery by choosing menu option 4, Recover System. The system may display the following, or an equivalent if graphics are available: System Recovery Press Esc to return to the menu. From this point on, the prompts and your responses will differ depending on the age of the system. Older SGI Systems Some older SGI systems present you with the following prompt after a short time: Insert the installation tape, then press <enter>: At this point you would make sure that either a bootable tape (your IRIX installation tape will work) is loaded into a local tape drive or that an IRIX installation CD-ROM is in a local CD-ROM drive. You then would press Enter to start loading the miniroot onto partition 1 of the system disk. Note that this procedure requires that the installation device be physically attached; booting from a remote system is described later. After a few minutes, the system prompts you for the type of restore: CRASH RECOVERY You may type sh to get a shell prompt at most questions. Remote or local restore: ([r]emote, [l]ocal): [1] Choose the appropriate type of restore, either remote or local. If you choose remote, the system prompts you for the name of the remote host and the tape drive name on the remote host. Make sure that your Backup tape is in the remote tape drive, and enter the IP address for the remote host as well as the name of the tape drive. If you choose to perform a local restore, the system prompts you only Page 313 for the name of the local tape drive. Make sure that the Backup tape is in your local tape drive, and enter the full name of the tape drive rather than /dev/tape. As an example, if you want to use tape drive that is set to SCSI ID 3 and is attached to SCSI controller 0, you would use /dev/rmt/tps0d3nr. If you do not have a tape or CD-ROM locally attached to the system you are recovering, you will need to enable tftp on a remote system and configure the boot PROM to enable booting across the network. On the remote system, edit the file /usr/etc/inetd.conf. Find the line that contains tftp and change it to be the following: tftp dgram udp wait guest /usr/etc/tftpd tftpd This allows tftp full access to the filesystems on the remote system; make sure to either change this line back to what it was before or comment it out completely once the recovery is completed. Also, make sure that you use Tabs for the whitespace separating the individual words. Next, signal inetd on the remote system by sending it a HUP signal. On some older versions of IRIX, inetd is broken, requiring you to issue a killall -9 inetd and restart it by hand. Now you need to configure the system you are recovering to boot from the remote system. Rather than choosing menu item 4 from the System Maintenance Menu, choose item 5, Enter Command Monitor. Issue the following PROM commands: >> setenv netaddr ip-address >> init >> exit Replace ip-address with the IP address of the system you are recovering, not the remote system. When the system returns to the System Maintenance Menu, choose item 4, Recover System, and follow the preceding steps for recovering. Newer SGI systems Newer systems will present you with this short menu, or something much like it if graphics are available, for specifying where the installation media is: 1) Remote Tape 2) Remote Directory 3) Local CD-ROM 4) Local Tape Enter 1-4 to select source type, Esc to quit, or Enter to start: Choices 1 (Remote Tape) and 4 (Local Tape) are not supported as bootable as of IRIX 6.2. To start recovery using a local CD-ROM, put your installation CD-ROM into the CD-ROM drive and choose item 3. Choose item 2 for either a remote CD-ROM or a remote software distribution directory. The system prompts you for the local system's IP address, if not set by the boot PROM, and the remote hostname and directory. The format should be remotehost:/directory/dist, where remotehost is the name of the remote host, and directory the name of the Page 314 remote directory. If you want to use remote CD-ROM drive, the remote host name might look much like: remotehost:/CD-ROM/dist When using a remote software distribution directory, the remote hostname contains just the full pathname to the directory, like: remotehost:/directory/dist/6.3 The system returns to the Source Type menu; press Enter to begin reading the installation tools to partition 1 of the system disk. After a few minutes, the following is displayed: ************************************************************ * * * CRASH RECOVERY * * * ************************************************************ You may type sh to get a shell prompt at most questions Please enter your hostname (system name) : muddy Please enter the IP address for muddy's Integral Ethernet interface (ec0): 172.16.0.1 Starting networking with primary hostname muddy Checking for tape devices If the system you are recovering has a locally attached tape drive, you will see the following: Restore will be from /dev/tape. OK? ([y]es, [n]o): [y] If this is correct, press Enter. If not (and you answer no to the prompt) or if a local tape drive cannot be found, then the following is displayed: Remote or local restore ([r]emote, [l]ocal) : [1] At this point, choosing [l]ocal allows you to specify a different local tape drive if the previous message was incorrect. Choosing [r]emote asks you for the remote hostname and the remote tape drive name. The system then prints out tape drive status information and prompts you for the first tape: Insert the first Backup tape in the drive, then press (<enter>, [q]uit (from recovery) ,[r]estart): Insert the first full Backup tape and press Enter. After a few minutes, messages like the following will be shown: Backup is a cpio archive label: Full system backup from / Thu Feb 25 17:25:47 PST 1999 Page 315 user: root group: sys IRIX muddy 6.5 05190003 IP22 IRIX 6.5:1274627333 built 4/29/98 at zebub:/xlv55/kudzu-apr12/root $ options: /sbin/cpio -KWovO /dev/tape Do you want to proceed ([y]es, [r]etry, [q]uit): [y] If this is the correct tape information, press Enter and the system configuration files will be read. Next, you will have the opportunity to re-create the filesystems on the system disk: Erase all old filesystems and make new ones (y, n, sh): [n] Choosing y will destroy any data remaining on your system, while choosing n will allow you to preserve the old filesystems. You also can choose sh for a shell, which will let you use the miniroot commands to poke around your old filesystems to see if anything can be salvaged. If you choose y, the system asks you for confirmation when rebuilding each filesystem. If you choose n, or when you finish rebuilding the filesystems, a table of the currently mounted filesystems will be displayed. If everything is there, press Enter to start recovery from the Backup tape. Once that has completed, it will ask if you want to read any incremental Backup tapes, at which point you can choose to do so. The very last step allows you to read the first Backup tape again, start over from the beginning, or reboot the recovered system: Reboot, start over, or first tape again? ([r]eboot, [s]tart, [f]irst) [r] If you haven't made any mistakes, you should choose to reboot. Congratulations! Your SGI system should be in the same state that it was when the Backup tape used for recovery was created. Homegrown Bare-Metal Recovery This procedure for recovering a failed SGI IRIX system takes a few shortcuts from what SGI would have you do. Their recommendation is to perform an IRIX installation, followed by the use of restore (or xfsrestore for restoring XFS dumps). We will bypass the IRIX installation and instead use the miniroot to perform the baremetal recovery. In order to perform this type of bare-metal recovery you will need the correct IRIX installation tape or CD-ROM or a bootable IRIX tape (only for IRIX 5.3 and 6.1). You also will need your current dump volumes, along with a listing of which partitions are on what volumes and in what order, and printed copies of the output of the hinv command, the system's partition and volume header information, and the /etc/fstab file. You might guess that it is a little difficult to keep track of how many Page 316 tape files a dump is made up of and much easier to recover a system during a panic situation if you keep your dump volumes simple. The installation media and configuration information needs to be gathered before disaster strikes. You should periodically print out all of the system configuration information. It is very difficult, if not impossible, to return a failed system to its original state without these things. Finding the partition information for each drive can be accomplished using the prtvtoc command. You would run the command once for each disk drive attached to the system and print the results: # prtvtoc /dev/rdsk/dks0lvh This command would print the volume table of contents, or partition information, for the SCSI drive on controller 0 with SCSI ID 1, which is typically the system disk. Another way to gather this information is by using fx: # echo "/label/show/partition" |fx 'dksc(0,1)' This shows the same information for the SCSI drive on controller 0 with SCSI ID 1 but in a format that might be easier to use, since we will be using fx during system recovery. You can use the dvhtool command to list the contents of the system disk volume header: # dvhtool -v list /dev/rvh We need this list to know what standalone files to put into the volume header if the header becomes damaged. Usually, the only standalone files that might have to be reinstalled are sash and possibly ide. If the system has any LV logical volumes, you will need a printed copy of /etc/lvtab. Note that the system's actual root and swap partitions cannot be LV volumes, but if /usr is separate, it is conceivable that it may have been grown by making it into an LV volume and adding an additional partition; recovering this case is beyond the scope of this book. You also will need a printed copy of the XLV configuration if it is using any XLV volumes, as well as a printed listing of the contents of the /dev/dsk/xlv directory. The root filesystem can be an XLV mirror (also called a plex), and /usr may have also been grown on the fly by making it an XLV volume and adding an additional partition. Recovering a /usr filesystem that has been changed in this way is beyond the scope of this book. Page 317 To create a file that contains a script that will duplicate your XLV configuration, you can use the xlv_mgr command. This is the same way that the IRIX Backup script extracts the configuration. # echo "script all\nquit\n" |xlv_mgr > /tmp/xlv_config_script To begin a bare-metal recovery, we will start out as if we are performing recovery with a Backup tape. We need to get the SGI system to the System Maintenance Menu. If your system prints messages like the following, either press Escape or click on the Stop for Maintenance button, if available: Starting up the system To perform system maintenance instead, press Esc Your system should then stop and print out the System Maintenance Menu: System Maintenance Menu (1) Start System (2) Install System Software (3) Run Diagnostics (4) Recover System (5) Enter Command Monitor This is where we deviate from the steps for bare-metal recovery using a Backup tape. Our methods will now be more down and dirty. First, we enter the Command Monitor to make sure all of our hardware is visible. Use the hinu command, paying special attention to the type of processor the system has and the SCSI disk, CD-ROM, and tape drives. We also will set the PROM variable AutoLoad: Command Monitor. Type "exit" to return to the menu. >> hinv System SGI-IP27 2 180 MHz IP27 Processors Main memory size: 640 Mbytes Integral SCSI controller 0 Integral SCSI controller 1 Integral Fast Ethernet IOC3 serial port Integral SCSI controller 2 Integral SCSI controller 3 Disk drive: unit 1 on SCSI Controller 0, (dksc(0,1,0)) Disk drive: unit 4 on SCSI Controller 0, (dksc(0,4,0)) Disk drive: unit 6 on SCSI Controller 0, (dksc(0,6,0)) CD-ROM: unit 6 on SCSI Controller 1, (CD-ROM(1,6,7)) Tape drive: unit 3 on SCSI Controller 2 >> setenv AutoLoad No Write down the processor type, the disk drive names (dksc(0,1,0)), the CD-ROM drive names (CD-ROM(1,6,7)), and the tape drive information (controller 2, SCSI ID 3). (This information may already be in the printed hinv output gathered while Page 318 the system was alive.) Setting AutoLoad prevents the system from booting, stopping it at the System Maintenance Menu. If the system does not have an ARCS PROM, the older bootmode variable has to be set instead: >> setenv bootmode m (You will know if the system has an ARCS PROM based on the name of the sash and fx programs from the previous table.) The next step is to boot the standalone fx program from the Command Monitor prompt to repair the system disk partitioning. You can boot either from a locally attached CD-ROM drive or from a CD-ROM drive on a remote system. The filenames of the sash and fx programs for the various SGI processor types are included in the previous table. To boot fx from a local CD-ROM drive, use a command like this: >> boot -f dksc(1,6,8)sashARCS dksc(1,6,7)stand/fx.ARCS x Replace dksc(1,6,8) and dksc (1,6,7) with the appropriate CD-ROM drive from the hinv output of the system being recovered, and sashARCS and fx.ARCS with the appropriate standalone program names from the table. To boot fx from a remote machine, check to make sure the boot PROM variable netaddr is set to the system's IP address, then issue the boot command: >> printenv netaddr netaddr=172.16.0.1 >> boot -f bootp()remote:/CD-ROM/stand/fx.ARCS -x The fx program will prompt you for the device name of the disk, the controller number, and drive number; the default values are what most systems would use: fx: "device-name" = (dksc) fx: ctrl# = (0) fx: drive# = (1) Before making any changes, it may be valuable to check for any existing partition information using the /show/label/partition command. If the partition information appears to be correct, you can exit fx to return to the System Maintenance Menu; if it is not correct, you will have to duplicate the partition information previously gathered. Most system disks have either the rootdrive or usrrootdrive partition scheme. If the partitioning is not standard, it may speed things up to start with a rootdrive template and modify it. Make sure to use the /label/sync command to make sure that any changes to the partitioning are written to the volume header. Once we have partitioned our system drive, we will boot the miniroot as if we were going to perform an IRIX installation. Choose menu item number 2, Install System Software. The system will then ask you for the source of the installation media. Select either the locally attached CD-ROM or a remote tape or directory. Page 319 To boot from a remote system, you will need to perform some of the same steps that were necessary for recovery using a Backup tape. You need to enable tftp on the remote system by editing the file /usr/etc/inetd.conf and changing the tftp line to the following: tftp dgram udp wait guest /usr/etc/tftpd tftpd This allows full access to the filesystems on the remote system. You should change this back to its previous value when you are finished with the recovery. Then, signal inetd by sending it a HUP signal. Back on the system you are recovering, it will ask you for the local system's IP address (if not set by the boot PROM), the remote system name, and the path to the installation directory. On older SGI systems, you may have to set the boot PROM variable netaddr to the local system's IP address. Once you tell the system where to install from, the system begins to load the installation tools to the swap partition. It prints out some messages and possibly shows a status bar as the installation tools are copied and the IRIX kernel boots. If the filesystems were completely destroyed, the system will ask you to make new ones as necessary. When creating a new XFS filesystem, it may ask you for a block size; just use 4096 unless there are some special requirements. There also may be partitions that the system is able to mount but that are, in fact, very corrupted. If this happens, the system will print out messages to that effect, then stop and prompt you with: Press Enter to invoke C shell csh: You should choose to launch the shell at this time. From the shell, you can use the mount command to see what mounted. You can run mkfs for each filesystem from the shell, but the quickest way to correct any corrupted filesystems may be to umount all of the system disk filesystems, exit the shell, and run the inst command admin mkfs. This will prompt you to rebuild each filesystem, and remount everything once it's complete. To do this, launch the shell, and immediately exit. The system will attempt to mount the remaining partitions, fail and launch the inst program. Sometimes you will need to run admin mkfs twice because of problems with unmounting filesystems. If all of the system disk partitions are mounted and correct, the system just loads the inst program. After inst loads, you should check and reset the system date if necessary: Inst> admin date Sat Jan 16 21:36:01 CST 1999 Inst> admin date mmddhhmm[cc]yy Page 320 Once you have checked the system date, you can launch a shell using the inst command admin sh and begin to recover the system disk filesystems. You should first unmount all of the disk filesystems except for /root: # mount /dev/miniroot on / type xfs (rw) /proc on /proc type proc (rw) /hw on /hw type hwgfs (rw) /dev/dsk/dks0dls0 on /root type xfs (rw) /hw on /root/hw type hwgfs (rw) /dev/dsk/dks0dls6 on /root/usr type xfs (rw) # umount /root/usr If the root filesystem was an XLV plex, you should force the plex to be re-created from the restored root filesystem by using the xlv_set_primary command: # xlv_set_primary /dev/dsk/dks0dls0 # rm -rf /dev/dsk/xlv /dev/rdsk/xlv # xlv_assemble -Pq -h muddy Replace /dev/dsk/dks0dls0 with the name of the root partition on the system disk, and muddy with the system's hostname. You then may want to compare the contents on /dev/dsk/xlv with the printed copy you made while the system was alive, and repair anything that is missing using commands from the script created by running the xlv_mgr script all command. If your system was dumped using xfsdump, recovering the root filesystem can be done with a command like the following, after you place the level-0 dump tape for root into the tape drive: # xfsrestore -r -f /dev/nrtape /root You should replace /dev/nrtape with the appropriate tape drive name, derived from the output of hinv, if /dev/nrtape is not the correct tape drive. Using the -r flag tells xfsrestore that you will potentially be restoring not only a level-0 xfsdump, but some higher incremental levels as well. If you used dump to back up your filesystems, you could recover your root filesystem with commands like this: # cd /root # restore rf /dev/nrtape If necessary, recover the /usr filesystem by mounting it on /root/usr, putting the correct dump tape into the tape drive, and using either xfsrestore or restore: # For xfsdump # mount /root/usr # xfsrestore -r -f /dev/nrtape /root/usr # For dump # mount /root/usr # cd /root/usr # restore rf /dev/nrtape Page 321 Use the same procedure for recovering any additional filesystems as required and for recovering any higher-level dumps for the system disk filesystems. Once you have recovered all of the filesystems on the system disk, you need to use dvhtool to copy sash and any other necessary files from the installation CD-ROM to the volume header to make the system disk bootable. Mount the CD-ROM if it's not already mounted, run dvhtool, and create the volume header files: # mkdir /CD-ROM # mount -t efs -o ro /dev/dsk/dksld3s7 /CD-ROM # cd /CD-ROM/stand # dvhtool /dev/rdsk/dks0d1vh Command? (read, vd, write, or quit): vd (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)? l Current contents: File name Length Block # sgilabel 512 2 (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)? c sashARCS ide (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)? c sashARCS sash (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)? 1 Current contents: File name Length Block # sgilabel 512 2 ide 316416 3 sash 316416 621 (d FILE, a UNIX_FILE FILE, c UNIX_FILE FILE, g FILE UNIX_FILE or l)? <Return> Command? (read, vd, write, or quit): write Command? (read, vd, write, or quit): quit Replace /dev/dsk/dks1d3s7 with the correct CD-ROM device name and /dev/rdsk/dks0d1vh with the name of the volume header for the system disk. You now should have a bootable system disk with everything restored. Exit from the shell and issue the inst the exit commands; do not use the quit command because inst will try to rebuild the kernel, and that can cause problems. The system then will prompt you for rebooting: Ready to restart the system. Restart? { (y)es, (n)o, (sh)ell, (h)elp) }: Restarting the system will bring it up into multiuser state, which you probably should not do until you check the rest of the filesystems. You can force the sys- Page 322 tem to halt by launching a shell from the prompt and using the uadmin command: # uadmin 2 0 [...]... Informix Backup & Recovery, discusses backup and recovery facilities and provides step-by-step recovery instructions • Chapter 15, Oracle Backup & Recovery, discusses Oracle's backup and recovery facilities and provides step-by-step recovery instructions • Chapter 16, Sybase Backup &Recovery, discusses Sybase's backup and recovery facilities and provides step-by-step recovery instructions Page 341 13 Backing... tapes and is not available with Sysback Page 339 V DATABASE BACKUP & RECOVERY Part V consists of the following four chapters which discuss database backup and detail the steps to back up and recover each of these widely used database: • Chapter 13, Backing Up Databases, provides an overview of database backup, concepts, terminology, and procedures • Chapter 14, Informix Backup & Recovery, discusses backup. .. To perform a backup of your system, run the following command: # smit sysback Then choose: Backup & Recovery Options Then choose: Backup Options The backup menu then presents the following options: Backup the System (Installation Image) Makes a bootable image of the entire system Includes the rootvg and any other VGs desired Page 332 Backup Volume Groups Makes a backup of a specific VG Backup Filesystems... databases, they are faster, larger, and more complex than ever before Companies are relying increasingly on bigger and bigger databases to store their information-information that, if lost, would be irreplaceable Customers have started to recognize the importance of safeguarding their data, and the demand for better backup and recovery utilities has followed Database companies and backup product companies have... tape backups of your system in case of disk failure It also can make an excellent companion to other backup programs that will handle your application and user data and provide things that mksysb cannot, such as incremental backups and remote restores mksysb is not a good solution for environments that are using raw logical volumes, have data outside rootvg, or need to be able to do incremental backups,... disaster recovery plan Among other things, Sysback allows: • Backups and restores of various types (full system dumps, volume groups, filesystems, logical volumes, or specific files and directories) • Backups and restores to a remote host configured as a Sysback server • Complete set of smit menus and fast paths to configure and perform backups Installing Sysback Sysback has the following prerequisites:... IBM was the first Unix vendor to deliver a true bare-metal recovery tool The following are the tools and products that are available to perform a bare-metal recovery of an AIX system: • The mksysb command makes a complete ''bootable" backup of the root volume group (rootvg) only • Sysback is a combination of scripts written by IBM that expands the functionality of mksysb Sysback allows backups of multiple... normalizing databases, designing user forms, and making sure the database performs adequately They know how to back up their database disk, maybe even to a standalone backup drive, but they don't have any experience with commercial backup software or large, automated libraries If the database is too big to back up to disk and they don't have a standalone backup drive to back up to, they have to work... more about database backup and recovery You then will be prepared to read and understand the vendor-specific database chapters in this book, as well as any of the appropriate sections of your favorite DBA book or manual This chapter assumes no prior knowledge, beginning with some of the very basic elements such as tables and rows, so that even the most junior person can understand everything However,... and recover; onbar is so much easier than rman And yet, Informix still doesn't have Oracle's market share I guess the Informix developer was right Can It Be Done? Think about database backups from a big-picture perspective, comparting them to filesystem backups There are a number of good backup utilities on the market now Why aren't there just as many for database backups? There is certainly a demand . Full system backup from / Thu Feb 25 17: 25: 47 PST 1999 Page 3 15 user: root group: sys IRIX muddy 6 .5 051 90003 IP22 IRIX 6 .5: 1274627333 built 4/29/98 at zebub:/xlv 55/ kudzu-apr12/root $ options: /sbin/cpio. vd (d FILE, a UNIX_ FILE FILE, c UNIX_ FILE FILE, g FILE UNIX_ FILE or l)? l Current contents: File name Length Block # sgilabel 51 2 2 (d FILE, a UNIX_ FILE FILE, c UNIX_ FILE FILE, g FILE UNIX_ FILE. a backup of your system, run the following command: # smit sysback Then choose: Backup & Recovery Options Then choose: Backup Options The backup menu then presents the following options: Backup