Next: Katalog Verwaltung Up: Bacula User's Guide Previous: Bacula Console Contents Index
Below, we will discuss restoring files with the Console restore command, which is the recommended way of doing restoring files. It is not possible to restore files by automatically starting a job as you do with Backup, Verify, ... jobs. However, in addition to the console restore command, there is a standalone program named bextract, which also permits restoring files. For more information on this program, please see the Bacula Utility Programs chapter of this manual. We don't particularly recommend the bextract program because it lacks many of the features of the normal Bacula restore, such as the ability to restore Win32 files to Unix systems, and the ability to restore access control lists (ACL). As a consequence, we recommend, wherever possible to use Bacula itself for restores as described below.
You may also want to look at the bls program in the same chapter, which allows you to list the contents of your Volumes. Finally, if you have an old Volume that is no longer in the catalog, you can restore the catalog entries using the program named bscan, documented in the same Bacula Utility Programs chapter.
In general, to restore a file or a set of files, you must run a restore job. That is a job with Type = Restore. As a consequence, you will need a predefined restore job in your bacula-dir.conf (Director's config) file. The exact parameters (Client, FileSet, ...) that you define are not important as you can either modify them manually before running the job or if you use the restore command, explained below, Bacula will automatically set them for you. In fact, you can no longer simply run a restore job. You must use the restore command.
Since Bacula is a network backup program, you must be aware that when you restore files, it is up to you to ensure that you or Bacula have selected the correct Client and the correct hard disk location for restoring those files. Bacula will quite willingly backup client A, and restore it by sending the files to a different directory on client B. Normally, you will want to avoid this, but assuming the operating systems are not too different in their file structures, this should work perfectly well, if so desired. By default, Bacula will restore data to the same Client that was backed up, and those data will be restored not to the original places but to /tmp/bacula-restores. You may modify any of these defaults when the restore command prompts you to run the job by selecting the mod option.
Since Bacula maintains a catalog of your files and on which Volumes (disk or tape), they are stored, it can do most of the bookkeeping work, allowing you simply to specify what kind of restore you want (current, before a particular date), and what files to restore. Bacula will then do the rest.
This is accomplished using the restore command in the Console. First you select the kind of restore you want, then the JobIds are selected, the File records for those Jobs are placed in an internal Bacula directory tree, and the restore enters a file selection mode that allows you to interactively walk up and down the file tree selecting individual files to be restored. This mode is somewhat similar to the standard Unix restore program's interactive file selection mode.
If a Job's file records have been pruned from the catalog, the restore command will be unable to find any files to restore. See below for more details on this.
Within the Console program, after entering the restore command, you are presented with the following selection prompt:
First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item: (1-12):
There are a lot of options, and as a point of reference, most people will want to slect item 5 (the most recent backup for a client). The details of the above options are:
There are two important things to note. First, this automatic selection will never select a job that failed (terminated with an error status). If you have such a job and want to recover one or more files from it, you will need to explicitly enter the JobId in item 3, then choose the files to restore.
If some of the Jobs that are needed to do the restore have had their File records pruned, the restore will be incomplete. Bacula currently does not correctly detect this condition. You can however, check for this by looking carefully at the list of Jobs that Bacula selects and prints. If you find Jobs with the JobFiles column set to zero, when files should have been backed up, then you should expect problems.
If all the File records have been pruned, Bacula will realize that there are no file records in any of the JobIds chosen and will inform you. It will then propose doing a full restore (non-selective) of those JobIds. This is possible because Bacula still knows where the beginning of the Job data is on the Volumes, even if it does not know where particular files are located or what their names are.
As an example, suppose that we select item 5 (restore to most recent state). If you have not specified a client=xxx on the command line, it it will then ask for the desired Client, which on my system, will print all the Clients found in the database as follows:
Defined clients:
1: Rufus
2: Matou
3: Polymatou
4: Minimatou
5: Minou
6: MatouVerify
7: PmatouVerify
8: RufusVerify
9: Watchdog
Select Client (File daemon) resource (1-9):
You will probably have far fewer Clients than this example, and if you have only one Client, it will be automatically selected. In this case, I enter Rufus to select the Client. Then Bacula needs to know what FileSet is to be restored, so it prompts with:
The defined FileSet resources are:
1: Full Set
2: Other Files
Select FileSet resource (1-2):
If you have only one FileSet defined for the Client, it will be selected automatically. I choose item 1, which is my full backup. Normally, you will only have a single FileSet for each Job, and if your machines are similar (all Linux) you may only have one FileSet for all your Clients.
At this point, Bacula has all the information it needs to find the most recent set of backups. It will then query the database, which may take a bit of time, and it will come up with something like the following. Note, some of the columns are truncated here for presentation:
+-------+------+----------+-------------+-------------+------+-------+---------- --+ | JobId | Levl | JobFiles | StartTime | VolumeName | File | SesId | VolSesTime | +-------+------+----------+-------------+-------------+------+-------+---------- --+ | 1,792 | F | 128,374 | 08-03 01:58 | DLT-19Jul02 | 67 | 18 | 1028042998 | | 1,792 | F | 128,374 | 08-03 01:58 | DLT-04Aug02 | 0 | 18 | 1028042998 | | 1,797 | I | 254 | 08-04 13:53 | DLT-04Aug02 | 5 | 23 | 1028042998 | | 1,798 | I | 15 | 08-05 01:05 | DLT-04Aug02 | 6 | 24 | 1028042998 | +-------+------+----------+-------------+-------------+------+-------+---------- --+ You have selected the following JobId: 1792,1792,1797 Building directory tree for JobId 1792 ... Building directory tree for JobId 1797 ... Building directory tree for JobId 1798 ... cwd is: / $
Depending on the number of JobFiles for each JobId, the Building directory tree ..." can take a bit of time. If you notice ath all the JobFiles are zero, your Files have probably been pruned and you will not be able to select any individual files -- it will be restore everything or nothing.
In our example, Bacula found four Jobs that comprise the most recent backup of the specified Client and FileSet. Two of the Jobs have the same JobId because that Job wrote on two different Volumes. The third Job was an incremental backup to the previous Full backup, and it only saved 254 Files compared to 128,374 for the Full backup. The fourth Job was also an incremental backup that saved 15 files.
Next Bacula entered those Jobs into the directory tree, with no files marked to be restored as a default, tells you how many files are in the tree, and tells you that the current working directory (cwd) is /. Finally, Bacula prompts with the dollar sign ($) to indicate that you may enter commands to move around the directory tree and to select files.
If you want all the files to automatically be marked when the directory tree is built, you could have entered the command restore all, or at the $ prompt, you can simply enter mark *.
Instead of choosing item 5 on the first menu (Select the most recent backup for a client), if we had chosen item 3 (Enter list of JobIds to select) and we had entered the JobIds 1792,1797,1798 we would have arrived at the same point.
One point to note, if you are manually entering JobIds, is that you must enter them in the order they were run (generally in increasing JobId order). If you enter them out of order and the same file was saved in two or more of the Jobs, you may end up with an old version of that file (i.e. not the most recent).
Directly entering the JobIds can also permit you to recover data from a Job that wrote files to tape but that terminated with an error status.
While in file selection mode, you can enter help or a question mark (?) to produce a summary of the available commands:
Command Description ======= =========== cd change current directory count count marked files in and below the cd dir long list current directory, wildcards allowed done leave file selection mode estimate estimate restore size exit same as done command find find files, wildcards allowed help print help ls list current directory, wildcards allowed lsmark list the marked files in and below the cd mark mark dir/file to be restored recursively in dirs markdir mark directory name to be restored (no files) pwd print current working directory unmark unmark dir/file to be restored recursively in dir unmarkdir unmark directory name only no recursion quit quit and do not do restore ? print help
As a default no files have been selected for restore (unless you added all to the command line. If you want to restore everything, at this point, you should enter mark *, and then done and Bacula will write the bootstrap records to a file and request your approval to start a restore job.
If you do not enter the above mentioned mark * command, you will start with an empty slate. Now you can simply start looking at the tree and mark particular files or directories you want restored. It is easy to make a mistake in specifying a file to mark or unmark, and Bacula's error handling is not perfect, so please check your work by using the ls or dir commands to see what files are actually selected. Any selected file has its name preceded by an asterisk.
To check what is marked or not marked, enter the count command, which displays:
128401 total files. 128401 marked to be restored.
Each of the above commands will be described in more detail in the next section. We continue with the above example, having accepted to restore all files as Bacula set by default. On entering the done command, Bacula prints:
Bootstrap records written to /home/kern/bacula/working/restore.bsr The job will require the following Volume(s) Storage(s) SD Device(s) =========================================================================== DLT-19Jul02 Tape DLT8000 DLT-04Aug02 Tape DLT8000 128401 files selected to restore. Run Restore job JobName: kernsrestore Bootstrap: /home/kern/bacula/working/restore.bsr Where: /tmp/bacula-restores Replace: always FileSet: Other Files Client: Rufus Storage: Tape When: 2006-12-11 18:20:33 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no):
Please examine each of the items very carefully to make sure that they are correct. In particular, look at Where, which tells you where in the directory structure the files will be restored, and Client, which tells you which client will receive the files. Note that by default the Client which will receive the files is the Client that was backed up. These items will not always be completed with the correct values depending on which of the restore options you chose. You can change any of these default items by entering mod and responding to the prompts.
The above assumes that you have defined a Restore Job resource in your Director's configuration file. Normally, you will only need one Restore Job resource definition because by its nature, restoring is a manual operation, and using the Console interface, you will be able to modify the Restore Job to do what you want.
An example Restore Job resource definition is given below.
Returning to the above example, you should verify that the Client name is correct before running the Job. However, you may want to modify some of the parameters of the restore job. For example, in addition to checking the Client it is wise to check that the Storage device chosen by Bacula is indeed correct. Although the FileSet is shown, it will be ignored in restore. The restore will choose the files to be restored either by reading the Bootstrap file, or if not specified, it will restore all files associated with the specified backup JobId (i.e. the JobId of the Job that originally backed up the files).
Finally before running the job, please note that the default location for restoring files is not their original locations, but rather the directory /tmp/bacula-restores. You can change this default by modifying your bacula-dir.conf file, or you can modify it using the mod option. If you want to restore the files to their original location, you must have Where set to nothing or to the root, i.e. /.
If you now enter yes, Bacula will run the restore Job. The Storage daemon will first request Volume DLT-19Jul02 and after the appropriate files have been restored from that volume, it will request Volume DLT-04Aug02.
If you have a small number of files to restore, and you know the filenames, you can either put the list of filenames in a file to be read by Bacula, or you can enter the names one at a time. The filenames must include the full path and filename. No wild cards are used.
To enter the files, after the restore, you select item number 7 from the prompt list:
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item: (1-12):
which then prompts you for the client name:
Defined Clients:
1: Timmy
2: Tibs
3: Rufus
Select the Client (1-3): 3
Of course, your client list will be different, and if you have only one client, it will be automatically selected. And finally, Bacula requests you to enter a filename:
Enter filename:
At this point, you can enter the full path and filename
Enter filename: /home/kern/bacula/k/Makefile.in Enter filename:
as you can see, it took the filename. If Bacula cannot find a copy of the file, it prints the following:
Enter filename: junk filename No database record found for: junk filename Enter filename:
If you want Bacula to read the filenames from a file, you simply precede the filename with a less-than symbol (<). When you have entered all the filenames, you enter a blank line, and Bacula will write the bootstrap file, tells you what tapes will be used, and proposes a Restore job to be run:
Enter filename: Automatically selected Storage: DDS-4 Bootstrap records written to /home/kern/bacula/working/restore.bsr The restore job will require the following Volumes: test1 1 file selected to restore. Run Restore job JobName: kernsrestore Bootstrap: /home/kern/bacula/working/restore.bsr Where: /tmp/bacula-restores Replace: always FileSet: Other Files Client: Rufus Storage: DDS-4 When: 2003-09-11 10:20:53 Priority: 10 OK to run? (yes/mod/no):
It is possible to automate the selection by file by putting your list of files in say /tmp/file-list, then using the following command:
restore client=Rufus file=</tmp/file-list
If in modifying the parameters for the Run Restore job, you find that Bacula asks you to enter a Job number, this is because you have not yet specified either a Job number or a Bootstrap file. Simply entering zero will allow you to continue and to select another option to be modified.
If all the above sounds complicated, you will probably agree that it really isn't after trying it a few times. It is possible to do everything that was shown above, with the exception of selecting the FileSet, by using command line arguments with a single command by entering:
restore client=Rufus select current all done yes
The client=Rufus specification will automatically select Rufus as the client, the current tells Bacula that you want to restore the system to the most current state possible, and the yes suppresses the final yes/mod/no prompt and simply runs the restore.
The full list of possible command line arguments are:
The where= option is simple, but not very powerful. With file relocation, Bacula can restore a file to the same directory, but with a different name, or in an other directory without recreating the full path.
You can also do filename and path manipulations, implemented in Bacula 2.1.8 or later, such as adding a suffix to all your files, renaming files or directories, etc. Theses options will overwrite where= option.
For example, many users use OS snapshot features so that file /home/eric/mbox will be backed up from the directory /.snap/home/eric/mbox, which can complicate restores. If you use where=/tmp, the file will be restored to /tmp/.snap/home/eric/mbox and you will have to move the file to /home/eric/mbox.bkp by hand. In this case, you could use strip_prefix=/.snap and add_suffix=.bkp options and Bacula will restore the file to its original location -- that is /home/eric/mbox.
To use this feature, there are command line options as described in the restore section of this manual; you can modify your restore job before running it; or you can add options to your restore job in as described in bacula-dir.conf.
Parameters to modify:
1: Level
2: Storage
..
10: File Relocation
..
Select parameter to modify (1-12):
This will replace your current Where value
1: Strip prefix
2: Add prefix
3: Add file suffix
4: Enter a regexp
5: Test filename manipulation
6: Use this ?
Select parameter to modify (1-6):
The format is very close to that used by sed or Perl (s/replace this/by that/) operator. A valid regexwhere expression has three fields :
Each field is delimited by a separator specified by the user as the first character of the expression. The separator can be one of the following:
<separator-keyword> = / ! ; % : , ~ # = &
You can use several expressions separated by a commas.
| Orignal filename | Computed filename | RegexWhere | Comments |
| c:/system.ini | c:/system.old.ini | /.ini$/.old.ini/ | use $ as end of filename |
| /prod/u01/pdata/ | /rect/u01/rdata | /prod/rect/,/pdata/rdata/ | using two regexp |
| /prod/u01/pdata/ | /rect/u01/rdata | !/prod/!/rect/!,/pdata/rdata/ | using ! instead of / |
| C:/WINNT | d:/WINNT | /c:/d:/i | using case-insensitive pattern matching |
Depending how you do the restore, you may or may not get the directory entries back to their original state. Here are a few of the problems you can encounter, and for same machine restores, how to avoid them.
If you are restoring on WinNT/2K/XP systems, Bacula will restore the files with the original ownerships and permissions as would be expected. This is also true if you are restoring those files to an alternate directory (using the Where option in restore). However, if the alternate directory does not already exist, the Bacula File daemon (Client) will try to create it. In some cases, it may not create the directories, and if it does since the File daemon runs under the SYSTEM account, the directory will be created with SYSTEM ownership and permissions. In this case, you may have problems accessing the newly restored files.
To avoid this problem, you should create any alternate directory before doing the restore. Bacula will not change the ownership and permissions of the directory if it is already created as long as it is not one of the directories being restored (i.e. written to tape).
The default restore location is /tmp/bacula-restores/ and if you are restoring from drive E:, the default will be /tmp/bacula-restores/e/, so you should ensure that this directory exists before doing the restore, or use the mod option to select a different where directory that does exist.
Some users have experienced problems restoring files that participate in the Active Directory. They also report that changing the userid under which Bacula (bacula-fd.exe) runs, from SYSTEM to a Domain Admin userid, resolves the problem.
Restoring files is generally much slower than backing them up for several reasons. The first is that during a backup the tape is normally already positioned and Bacula only needs to write. On the other hand, because restoring files is done so rarely, Bacula keeps only the start file and block on the tape for the whole job rather than on a file by file basis which would use quite a lot of space in the catalog.
Bacula will forward space to the correct file mark on the tape for the Job, then forward space to the correct block, and finally sequentially read each record until it gets to the correct one(s) for the file or files you want to restore. Once the desired files are restored, Bacula will stop reading the tape.
Finally, instead of just reading a file for backup, during the restore, Bacula must create the file, and the operating system must allocate disk space for the file as Bacula is restoring it.
For all the above reasons the restore process is generally much slower than backing up (sometimes it takes three times as long).
The most frequent problems users have restoring files are error messages such as:
04-Jan 00:33 z217-sd: RestoreFiles.2005-01-04_00.31.04 Error: block.c:868 Volume data error at 20:0! Short block of 512 bytes on device /dev/tape discarded.
or
04-Jan 00:33 z217-sd: RestoreFiles.2005-01-04_00.31.04 Error: block.c:264 Volume data error at 20:0! Wanted ID: "BB02", got ".". Buffer discarded.
Both these kinds of messages indicate that you were probably running your tape drive in fixed block mode rather than variable block mode. Fixed block mode will work with any program that reads tapes sequentially such as tar, but Bacula repositions the tape on a block basis when restoring files because this will speed up the restore by orders of magnitude when only a few files are being restored. There are several ways that you can attempt to recover from this unfortunate situation.
Try the following things, each separately, and reset your Device resource to what it is now after each individual test:
There are a number of reasons why there may be restore errors or warning messages. Some of the more common ones are:
If the restored size is smaller, then you should be concerned about a possible tape error and check the Bacula output as well as your system logs.
Job {
Name = "RestoreFiles"
Type = Restore
Client = Any-client
FileSet = "Any-FileSet"
Storage = Any-storage
Where = /tmp/bacula-restores
Messages = Standard
Pool = Default
}
If Where is not specified, the default location for restoring files will be their original locations.
After you have selected the Jobs to be restored and Bacula has created the in-memory directory tree, you will enter file selection mode as indicated by the dollar sign ($) prompt. While in this mode, you may use the commands listed above. The basic idea is to move up and down the in memory directory structure with the cd command much as you normally do on the system. Once you are in a directory, you may select the files that you want restored. As a default no files are marked to be restored. If you wish to start with all files, simply enter: cd / and mark *. Otherwise proceed to select the files you wish to restore by marking them with the mark command. The available commands are:
Note, on Windows systems, the various drives (c:, d:, ...) are treated like a directory within the file tree while in the file selection mode. As a consequence, you must do a cd c: or possibly in some cases a cd C: (note upper case) to get down to the first directory.
After executing the mark command, it will print a brief summary:
No files marked.
If no files were marked, or:
nn files marked.
if some files are marked.
This and the following sections will try to present a few of the kinds of problems that can come up making restoring more difficult. We will try to provide a few ideas how to get out of these problem situations. In addition to what is presented here, there is more specific information on restoring a Client and your Server in the Disaster Recovery Using Bacula chapter of this manual.
Assuming the above does not resolve the problem, you will need to restore or rebuild your catalog. Note, if it is a matter of some inconsistencies in the Bacula tables rather than a broken database, then running dbcheck might help, but you will need to ensure that your database indexes are properly setup. Please see the Database Performance Issues sections of this manual for more details.
./drop_bacula_tables ./make_bacula_tablesAfter re-initializing the database, you should be able to run Bacula. If you now try to use the restore command, it will not work because the database will be empty. However, you can manually run a restore job and specify your bootstrap file. You do so by entering the bf run command in the console and selecting the restore job. If you are using the default bacula-dir.conf, this Job will be named RestoreFiles. Most likely it will prompt you with something such as:
Run Restore job JobName: RestoreFiles Bootstrap: /home/kern/bacula/working/restore.bsr Where: /tmp/bacula-restores Replace: always FileSet: Full Set Client: rufus-fd Storage: File When: 2005-07-10 17:33:40 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no):
A number of the items will be different in your case. What you want to do is: to use the mod option to change the Bootstrap to point to your saved bootstrap file; and to make sure all the other items such as Client, Storage, Catalog, and Where are correct. The FileSet is not used when you specify a bootstrap file. Once you have set all the correct values, run the Job and it will restore the backup of your database, which is most likely an ASCII dump.
You will then need to follow the instructions for your database type to recreate the database from the ASCII backup file. See the Catalog Maintenance chapter of this manual for examples of the command needed to restore a database from an ASCII dump (they are shown in the Compacting Your XXX Database sections).
Also, please note that after you restore your database from an ASCII backup, you do NOT want to do a make_bacula_tables command, or you will probably erase your newly restored database tables.
22-Apr 10:22 HeadMan: Start Backup JobId 7510, Job=CatalogBackup.2005-04-22_01.10.0 22-Apr 10:23 HeadMan: Bacula 1.37.14 (21Apr05): 22-Apr-2005 10:23:06 JobId: 7510 Job: CatalogBackup.2005-04-22_01.10.00 Backup Level: Full Client: Polymatou FileSet: "CatalogFile" 2003-04-10 01:24:01 Pool: "Default" Storage: "DLTDrive" Start time: 22-Apr-2005 10:21:00 End time: 22-Apr-2005 10:23:06 FD Files Written: 1 SD Files Written: 1 FD Bytes Written: 210,739,395 SD Bytes Written: 210,739,521 Rate: 1672.5 KB/s Software Compression: None Volume name(s): DLT-22Apr05 Volume Session Id: 11 Volume Session Time: 1114075126 Last Volume Bytes: 1,428,240,465 Non-fatal FD errors: 0 SD Errors: 0 FD termination status: OK SD termination status: OK Termination: Backup OK
From the above information, you can manually create a bootstrap file, and then follow the instructions given above for restoring your database. A reconstructed bootstrap file for the above backup Job would look like the following:
Volume="DLT-22Apr05" VolSessionId=11 VolSessionTime=1114075126 FileIndex=1-1
Where we have inserted the Volume name, Volume Session Id, and Volume Session Time that correspond to the values in the job report. We've also used a FileIndex of one, which will always be the case providing that there was only one file backed up in the job.
The disadvantage of this bootstrap file compared to what is created when you ask for one to be written, is that there is no File and Block specified, so the restore code must search all data in the Volume to find the requested file. A fully specified bootstrap file would have the File and Blocks specified as follows:
Volume="DLT-22Apr05" VolSessionId=11 VolSessionTime=1114075126 VolFile=118-118 VolBlock=0-4053 FileIndex=1-1
Once you have restored the ASCII dump of the database, you will then to follow the instructions for your database type to recreate the database from the ASCII backup file. See the Catalog Maintenance chapter of this manual for examples of the command needed to restore a database from an ASCII dump (they are shown in the Compacting Your XXX Database sections).
Also, please note that after you restore your database from an ASCII backup, you do NOT want to do a make_bacula_tables command, or you will probably erase your newly restored database tables.
There is a specific example of how to use bls below.
1 Job 0 Filesand restores nothing.
llist jobid=120
JobId: 120
Job: save.2005-12-05_18.27.33
Job.Name: save
PurgedFiles: 0
Type: B
Level: F
Job.ClientId: 1
Client.Name: Rufus
JobStatus: T
SchedTime: 2005-12-05 18:27:32
StartTime: 2005-12-05 18:27:35
EndTime: 2005-12-05 18:27:37
JobTDate: 1133803657
VolSessionId: 1
VolSessionTime: 1133803624
JobFiles: 236
JobErrors: 0
JobMissingFiles: 0
Job.PoolId: 4
Pool.Name: Full
Job.FileSetId: 1
FileSet.FileSet: BackupSet
Then you can find the Volume(s) used by doing:
sql select VolumeName from JobMedia,Media where JobId=1 and JobMedia.MediaId=Media.MediaId;
Finally, you can create a bootstrap file as described in the previous problem above using this information.
If you are using Bacula version 1.38.0 or greater, when you select item 3 from the menu and enter the JobId, it will ask you if you would like to restore all the files in the job, and it will collect the above information and write the bootstrap file for you.
./bls -j -V DLT-22Apr05 /dev/nst0Might produce the following output:
bls: butil.c:258 Using device: "/dev/nst0" for reading. 21-Jul 18:34 bls: Ready to read from volume "DLT-22Apr05" on device "DLTDrive" (/dev/nst0). Volume Record: File:blk=0:0 SessId=11 SessTime=1114075126 JobId=0 DataLen=164 ... Begin Job Session Record: File:blk=118:0 SessId=11 SessTime=1114075126 JobId=7510 Job=CatalogBackup.2005-04-22_01.10.0 Date=22-Apr-2005 10:21:00 Level=F Type=B End Job Session Record: File:blk=118:4053 SessId=11 SessTime=1114075126 JobId=7510 Date=22-Apr-2005 10:23:06 Level=F Type=B Files=1 Bytes=210,739,395 Errors=0 Status=T ... 21-Jul 18:34 bls: End of Volume at file 201 on device "DLTDrive" (/dev/nst0), Volume "DLT-22Apr05" 21-Jul 18:34 bls: End of all volumes.Of course, there will be many more records printed, but we have indicated the essential lines of output. From the information on the Begin Job and End Job Session Records, you can reconstruct a bootstrap file such as the one shown above.
If you would like to know the JobId where a file was saved, select restore menu option 2.
You can also use the query command to find information such as:
*query
Available queries:
1: List up to 20 places where a File is saved regardless of the
directory
2: List where the most recent copies of a file are saved
3: List last 20 Full Backups for a Client
4: List all backups for a Client after a specified time
5: List all backups for a Client
6: List Volume Attributes for a selected Volume
7: List Volumes used by selected JobId
8: List Volumes to Restore All Files
9: List Pool Attributes for a selected Pool
10: List total files/bytes by Job
11: List total files/bytes by Volume
12: List Files for a selected JobId
13: List Jobs stored on a selected MediaId
14: List Jobs stored for a given Volume name
15: List Volumes Bacula thinks are in changer
16: List Volumes likely to need replacement from age or errors
Choose a query (1-16):
There are basically three steps to take:
When the above is complete, you can begin bscanning your Volumes. Please see the bscan section of the Volume Utility Tools of this chapter for more details.
This document briefly describes the GUI programs that work with Bacula. The GUI programs that are currently available are:
For more information on bimagemgr, please see below.
For more information on gnome-console, please consult the Console Chapter of this manual.
For more information, please see Configuring the Monitor Program chapter this manual.
bimagemgr is a utility for those who backup to disk volumes in order to commit them to CDR disk, rather than tapes. It is a web based interface written in Perl and is used to monitor when a volume file needs to be burned to disk. It requires:
SQLite databases and DVD burning are not supported by bimagemgr at this time, but both are planned for future releases.
Please see the README file in the bimagemgr directory of the distribution for instructions.
Calling the program in your web browser, e.g. http://localhost/cgi-bin/bimagemgr.pl will produce a display as shown below in Figure 1. The program will query the bacula database and display all volume files with the date last written and the date last burned to disk. If a volume needs to be burned (last written is newer than last burn date) a "Burn" button will be displayed in the rightmost column.
Place a blank CDR disk in your recorder and click the "Burn" button. This will cause a pop up window as shown in Figure 2 to display the burn progress.
When the burn finishes the pop up window will display the results of cdrecord as shown in Figure 3. Close the pop up window and refresh the main window. The last burn date will be updated and the "Burn" button for that volume will disappear. Should you have a failed burn you can reset the last burn date of that volume by clicking its "Reset" link.
In the bottom row of the main display window are two more buttons labeled "Burn Catalog" and "Blank CDRW". "Burn Catalog" will place a copy of your bacula catalog on a disk. If you use CDRW disks rather than CDR then "Blank CDRW" allows you to erase the disk before re-burning it. Regularly committing your backup volume files and your catalog to disk with bimagemgr ensures that you can rebuild easily in the event of some disaster on the bacula server itself.
bimagemgr ist ein Hilfsmittel für diejenigen, die Ihre Backups auf Festplatten-Volumes speichern und diese Volumes auf CDR brennen wollen. Es hat eine Web-basierte Bedienoberfläche und ist in Perl programmiert. Es wird benutzt, um zu kontrollieren, wann die Notwendigkeit besteht, eine Volume-Datei auf eine CD zu brennen. Es benötigt:
DVD-Brenner werden von bimagemgr zur Zeit nicht unterstützt, das ist aber für zukünftige Versionen geplant.
Installation aus dem tar.gz: 1. Prüfen und anpassen des Makefile, um es auf Ihre Computer-Konfiguration abzustimmen. 2. Editieren der Datei config.pm ,um sie auf Ihre Konfiguration abzustimmen. 3. Führen Sie 'make install' als root aus. 4. Passen Sie in Ihrer httpd.conf das Timeout an. Der Web-Server darf die Verbindung nicht schliessen, solange der Brennvorgang nicht abgeschlossen ist. Der benötigte Wert, den Sie als Timeout konfigurieren müssen, hängt von der Geschwindigkeit Ihres CD-Brenners ab, oder ob Sie über das Netzwerk brennen. In den meisten Fällen reichen 1000 Sekunden als Timeout. Den httpd neu starten. 5. Stellen Sie sicher, dass das Kommando cdrecord als "setuid root" installiert ist.
Installation eines rpm-Paketes: 1. Installieren Sie das rpm-Paket für Ihre Plattform. 2. Editieren Sie die Datei /cgi-bin/config.pm, um sie an Ihre Konfiguration abzupassen. 3. Passen Sie in Ihrer httpd.conf das Timeout an. Der Web-Server darf die Verbindung nicht schliessen, solange der Brennvorgang nicht abgeschlossen ist. Der benötigte Wert, den Sie als Timeout konfigurieren müssen, hängt von der Geschwindigkeit Ihres CD-Brenners ab, oder ob Sie über das Netzwerk brennen. In den meisten Fällen reichen 1000 Sekunden als Timeout. Den httpd neu starten. 4. Stellen Sie sicher, dass das Kommando cdrecord als "setuid root" installiert ist.
Zugriff auf die Volume-Dateien: Die Volume-Dateien haben standardmäßig die Zugriffsrechte 640 gesetzt und können nur von Benutzer root gelesen werden. Die empfohlene Methode ist die folgende (das funktioniert nur, wenn bacula und bimagemgr auf demselben Computer laufen wie der Web-Server):
Für Bacula-Versionen 1.34 oder 1.36 installiert aus dem tar.gz - 1. Erstellen Sie eine neu Gruppe namens bacula und fügen Sie den Benutzer apache dieser Gruppe hinzu (bei RedHat und Mandrake, bei SuSE ist es der Benutzer wwwrun, bei debian www-data) 2. Ändern Sie den Eigentümer aller Volume-Dateien auf root.bacula. 3. Passen Sie das Script /etc/init.d/bacula an und setzen Sie SD_USER=root und SD_GROUP=bacula. Starten Sie Bacula neu.
Anmerkung: Schritt Nr. 3 sollte auch in /etc/init.d/bacula-sd gemacht werden, aber die Dateien aus Bacula-Versionen vor 1.36 unterstützen dies nicht. In diesem Fall kann es nötig sein den Computer neu zu starten, um '/etc/bacula/bacula restart' auszuführen.
Für Bacula-Versionen 1.38 installiert aus dem tar.gz 1. Ihr configure-Aufruf sollte dies beinhalten: --with-dir-user=bacula --with-dir-group=bacula --with-sd-user=bacula --with-sd-group=disk --with-fd-user=root --with-fd-group=bacula 2. Fügen Sie den Benutzer apache der Gruppe bacula hinzu (bei RedHat und Mandrake, bei SuSE ist es der Benutzer wwwrun, bei debian www-data) 3. Kontrollieren/Ändern Sie den Eigentümer aller Volume-Dateien auf root.bacula
Für Bacul-Versionen 1.36 oder 1.38 mit rpm installiert - 1. Fügen Sie den Benutzer apache der Gruppe bacula hinzu (bei RedHat und Mandrake, bei SuSE ist es der Benutzer wwwrun, bei debian www-data) 2. Kontrollieren/Ändern Sie den Eigentümer aller Volume-Dateien auf root.bacula
Wenn bimagemgr mit einem rpm-Paket Version größer 1.38.9 installiert wird, wird der Web-Server-Benutzer automatisch der Gruppe bacula hinzugefügt. Stellen Sie sicher, dass Sie die Datei config.pm nach der Installation anpassen.
bimagemgr kann jetzt alle Volume-Dateien lesen, aber sie sind nicht durch alle Benutzer lesbar.
Wenn Sie bimagemgr auf einen anderen Computer installieren (nicht empfohlen), müssen Sie die Zugriffsrechte aller Volume-Dateien auf 644 ändern, damit Sie über nfs oder andere Mittel darauf zugreifen können. Beachten Sie, dass bei diesem Vorgehen die Volume-Dateien für alle Benutzer lesbar sind und Sie den Schutz der Dateien anders sicherstellen.
Rufen Sie das Programm mit Ihrem Web-Browser auf, z.B. http://localhost/cgi-bin/bimagemgr.pl, dann sollten Sie eine Darstellung ähnlich der unten im Bild 1 abgebildeten sehen. Das Programm wird die Bacula-Datenbank abfragen und alle Volume-Dateien mit dem Datum des letzten Schreibvorgangs und dem Zeitpunkt darstellen, wo das Volume zum letzten Mal auf CD gebrannt wurde. Wenn ein Volume auf CD gebrannt werden muss (letzter Schreibvorgang ist neuer als der letzte Brennvorgang), wird ein "Brennen"-Knopf in der rechten Spalte angezeigt.
Legen Sie eine leere CD in Ihren CD-Brenner und klicken Sie auf den "Brennen"-Knopf. Dann öffnet sich ein PopUp-Fenster, wie im Bild 2, das den Brennvorgang anzeigt.
Wenn der Brennvorgang abgeschloßen ist, zeigt das PopUp-Fenster die Ausgaben von cdrecord an (siehe Bild 3). Schließen Sie das PopUp-Fenster und laden Sie die Hauptseite neu. Das Datum des letzten Brennvorgangs wird aktualisiert und der "Brennen"-Knopf verschwindet. Sollte das Brennen fehlgeschlagen sein, können Sie das Datum des letzten Brennvorgangs zurücksetzen, indem Sie auf den Link "Reset" des Volumes klicken.
In der untersten Zeile des Hauptfensters sind zwei weitere Knöpfe, mit "Burn Catalog" und "Blank CDRW" beschriftet. "Burn Catalog" schreibt eine Kopie Ihrer Katalog-Datenbank auf eine CD. Falls Sie CDRW-Medien benutzen, können Sie mit "Blank CDRW" ein Medium löschen bevor Sie es wiederverwenden. Regelmässiges speichern Ihrer Volume-Dateien und Ihrer Katalog-Datenbank mit bimagemgr auf CD's stellt sicher, dass Sie jederzeit im Falle eines Datenverlustes auf Ihrem Bacula-Server diesen einfach wiederherstellen können.
Kern Sibbald 2008-01-31
