Restoring files (old): Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 8: Line 8:
* Also, this section 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.
* Also, this section 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.


* All the examples below assume the backups were done using DUMP program. Backups done using GNUTAR can be restored in similar
* All the examples below assume the backups were done using DUMP program. Backups done using GNUTAR can be restored in similar manner. Instead of using restore command, gtar command will have to be used.
manner. Instead of using restore command, gtar command will have to be used.


==Examples==
==Examples==
Line 60: Line 59:




===Example 2: Client machine fails, system critical disk.===
===Example 2: Client machine fails, system critical disk===


Example: / fails on Barney.
Example: / fails on Barney.
Line 67: Line 66:
* Go through all steps in Example 1.
* Go through all steps in Example 1.


===Example 3: Server machine fails, non-system critical, non-AMANDA disk.===
===Example 3: Server machine fails, non-system critical, non-AMANDA disk===


* Proceed with steps described in Example 1.  
* Proceed with steps described in Example 1.  
Line 73: Line 72:
* However, the rsh process need not be used. Use amrestore to replace the lost data directly.
* However, the rsh process need not be used. Use amrestore to replace the lost data directly.


===Example 4: Server machine fails, system critical, non-AMANDA disk.
===Example 4: Server machine fails, system critical, non-AMANDA disk===


Example: / on Aaron
Example: / on Aaron


      First of all, boot off the CD, and reinstall the system critical partition, restoring it to vendor supplied state.
* Boot off the CD, and reinstall the system critical partition, restoring it to vendor supplied state.


      Then, follow steps in Scenario 3.
* Follow steps in Example 3.
  5.


      Server machine fails, non-system critical, AMANDA disk, with db.
===Example 5: Server machine fails, non-system critical, AMANDA disk, with db===


      Example: /opt on Aaron
Example: /etc 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.
* If the disk that contains the AMANDA database is bad, then you need to rebuild the database.  


      Note that AMANDA does not mail the exported database automatically; you may add this to the crontab entry that runs amanda.
* Use the text file that is mailed using the '[[amadmin]] <config> export' command, and import via the 'amadmin <config> import' command.


      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.
* Follow the steps outlined in Example 4.
  6.


      Server machine fails, non-system critical, AMANDA disk, with binaries.
  * Note that Amanda does not mail the exported database automatically; Create a crontab entry to do 'amadmin <config> export'


      Example: /usr/local on Aaron
  * It is a good idea to print out the text files as well and store the last 2 dumpcycles information.


      This is where things get hairy. If the disk with the amanda binaries on it is toast, you have three options.
===Example 6: Server machine fails, non-system critical, AMANDA disk, with binaries===
        1.


            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).
Example: /usr/local on Aaron
        2.


            recompile AMANDA, making sure not to overwrite your db files.
If the disk with the amanda binaries is bad, there are three options.
        3.


            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.
# Reinstall the Amanda binaries from another tape or RPMs, on which you have conveniently backed up the binaries within the last couple of weeks (not using Amanda).
              1.
# Recompile Amanda, making sure not to overwrite your db files.
# Use dd to read Amanda formatted tapes. Amanda stores dump in client format and can be restored using client tools.
::1. Find out the device name used by Amanda, by looking in amanda.conf. Example: /dev/rmt/0cn. If amanda.conf is not available, this must be a non-rewinding tape device. (the trailing `n' stands for non-rewinding tape device).
::2. Look at a copy of the output of 'amadmin <config> export', and find out which tapes /usr/local was backed up on.
::3. Grab the tapes that /opt was backed up on, and put the level 0 into the tape drive. cd to /usr/local.
::4. Skip the first record, which is just the tape header, by using the appropriate tape command.
mt -f /dev/rmt/0cn fsf 1
::5. Look for /usr/local on this tape.
dd if=/dev/rmt/0cn bs=32k skip=1 | gzip -d | /usr/sbin/restore -ivf -
This command provides interactive restore of this record, including partition, host, and level the backup was. The gzip -d portion of the pipe can be omitted if there was no compression.
::6. If /usr/local could not be found, quit restore, 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.


                  Find out the device name used by AMANDA, by looking in amanda.conf. Turns out to be /dev/rmt/0cn for this system.
::* Another option is to create a quick tape index in case information about which partition /usr/local was on is not available.


                  If amanda.conf isn't at hand: this must be a non-rewinding tape device specifier (which I believe the trailing `n' stands for).
#!/bin/sh
              2.
TAPEDEV=/dev/nrtape
 
while mt -f $TAPEDEV fsf 1 ; do
                  Look over the copy of the output of 'amadmin <config> export', and find out which tapes /usr/local was backed up on.
              3.
 
                  Grab the tapes that /opt was backed up on, and stick the level 0 into the drive. cd to /usr/local.
              4.
 
                  Skip the first record, which is just the tape header, by using the appropriate tape command.
 
mt -f /dev/rmt/0cn fsf 1
 
              5.
 
                  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.
              6.
 
                  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 <[email protected]>)
 
