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 {\bf restore} command, explained below, Bacula will
-automatically set them for you.
+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
\begin{itemize}
\item Item 1 will list the last 20 jobs run. If you find the Job you want,
- you can then select item 3 and enter its JobId(s).
+ you can then select item 3 and enter its JobId(s).
+
\item Item 2 will list all the Jobs where a specified file is saved. If you
- find the Job you want, you can then select item 3 and enter the JobId.
+ find the Job you want, you can then select item 3 and enter the JobId.
+
\item Item 3 allows you the enter a list of comma separated JobIds whose
files will be put into the directory tree. You may then select which
files from those JobIds to restore.
+
\item Item 4 allows you to enter any arbitrary SQL command. This is probably
the most primitive way of finding the desired JobIds, but at the same time,
the most flexible. Once you have found the JobId(s), you can select item 3
- and enter them.
+ and enter them.
+
\item Item 5 will automatically select the most recent Full backup and all
subsequent incremental and differential backups for a specified Client.
These are the Jobs and Files which, if reloaded, will restore your
automatically select the most recent Full backup and all subsequent
incremental and differential backups that started before the specified date
and time.
+
\item Item 7 allows you to specify one or more filenames (complete path
required) to be restored. Each filename is entered one at a time or if you
prefix a filename with the less-than symbol (\lt{}) Bacula will read that
file and assume it is a list of filenames to be restored. The filename entry
- mode is terminated by entering a blank line.
+ mode is terminated by entering a blank line.
+
\item Item 8 allows you to specify a date and time before entering the
- filenames. See Item 7 above for more details.
+ filenames. See Item 7 above for more details.
+
\item Item 9 allows you find the JobIds of the most recent backup for
a client. This is much like option 5 (it uses the same code), but
those JobIds are retained internally as if you had entered them
manually. You may then select item 11 (see below) to restore one
or more directories.
+
\item Item 10 is the same as item 9, except that it allows you to enter
a before date (as with item 6). These JobIds will then be retained
internally.
+
+\index[general]{Restore Directories}
\item Item 11 allows you to enter a list of JobIds from which you can
select directories to be restored. The list of JobIds can have been
previously created by using either item 9 or 10 on the menu. You
be restored, but if the directory contains subdirectories, nothing
will be restored in the subdirectory unless you explicitly enter its
name.
+
\item Item 12 allows you to cancel the restore command.
\end{itemize}
\normalsize
Depending on the number of {\bf JobFiles} for each JobId, the {\bf Building
-directory tree ...``} can take a bit of time. If you notice ath all the
+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.
\begin{itemize}
\item You backed up on one machine and are restoring to another that is
either a different OS or doesn't have the same users/groups defined. Bacula
- does the best it can in these situations.
-\item You are restoring into a directory that is already created and has file
- creation restrictions. Bacula tries to reset everything but without walking
- up the full chain of directories and modifying them all during the restore,
- which Bacula does and will not do, getting permissions back correctly in
-this
- situation depends to a large extent on your OS.
-\item You selected one or more files in a directory, but did not select the
- directory entry to be restored. In that case, if the directory is not on
-disk
- Bacula simply creates the directory with some default attributes which may
- not be the same as the original. If you do not select a directory and all
-its
- contents to be restored, you can still select items within the directory to
- be restored by individually marking those files, but in that case, you
-should
- individually use the ''markdir`` command to select all higher level
- directory entries (one at a time) to be restored if you want the directory
- entries properly restored.
+ does the best it can in these situations. Note, Bacula has saved the
+ user/groups in numeric form, which means on a different machine, they
+ may map to different user/group names.
+\item You are restoring into a directory that is already created and has
+ file creation restrictions. Bacula tries to reset everything but
+ without walking up the full chain of directories and modifying them all
+ during the restore, which Bacula does and will not do, getting
+ permissions back correctly in this situation depends to a large extent
+ on your OS.
+\item You are doing a recursive restore of a directory tree. In this case
+ Bacula will restore a file before restoring the file's parent directory
+ entry. In the process of restoring the file Bacula will create the
+ parent directory with open permissions and ownership of the file being
+ restored. Then when Bacula tries to restore the parent directory Bacula
+ sees that it already exists (Similar to the previous situation). If you
+ had set the Restore job's "Replace" property to "never" then Bacula will
+ not change the directory's permissions and ownerships to match what it
+ backed up, you should also notice that the actual number of files
+ restored is less then the expected number. If you had set the Restore
+ job's "Replace" property to "always" then Bacula will change the
+ Directory's ownership and permissions to match what it backed up, also
+ the actual number of files restored should be equal to the expected
+ number.
+\item You selected one or more files in a directory, but did not select the
+ directory entry to be restored. In that case, if the directory is not
+ on disk Bacula simply creates the directory with some default attributes
+ which may not be the same as the original. If you do not select a
+ directory and all its contents to be restored, you can still select
+ items within the directory to be restored by individually marking those
+ files, but in that case, you should individually use the "markdir"
+ command to select all higher level directory entries (one at a time) to
+ be restored if you want the directory entries properly restored.
\end{itemize}
\label{Windows}
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).
+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 {\bf /tmp/bacula-restores/} and if you are
restoring from drive {\bf E:}, the default will be
\index[general]{Restoring Files Can Be Slow }
\addcontentsline{toc}{subsection}{Restoring Files Can Be Slow}
-Restoring files is generally {\bf much} slower than backing it up for several
+Restoring files is generally {\bf 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 he start file and block on the
+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 versions 1.31a and older would seek to the first file on the first
-tape, then sequentially search the tape for the specified files. If you were
-doing a full restore, this is OK, but if you want to restore one or two files,
-the process could be quite long.
-
-This deficiency has been corrected in version 1.32. The consequence is that
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. For restoring a small number of files, version 1.32 and greater are
-hundreds of times faster than previous versions.
+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
what it is now after each individual test:
\begin{enumerate}
-\item Set ''Block Positioning = no`` in your Device resource and try the
+\item Set "Block Positioning = no" in your Device resource and try the
restore. This is a new directive and untested.
-\item Set ''Minimum Block Size = 512`` and ''Maximum Block Size = 512`` and
- try the restore. Again send me the full job report output. If you are able
-to
- determine the block size your drive was previously using, you should try
- that size if 512 does not work.
+\item Set "Minimum Block Size = 512" and "Maximum Block Size = 512" and
+ try the restore. If you are able to determine the block size your drive
+ was previously using, you should try that size if 512 does not work.
\item Try editing the restore.bsr file at the Run xxx yes/mod/no prompt
- before starting the restore job and remove all the VolBlock statements.
-These
- are what causes Bacula to reposition the tape, and where problems occur if
- you have a fixed block size set for your drive. The VolFile commands also
- cause repositioning, but this will work regardless of the block size.
+ before starting the restore job and remove all the VolBlock statements.
+ These are what causes Bacula to reposition the tape, and where problems
+ occur if you have a fixed block size set for your drive. The VolFile
+ commands also cause repositioning, but this will work regardless of the
+ block size.
\item Use bextract to extract the files you want -- it reads the Volume
- sequentially if you use the include list feature, or if you use a .bsr file,
- but remove all the VolBlock statements after the .bsr file is created (at
-the
- Run yes/mod/no) prompt but before you start the restore.
+ sequentially if you use the include list feature, or if you use a .bsr
+ file, but remove all the VolBlock statements after the .bsr file is
+ created (at the Run yes/mod/no) prompt but before you start the restore.
\end{enumerate}
+\subsection*{Restore Errors}
+\index[general]{Errors!Restore}
+\index[general]{Restore Errors}
+\addcontentsline{toc}{subsection}{Restore Errors}
+
+There are a number of reasons why there may be restore errors or
+warning messages. Some of the more common ones are:
+
+\begin{description}
+
+\item [file count mismatch]
+ This can occur for the following reasons:
+ \begin{itemize}
+ \item You requested Bacula not to overwrite existing or newer
+ files.
+ \item A Bacula miscount of files/directories. This is an
+ on-going problem due to the complications of directories,
+ soft/hard link, and such. Simply check that all the files you
+ wanted were actually restored.
+ \end{itemize}
+\item [file size error]
+ When Bacula restores files, it checks that the size of the
+ restored file is the same as the file status data it saved
+ when starting the backup of the file. If the sizes do not
+ agree, Bacula will print an error message. This size mismatch
+ most often occurs because the file was being written as Bacula
+ backed up the file. In this case, the size that Bacula
+ restored will be greater than the status size. This often
+ happens with log files.
+
+ 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.
+\end{description}
+
+
+
\subsection*{Example Restore Job Resource}
\index[general]{Example Restore Job Resource }
\index[general]{Resource!Example Restore Job }
\item [cd]
The {\bf cd} command changes the current directory to the argument
-specified.
+ specified.
It operates much like the Unix {\bf cd} command. Wildcard specifications are
not permitted.
Note, on Windows systems, the various drives (c:, d:, ...) are treated like
-a
+ a
directory within the file tree while in the file selection mode. As a
consequence, you must do a {\bf cd c:} or possibly in some cases a {\bf cd
C:} (note upper case) to get down to the first directory.
\index[dir]{dir }
The {\bf dir} command is similar to the {\bf ls} command, except that it
prints it in long format (all details). This command can be a bit slower
-than
+ than
the {\bf ls} command because it must access the catalog database for the
detailed information for each file.
\index[dir]{estimate }
The {\bf estimate} command prints a summary of the total files in the tree,
how many are marked to be restored, and an estimate of the number of bytes
-to
+ to
be restored. This can be useful if you are short on disk space on the
-machine
+ machine
where the files will be restored.
\item [find]
\item [mark]
\index[dir]{mark }
- The {\bf mark} command allows you to mark files to be restored. It takes a
+ The {\bf mark} command allows you to mark files to be restored. It takes a
single argument which is the filename or directory name in the current
directory to be marked for extraction. The argument may be a wildcard
specification, in which case all files that match in the current directory
This command is the same as the {\bf help} command.
\end{description}
+\label{database_restore}
\subsection*{Restoring When Things Go Wrong}
\index[general]{Restoring When Things Go Wrong }
+\index[general]{Restoring Your Database}
+\index[general]{Database!Restoring}
\addcontentsline{toc}{subsection}{Restoring When Things Go Wrong}
This and the following sections will try to present a few of the kinds of
problems that can come up making restoring more difficult. I'll 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 \ilink{Client}{restore_client} and your
+\ilink{Server}{restore_server} in the \ilink{Disaster Recovery Using
+Bacula}{_ChapterRescue} chapter of this manual.
\begin{description}
-\item [Problem]
- Your catalog has been damaged and Bacula either doesn't work or prints
- errors.
+\item[Problem]
+ My database is broken.
\item[Solution]
For SQLite, use the vacuum command to try to fix the database. For either
MySQL or PostgreSQL, see the vendor's documentation. They have specific tools
- that check and repair databases.
+ that check and repair databases, see the \ilink{database
+ repair}{DatabaseRepair} sections of this manual for links to vendor
+ information.
Assuming the above does not resolve the problem, you will need to restore
- or rebuild your catalog.
+ or rebuild your catalog. Note, if it is a matter of some
+ inconsistencies in the Bacula tables rather than a broken database, then
+ running \ilink{dbcheck}{dbcheck} might help, but you will need to ensure
+ that your database indexes are properly setup. Please see
+ the \ilink{Database Performance Issues}{DatabasePerformance} sections
+ of this manual for more details.
+
\item[Problem]
How do I restore my catalog?
-\item[Solution]
+\item[Solution with a Catalog backup]
If you have backed up your database nightly (as you should) and you
have made a bootstrap file, you can immediately load back your
database (or the ASCII SQL output). Make a copy of your current
OK to run? (yes/mod/no):
\end{verbatim}
\normalsize
- 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. You will then
- need to follow the instructions for your database type to
- recreate the database from the ASCII backup file.
+ 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 \ilink {Catalog Maintenance}{_ChapterStart12} 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 {\bf make_bacula_tables} command, or
+ you will probably erase your newly restored database tables.
-\item[Solution]
- If you did save your database but did not make a bootstrap file, then
- recovering the database
- is more difficult. You will probably need to use bextract to extract the
- backup copy.
- First you should locate the listing of the job report from the last catalog
- backup. It has important information that will allow you to quickly find
- your database file. For example, in the job report for the CatalogBackup
- shown below, the critical items are the Volume name(s), the Volume Session Id
- and the Volume Session Time. If you know those, you can easily restore your
+\item[Solution with a Job listing]
+ If you did save your database but did not make a bootstrap file, then
+ recovering the database is more difficult. You will probably need to
+ use bextract to extract the backup copy. First you should locate the
+ listing of the job report from the last catalog backup. It has
+ important information that will allow you to quickly find your database
+ file. For example, in the job report for the CatalogBackup shown below,
+ the critical items are the Volume name(s), the Volume Session Id and the
+ Volume Session Time. If you know those, you can easily restore your
Catalog.
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
+
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:
+
\footnotesize
\begin{verbatim}
Volume="DLT-22Apr05"
FileIndex=1-1
\end{verbatim}
\normalsize
- 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.
+
+ 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:
+ 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:
+
\footnotesize
\begin{verbatim}
Volume="DLT-22Apr05"
FileIndex=1-1
\end{verbatim}
\normalsize
+
+ 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 \ilink {Catalog Maintenance}{_ChapterStart12} 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 {\bf make_bacula_tables} command, or
+ you will probably erase your newly restored database tables.
+
+\item [Solution withou a Job Listing]
+ If you do not have a job listing, then it is a bit more difficult.
+ Either you use the \ilink{bscan}{bscan} program to scan the contents
+ of your tape into a database, which can be very time consuming
+ depending on the size of the tape, or you can use the \ilink{bls}{bls}
+ program to list everything on the tape, and reconstruct a bootstrap
+ file from the bls listing for the file or files you want following
+ the instructions given above.
+
+ There is a specific example of how to use {\bf bls} below.
+
+\item [Problem]
+ I try to restore the last known good full backup by specifying
+ item 3 on the restore menu then the JobId to restore. Bacula
+ then reports:
+
+\footnotesize
+\begin{verbatim}
+ 1 Job 0 Files
+\end{verbatim}
+\normalsize
+ and restores nothing.
+\item[Solution]
+ Most likely the File records were pruned from the database either due
+ to the File Retention period expiring or by explicitly purging the
+ Job. By using the "llist jobid=nn" command, you can obtain all the
+ important information about the job:
+\footnotesize
+\begin{verbatim}
+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
+\end{verbatim}
+\normalsize
+
+ Then you can find the Volume(s) used by doing:
+\footnotesize
+\begin{verbatim}
+sql
+select VolumeName from JobMedia,Media where JobId=1 and JobMedia.MediaId=Media.MediaId;
+\end{verbatim}
+\normalsize
+ 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.
+
\item [Problem]
You don't have a bootstrap file, and you don't have the Job report for
the backup of your database, but you did backup the database, and you
know the Volume to which it was backed up.
\item [Solution]
- Use {\bf bls} to indicate where it is on the tape. For example:
+ Either bscan the tape, or use {\bf bls} to indicate where it is on the
+ tape. For example:
\footnotesize
\begin{verbatim}
\footnotesize
\begin{verbatim}
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).
+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
+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
+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 Volume at file 201 on device "DLTDrive" (/dev/nst0),
+Volume "DLT-22Apr05"
21-Jul 18:34 bls: End of all volumes.
\end{verbatim}
\normalsize
Job Session Records, you can reconstruct a bootstrap file such as the one
shown above.
+\item[Problem]
+ How can I find where a file is stored.
+\item[Solution]
+ Normally, it is not necessary, you just use the {\bf restore} command to
+ restore the most recently saved version (menu option 5), or a version
+ saved before a given date (menu option 8). If you know the JobId of the
+ job in which it was saved, you can use menu option 3 to enter that JobId.
+
+ If you would like to know the JobId where a file was saved, select
+ restore menu option 2.
+
+ You can also use the {\bf query} command to find information such as:
+\footnotesize
+\begin{verbatim}
+*query
+Available queries:
+ 1: List Job totals:
+ 2: List up to 20 places where a File is saved regardless of the directory:
+ 3: List where the most recent copies of a file are saved:
+ 4: List last 20 Full Backups for a Client:
+ 5: List all backups for a Client after a specified time
+ 6: List all backups for a Client
+ 7: List Volume Attributes for a selected Volume:
+ 8: List Volumes used by selected JobId:
+ 9: List Volumes to Restore All Files:
+ 10: List Pool Attributes for a selected Pool:
+ 11: List total files/bytes by Job:
+ 12: List total files/bytes by Volume:
+ 13: List Files for a selected JobId:
+ 14: List Jobs stored in a selected MediaId:
+ 15: List Jobs stored for a given Volume name:
+Choose a query (1-15):
+\end{verbatim}
+\normalsize
+
+
\end{description}
projects / bacula / docs / blobdiff