FAQ:How are backup levels defined and how does Amanda use them?

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)

Jump to: navigation, search

This article answers a FAQ (frequently asked question).


Backup levels

Different backup software define backup levels in different ways, often using the same terms in contradictory ways. Amanda’s definition of backup levels follows the traditional Unix/BSD/Linux dump utility backup levels of 0-9, with level 0 being a full backup, and each level n being a backup of changes since the last backup of level n-1 or lower. Explanations and examples can be found in your system’s man pages for dump (or, e.g., ufsdump in Solaris). This system, and Amanda’s configuration parameters, are flexible enough to emulate virtually any backup scheme a user may be familiar with from previous experience with another piece of backup software. However, there are advantages to be gained from becoming familiar with Amanda’s backup planning strategy and from letting Amanda do the planning.

For general reference, a new user may be wondering about how to do differential backups with Amanda. The typical definition of differential backup is the same as Amanda’s level 1 backup, and the reason a user may be interested in this is that it reduces the number of tapes required to recover a system. Their concern may arise from a definition of incremental backup that says changes since the last backup of any kind. With that definition, recovering a system would require every tape since the last full backup. Using Amanda’s standard backup planning strategy avoids that problem and typically gives the best result.

Because different backup software may have conflicting definitions, it is important to get a specific definition for reference in asking or answering questions. For example, Symantec’s (Veritas) Netbackup defines a “differential-incremental” as only the changes since the last backup of any kind, and a “cumulative-incremental” as the changes since the last full backup. EMC Retrospect calls their backup IncrementalPLUS (“using patented technology”). However, the most common definitions of backup levels are those used by Amanda (0-9) and the set of definitions for full/incremental/differential in which incremental is changes since the last backup of any kind and differential is the changes since the last full backup.

Amanda’s planning strategy

Amanda’s strategy is one of optimization. Amanda balances the amount of tape or disk space used by a given level of incremental against the number of tapes that will be required to recover a system. Amanda is also balancing the usage of resources (network bandwidth, tape space, backup time) across the dump cycle (typically 5 or 10 days) to smooth out demands and avoid excessive spikes.

Amanda’s default strategy has years of experience incorporated into it and works well in most situations. The guarantee is that you will get at least one full backup of each Disk List Entry (DLE) during each dump cycle. You will have at least an incremental of each DLE on every run, so you are covered for every DLE for every run within the dump cycle.

There are a number of parameters available for tuning Amanda’s strategy to specific environments. See bumping and amanda.conf(5) for more detail. However, it might be best to wait and see. Amanda may take a dump cycle or two to get the full backups distributed (first time around they will pile up at the beginning) and to get a sense of what it is dealing with. After that, you will find the the fulls distributed over the dump cycle and the load smoothed out.

What constitutes “changes”?

Some backup programs that have their own backup procedures have issues with various kinds of changes to the file system. For example, what happens when a user moves files from one directory to another? Or deletes files? And what does the backup procedure do to the file attributes?

Amanda uses native utilities for its backup procedures. This not only gives the user freedom to choose, but also assures the highest likelihood of correct behavior.

For example, testing with ufsdump/ufsrestore on Solaris 9 shows that the incremental backup captures the changes described above. Doing a ufsrestore of a full followed by an incremental correctly restores the directory structure and contents to account for moves and deletes. ufsdump also works off the raw device and does not affect atime.

Gnutar uses tar extensions to implement incremental backups (see http://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html), and captures metadata that allows it to restore a directory structure to the state it was in when the incremental backup was done. Gnutar will affect atime. Attempting to get around this using the --atime-preserve=replace option is not a good idea, because it affects ctime (by changing atime back).

Amanda works well with Gnutar or dump, and understands the options required to achieve the desired results. Much of this information is available from the man pages, and can be checked for whatever backup procedure is chosen.

Personal tools