#!/bin/sh
TAPEDEV=/dev/nrtape
while mt -f $TAPEDEV fsf 1 ; do
   dd if=$TAPEDEV bs=32k count=1 | head -1
   dd if=$TAPEDEV bs=32k count=1 | head -1
   sleep 1
   sleep 1
done
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


              7.
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


                  Restore the AMANDA binaries (what else do you need??), and then bail out of ufsrestore. You can use amrestore, as in Scenario 3.
::7. Restore the Amanda binaries and then exit restore. Use amrestore command as in Example 3.

Revision as of 16:24, 25 November 2005

This section describes how to restore files backed up with Amanda either with or without Amanada tools. The section has presented as multiple examples. Read the whole section and use the example that is most applicable to your situation

Assumptions

  • All the examples below discuss restoration of a complete disk, that is, replacing a bad disk with a new one, or created a new filesystem on top of old one. Changing the restore arguments (not amrestore), individual files can be restored.
  • Also, this section 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.
  • All the examples below assume the backups were done using DUMP program. Backups done using GNUTAR can be restored in similar manner. Instead of using restore command, gtar command will have to be used.

Examples

The server machine is called Aaron, the client machine is called Barney. Backup is being restored to Barney

Example 1: Client machine fails, non-system critical

Example: /home fails on Barney.

  • 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

Above information shows that two tapes are needed 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 Barney 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 step 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. 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.


Example 2: Client machine fails, system critical disk

Example: / fails on Barney.

  • Boot off the CD, and reinstall the system critical partition, restoring it to vendor supplied state.
  • Go through all steps in Example 1.

Example 3: Server machine fails, non-system critical, non-AMANDA disk

  • Proceed with steps described in Example 1.
  • However, the rsh process need not be used. Use amrestore to replace the lost data directly.

Example 4: Server machine fails, system critical, non-AMANDA disk

Example: / on Aaron

  • Boot off the CD, and reinstall the system critical partition, restoring it to vendor supplied state.
  • Follow steps in Example 3.

Example 5: Server machine fails, non-system critical, AMANDA disk, with db

Example: /etc on Aaron

  • If the disk that contains the AMANDA database is bad, then you need to rebuild the database.
  • Use the text file that is mailed using the 'amadmin <config> export' command, and import via the 'amadmin <config> import' command.
  • Follow the steps outlined in Example 4.
 * Note that Amanda does not mail the exported database automatically; Create a crontab entry to do 'amadmin <config> export'

 * It is a good idea to print out the text files as well and store the last 2 dumpcycles information.

Example 6: Server machine fails, non-system critical, AMANDA disk, with binaries

Example: /usr/local on Aaron

If the disk with the amanda binaries is bad, there are three options.

  1. Reinstall the Amanda binaries from another tape or RPMs, on which you have conveniently backed up the binaries within the last couple of weeks (not using Amanda).
  2. Recompile Amanda, making sure not to overwrite your db files.
  3. Use dd to read Amanda formatted tapes. Amanda stores dump in client format and can be restored using client tools.
1. Find out the device name used by Amanda, by looking in amanda.conf. Example: /dev/rmt/0cn. If amanda.conf is not available, this must be a non-rewinding tape device. (the trailing `n' stands for non-rewinding tape device).
2. Look at a copy of the output of 'amadmin <config> export', and find out which tapes /usr/local was backed up on.
3. Grab the tapes that /opt was backed up on, and put the level 0 into the tape drive. cd to /usr/local.
4. Skip the first record, which is just the tape header, by using the appropriate tape command.
mt -f /dev/rmt/0cn fsf 1
5. Look for /usr/local on this tape.
dd if=/dev/rmt/0cn bs=32k skip=1 | gzip -d | /usr/sbin/restore -ivf -

This command provides interactive restore of this record, including partition, host, and level the backup was. The gzip -d portion of the pipe can be omitted if there was no compression.

6. If /usr/local could not be found, quit restore, 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 option is to create a quick tape index in case information about which partition /usr/local was on is not available.
#!/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
7. Restore the Amanda binaries and then exit restore. Use amrestore command as in Example 3.
Retrieved from ‘http://wiki.zmanda.com/index.php?title=Restoring_files_(old)&oldid=1626’