FS
Documentation

Backup3G/User Guide/Recovery

This page was last modified 10:37, 6 March 2008.

From Documentation

< Backup3G | User Guide(Difference between revisions)
Jump to: navigation, search
Revision as of 07:51, 20 April 2006
Moff (Talk | contribs)
(Restricting Recovery Destinations by Role)
← Previous diff
Current revision
Moff (Talk | contribs)
(Backup3G 5.1/User Guide/Recovery moved to Backup3G/User Guide/Recovery)
Line 1: Line 1:
 +{| align="right"
 +| __TOC__
 +|}
The real test of a backup system is its ability to quickly and easily restore files. This involves finding the files, ensuring that they are the correct versions, allowing flexible restoration—to any directory on any host, and logging all movements of files. The real test of a backup system is its ability to quickly and easily restore files. This involves finding the files, ensuring that they are the correct versions, allowing flexible restoration—to any directory on any host, and logging all movements of files.
Line 5: Line 8:
*multipart recovery *multipart recovery
*restricting which hosts and directories particular users can recover to. *restricting which hosts and directories particular users can recover to.
-__FORCETOC__+ 
<br> <br>
== Searching Backup Media == == Searching Backup Media ==

Current revision

Contents

The real test of a backup system is its ability to quickly and easily restore files. This involves finding the files, ensuring that they are the correct versions, allowing flexible restoration—to any directory on any host, and logging all movements of files.

This section introduces the key concepts in efficient recovery, concentrating on how to ensure that you can find the files that you want to recover:


Searching Backup Media

Backup3G has two methods of pattern matching for searching media contents and online indexes. By default it treats search expressions as shell file patterns, using the Bourne shell file name metacharacters. For more complex searches you can choose to use full regular expressions.


File patterns

Backup3G attempts to match the full search string against the list of file names in the index or media contents table. The following expressions have special meanings in the search string:

* match any number of characters, including null
? match any single character
[…] match any character in this set or range
[!…] match any character not in this set or range


Here are some examples of using file patterns to match base directories:

Table 3 - Searching using file patterns
Pattern Matches Description
/local/* /local/bin
/local/fs
All base directories under /local
/local/g* /local/gif
/local/gnats
Any base directories starting with g under /local
/l* /local
/lib
/lost+found
Base directories starting with l in the root directory
/l*/[ab]* /local/apps
/local/bin
/lib/acct
/lib/adb
Base directories starting with a or b that are subdirectories of the l directories in the previous example


Regular expressions

Backup3G uses similar rules to those of awk(1) to process regular expressions. In fact awk itself is used to handle many pattern searches, for example when you specify a partial file name to search online indexes.



Note
backup3G uses its own regexp library instead of the system’s regexp(3) library, as different versions of UNIX handle regular expressions in different ways.


Generally, any string matching regular expression (RE) will work the same in a backup3G pattern search as it would in an awk statement. For example:

. match any character
[s] match any character in this set or range
[^s] match any character not in this set or range
^ match the start of the string
$ match the end of the string
? match 0 or 1 occurrences of the preceding RE
match 1 or more occurrences of the preceding RE
¦ alternation – match either RE
(…) group the enclosed characters into a RE


Note that the \{…\} construct is not supported. See the egrep(1) man page for more details.

Table 4 lists some examples of regular expressions used to match base directories:

Table 4 — Searching using regular expressions
Pattern Matches Description
bin /bin
/bin/save
/usr/bin
/usr/local/bin
Base directories containing bin
bin$ /bin
/usr/bin
/usr/local/bin
Base directories ending in bin
^bin NO MATCH Base directories beginning bin. Nothing is selected, as all directories must start with /
^/bin /bin
/bin/save
Base directories beginning /bin
/usr.$ /usr1
/usr2
Base directories ending in /usr plus one extra character
Does not match /usr or /usr/bin
/usr.*bin /usr/bin
/usr/local/bin
/usr2/bin
Base directories beginning /usr and containing bin


The file name pattern can either be relative to the base directory or include the base directory name. For example, if the base directory is /usr, and you are searching for files under /usr/home/jdoe, enter /usr for Base directory/pattern. Any of the following patterns will work for Filename/pattern:

home/jdoe
home/jd
jdoe
relative to base directory
/usr.*j includes base directory


The base directory is optional. Its purpose is to limit the search to a subset of all the backups on the system. It is possible, though not recommended, to enter only a filename and leave Base directory/pattern blank. In this case every online index will be searched. This may be very slow.



Note
Some backup3G prompt screens, such as ‘Search media indexes’ (Recover > Search > Files), let you enter both a base directory and a file name pattern. backup3G first selects the backups whose base directory matches the pattern, finds which of these backups has an index, then searches the indexed backups for files matching the file name pattern.


If you’re not sure of a file name, a good rule-of-thumb is to start with a fairly broad pattern search, then use the Search key to find the file in the resulting list. Another useful rule is to use the start and end date fields to limit the search even further.

Again, remember that broad searches can be very slow to process, depending on the number of indexes to be searched. On some systems a search may fail if the number of indexes is very large.

See To Recover Using Search on page 110 for step by step instructions.


Multi-part Recovery

When you do a full recovery of files from a multi-part backup step, the recovery job scans all the parts. When you recover selected files, backup3G displays a list of all files in the base directory. This is a concatenation of the indexes of all the parts. backup3G determines which parts must be read to recover the files you have requested, and which parts can be skipped.

If you enter the names of the files to be recovered, the recovery job will still scan the index to work out which parts to read. If the backup is not indexed, all parts will be read.

Loading of new volumes is handled in the same way as for the backup. If the tape is in a stacker or jukebox it is loaded automatically, otherwise a ‘change media’ request is made to the operator via the Backup Monitor.


Multi-step recovery

Backup3G supports multi-step recovery. Selected steps from the multi-step backup can be recovered to the original location or to a new location.


Restricting Recovery Destinations by Role

You may wish to restrict which target directories particular users can recover to. The ability to recover files is controlled by the ‘Recover by Roles’ table and by two capabilities: recover and recoverALL.

Users with the recoverALL capability can recover files to any directory on any remote backup3G host. Users with the recover capability can recover files subject to restrictions.

The ‘Recovery by Roles’ table (backup3G configuration > Maintain tables) lists the recovery restrictions for various roles. This is used to restrict which directories and hosts particular classes of user can recover files to.

Figure 8 — Sample set of recovery restrictions

For example, in Figure 8, users with the Operator role can recover to any directory on host morticia, /tmp and /local/ops on host mama, and /tmp on any other host. Users with the Admin role can recover to /tmp, /var, /opt, /users, and /local on host mama, and /tmp, /users, and /local on any other host.

Backup3G is installed with these defaults:



Note
Restrictions are inherited. A user with both the Admin and the Operator role inherits the restrictions of both roles.