--- /dev/null
+
+ Chapter 6. Restore
+Prev Part I. Installation Next
+
+-------------------------------------------------------------------------------
+
+Chapter 6. Restore
+
+
+Daniel Moore
+
+Original text<dmoore@jeffco.k12.co.us>
+
+Alexandre Oliva
+
+Substantial rewriting
+AMANDA Core Team
+<oliva@dcc.unicamp.br>>
+
+Murf
+
+Corrections and additions<jam@philabs.research.philips.com>
+
+Ralf Fassel
+
+Corrections and additions<ralf@atg.venture.de>
+
+Stefan G. Weichinger
+
+XML-conversion;Updates
+AMANDA Core Team
+<sgw@amanda.org>
+
+Note
+
+Refer to http://www.amanda.org/docs/restore.html for the current version of
+this document.
+This document describes how to restore files backed up with AMANDA either with
+or without AMANDA tools.
+All these cases assume you're trying to restore a complete disk, that is,
+you've replaced the lost disk with a new one, or created a new filesystem on
+it. Tweaking with the arguments to restore (not amrestore), you will be able to
+restore individual files.
+Also, this text does not cover amrecover, a program that provides a text user
+interface similar to interactive restore (restore -i), but it allows you to
+select individual files to recover and automatically determines the tapes where
+they were stored. The backups must be performed with the `index' option enabled
+for this to work.
+I considered the following cases.
+The server machine (machine Aaron) runs solaris, the client machine (machine
+Barney) runs sunos.
+
+ 1. Client machine fails, non-system critical.
+ Example: /home fails on Barney.
+ First, use amadmin to find the tapes most recently used to backup the
+ partition.
+
+ amadmin <config> info Barney '/home$'
+
+ Current info for Barney /home:
+ Stats: dump rates (kps), Full: 41.1, 33.1, 38.8
+ Incremental: 9.5, 2.1, 24.7
+ compressed size, Full: 63.1%, 54.0%, 52.9%
+ Incremental: 43.7%, 15.5%, 47.8%
+ Dumps: lev datestmp tape file origK compK secs
+ 0 19971223 Barney01 16 329947 208032 5060
+ 1 19980108 Barney16 8 1977 864 91
+ 2 19971222 Barney06 7 1874 672 83
+ 3 19970926 Barney03 11 12273 3040 211
+
+ This tells us that we will need two tapes to do a full restore (Barney01,
+ Barney16). Note that, even if Barney06 and Barney03 are listed, they are
+ actually older than the full backup, so they should not be used to restore
+ any data.
+ Log into Barney. Cd to the /home directory. Insert the tape with the level
+ 0 dump on it into the tape drive of Aaron.
+ Become super-user in the client host and run (replace <amanda> with the
+ username under which amanda runs):
+
+ rsh -n -l <amanda> Aaron amrestore -p /dev/rmt/0cn Barney '/home\$' |
+ restore -ivbf 2 -
+
+ This requires client root to have login access to <amanda>@Aaron, with a
+ .rhosts entry (.amandahosts won't do). If you use ssh, you may be able to
+ type a password in order to be authenticated. Another alternative is to
+ start the operation in the server, and rsh to the client. You should be
+ the amanda user or root in the tape server and run:
+
+ amrestore -p /dev/rmt/0cn Barney '/home$' |
+ rsh Barney -l root /usr/etc/restore -ivbf 2 -
+
+ If you don't want to use rsh at all, you may run:
+
+ amrestore /dev/rmt/0cn Barney '/home$'
+
+ This should create a file whose name contains the hostname, directory
+ name, dump level and dump date of the backup. Now you have to move this
+ file to the client somehow: you may use NFS, rcp, ftp, floppy disks :-),
+ whatever. Suppose you rename that file to `home.0'. Then, on the client,
+ you should become root and run:
+
+ restore -ivbf 2 home.0
+
+ Repeat one of these steps, incrementing the level of the dump, until there
+ are no more available backups.
+ 2. Client machine fails, system critical disk.
+ Example: / fails on Barney.
+ First of all, boot off the CD, and reinstall the system critical
+ partition, restoring it to vendor supplied state. Then, go through all of
+ Scenario 1.
+ 3. Server machine fails, non-system critical, non-AMANDA disk.
+ Proceed just as described in Scenario 1. However, you won't have to go
+ through the rsh process, because you can just use amrestore to replace the
+ lost data directly.
+ 4. Server machine fails, system critical, non-AMANDA disk.
+ Example: / on Aaron
+ First of all, boot off the CD, and reinstall the system critical
+ partition, restoring it to vendor supplied state.
+ Then, follow steps in Scenario 3.
+ 5. Server machine fails, non-system critical, AMANDA disk, with db.
+ Example: /opt on Aaron
+ If the disk that contains the AMANDA database is toast, then you need to
+ rebuild the database. The easiest way to do it is to take the text file
+ that you had mailed to you via the 'amadmin export' command, and import
+ via the 'amadmin import' command. Then you should be able to follow the
+ steps outlined in Scenario 4.
+ Note that AMANDA does not mail the exported database automatically; you
+ may add this to the crontab entry that runs amanda.
+ Maybe it's a good idea to print out the text files as well and store the
+ last 2 dumpcycles worth of paper (the disc text files might have got
+ toasted as well). From the paper you still are able to reconstruct where
+ your discs are.
+ 6. Server machine fails, non-system critical, AMANDA disk, with binaries.
+ Example: /usr/local on Aaron
+ This is where things get hairy. If the disk with the amanda binaries on it
+ is toast, you have three options.
+
+ i. reinstall the AMANDA binaries from another tape, on which you have
+ conveniently backed up the binaries within the last couple of weeks
+ (not using AMANDA).
+ ii. recompile AMANDA, making sure not to overwrite your db files.
+ iii. use dd to read AMANDA formatted tapes. This is the option I am going
+ to explore most fully, because this seems the most likely to occur.
+
+ a. Find out the device name used by AMANDA, by looking in
+ amanda.conf. Turns out to be /dev/rmt/0cn for this system.
+ If amanda.conf isn't at hand: this must be a non-rewinding tape
+ device specifier (which I believe the trailing `n' stands for).
+ b. Look over the copy of the output of 'amadmin <config> export',
+ and find out which tapes /usr/local was backed up on.
+ c. Grab the tapes that /opt was backed up on, and stick the level 0
+ into the drive. cd to /usr/local.
+ d. Skip the first record, which is just the tape header, by using
+ the appropriate tape command.
+
+ mt -f /dev/rmt/0cn fsf 1
+
+ e. Now you want to start looking for /usr/local on this tape.
+
+ dd if=/dev/rmt/0cn bs=32k skip=1 | gzip -d | /usr/sbin/
+ ufsrestore -ivf -
+
+ This command gives us an interactive restore of this record,
+ including telling us what partition, what host, and what level
+ the backup was. The gzip -d portion of the pipe can be omitted
+ if there was no compression.
+ f. If you don't find /usr/local on the first try, quit ufsrestore,
+ and move forward one record.
+
+ mt -f /dev/rmt/0cn fsf 1
+
+ and try the dd/restore command shown above. Do this until you
+ find /opt on the disk.
+ Another possibility: quick and dirty tape index in case you
+ don't know which partition /usr/local was on: (from
+ <ralf@atg.venture.de>)
+
+ #!/bin/sh
+ TAPEDEV=/dev/nrtape
+ while mt -f $TAPEDEV fsf 1 ; do
+ dd if=$TAPEDEV bs=32k count=1 | head -1
+ sleep 1
+ done
+
+ Example output:
+
+ AMANDA: FILE 19971220 uri /root-sun4 lev 1 comp .gz program
+ DUMP
+ AMANDA: FILE 19971220 uri /misc lev 1 comp .gz program DUMP
+ AMANDA: FILE 19971220 uri / lev 1 comp .gz program DUMP
+
+ g. Restore the AMANDA binaries (what else do you need??), and then
+ bail out of ufsrestore. You can use amrestore, as in Scenario 3.
+
+
+
+-------------------------------------------------------------------------------
+
+Prev Up Next
+Chapter 5. Backup PC hosts using Samba Home Part II. About Tapes and Changers
+
projects / debian / amanda / blobdiff