Recovery Process Overview

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)
Revision as of 18:59, 12 April 2010 by Dustin (talk | contribs) (new text)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Amanda considers any activity that moves data out of Amanda's data-storage backend to be a recovery operation. This page describes the components that are required for such an operation and how they fit together. Note that an amvault(8) operation is simply a recovery "glued" (using the Transfer Architecture) to a taper operation.

Amanda does two kinds of recoveries. The first, implemented by amfetchdump(8) and amrecover(8) (well, really by amidxtaped), recovers entire dumpfiles, reassembling split parts along the way. The second, which we will call a "restore", is implemented by amrestore(8), and merely extracts data files from volumes without reassembling them. The advantage of restores is that they can be done without any catalog information, and often without an Amanda configuration present at all. We'll cover these separately, starting with the simpler restore operation.

Restores

You can see the canonical restore operation in server-src/amrestore.pl.

Since all devices must be created from changers, the first step is to create a changer to wrap the restore device. This will most likely be a chg-single instance, although the user might supply any valid changer name. Amrestore then loads the current slot in this changer; again, this will most likely open and set up the device specified by the user.

After this point, amrestore uses Device API functions to seek to the desired files, and uses a transfer to extract the data, filter it for decompression or decryption, and write it to disk or a file descriptor. The source element is an Amanda::Xfer::Source::Device or, for holding disks, Amanda::Xfer::Source::Holding. The destination is a simple Amanda::Xfer::Dest::Fd.

Recoveries

Recoveries are more complicated. The recovery applications have access to the Amanda configuration and catalog, and are asked to recover one or more complete dumpfiles. Each dumpfile is recovered with a single transfer, even if it comes from split parts spanning several volumes. Because of the added complexity of finding and reassembling split parts, we need configurable scanning and interactivity modules, too.

Make a Plan

Before opening any devices, the first task is to figure out where the required data is. The tool for the job is Amanda::Recovery::Planner. It allows several kinds of input: dumpspecs, holding file, or a filelist. The output is the same, though: a list of volumes and parts on those volumes.

Without vaulting, making a plan is pretty simple: just find the required data. However, with vaulted data present, there are generally several valid plans. At the moment, the planner selects the copy of a dumpfile written earliest. For the common case of vaulting data from short-term to long-term media, this makes sense: if the data is still in short-term media, use that; otherwise, use the long-term media. In the future, Amanda::Recovery::Planner will support user-selectable algorithms. Note that it is not possible to "mix" data from several distinct copies of a dumpfile (e.g., take the first three parts from secondary media and the remaining parts from tertiary media).

Hire a Clerk

There's a lot of device-shuffling and seeking to do, and it's made even more complicated by the need to support DirectTCP. All of this is coordinated by the Amanda::Recovery::Clerk. Its operation is pretty simple: feed it the plan for a dumpfile, and it gives you a transfer source, which it will manage for you during the transfer.

The clerk will need a number of resources to do its job:

Feedback

The clerk will optionally call methods on a feedback object to track the progress of the recovery.

Recovery Scan

The clerk uses a scan object (see Amanda::Recovery::Scan) to fetch volumes. This wraps a changer, adding lots of configuration options.

The scan takes a changer -- usually the configuration's default changer -- where it will begin looking for volumes. It also takes an interactive object (Amanda::Interactive) which it will use to prompt the user for volumes that it cannot access directly.

Overall, the scan is used to look really hard for a volume, including asking the user for any missing volumes. This allows Amanda to restore from more volumes than the system has drives without asking the user to manually load each volume into the same drive.

Recovery scanning was added late in the 3.1 release cycle, and will be considerably changed in 3.2.

Move the Data

The transfer source produced by the clerk is connected to whatever destination is appropriate -- a file, a socket, or even a DirectTCP element -- and started. Once the transfer is started, the clerk monitors its transfer and feeds it parts as directed by the plan, using the scan to load the required volumes.