
#include "bacula_template.inc" title="FAQ"

<h1>Bacula Frequently Asked Questions</h1>
 See <a href="bugs.html">the bugs section</a> of this document for
 a list of known bugs and solutions.<p>
<dl>
<dt>What is <b>Bacula</b>? </dt>
   <p></p>
    <dd><b>Bacula</b> is a network backup and restore program.</dd>

<dt>Does <b>Bacula</b> support Windows?</dt><p></p>
    <dd>Yes, <b>Bacula</b> compiles and runs on Windows machines
      (Win98, WinMe, WinXP, WinNT, and Win2000).
      We provide a binary version of the Client (bacula-fd), but have
      not tested the Director nor the Storage daemon. Note, Win95
      is no longer supported because it doesn't have the 
      GetFileAttributesExA API call.
      </dd>

<p>
<dt>What language is <b>Bacula</b> written in?
<p><dd>It is written in C++, but it is mostly C
      code using only a limited set of the C++ extensions
      over C. 
      Thus Bacula is completely
      compiled using the C++ compiler. There are several modules,
      including the Win32 interface that are written using the 
      object oriented C++ features. Over time, we are slowly adding a larger 
      subset of C++.
   <p><p>
<dt>On what machines does <b>Bacula</b> run?</dt>
 <p><dd><b>Bacula</b> builds and executes on RedHat Linux (versions
     7.1, 7.2, and 7.3), FreeBSD, Solaris, and Win32.  On  
     Win32 systems (Win95/98/Me/XP/NT/2000), only the client
     program (File daemon) has been tested.
     <p>Bacula has been my only backup tool for over
     three years backing up 5 machines nightly (3 Linux boxes
     running RedHat, a Win98 machine, and a WinNT machine).
     </dd>
   <p>
 <dt>Is <b>Bacula</b> stable?</dt>
   <p><dd>Yes, it is remarkably stable, but remember, there are 
      still a lot of unimplemented or partially implemented features.
      With a program of this size (70,000+ lines of C code
      not including the SQL programs) there are bound to be bugs.
      The current test environment (a twisted pair local network and a HP DLT
      backup tape) is rather idea, so additional testing on other
      sites is necessary. The File daemon has never crashed -- running
      months at a time with no intervention. The Storage daemon is
      remarkably stable with most of the problems arising during labeling
      or switching tapes. Storage daemon crashes are rare.
      The Director, given the multitude of functions it fulfills is
      also relatively stable. In a production environment, it rarely
      if ever crashes. Of the three daemons, the Director is the most
      prone to having problems. It frequently runs several months with 
      no problems.
      <p><p>There are a number of reasons for this stability.
      1. The program was largely written by one person to date (Kern). 
      2.  The program constantly is checking the chain of allocated
      memory buffers to ensure that no overruns have occurred.  3.  All
      memory leaks (orphaned buffers) are reported each time the program
      terminates.  4.  Any signal (segmentation fault, ...) generates a
      traceback that is emailed to the developer.  This permits quick
      resolution of bugs even if they only show up rarely in a
      production system.  </dd>
              
<a name="AuthorizationErrors"></a>
<dt>I'm Getting Authorization Errors. What is Going On?</dt>
 <p><dd>For security reasons, <b>Bacula</b> requires that both
     the File daemon and the Storage daemon know the name
     of the Director as well as his password. As a consequence,
     if you change the Director's name or password, you must
     make the corresponding change in the Storage daemon and
     in the File daemon configuration files.
     <p>During the authorization process, the Storage daemon
     and File daemon also require that the Director authenticate
     himself, so both ends require the other to have the correct
     name and password.
     <p>
     If you have edited the conf files and modified any name or
     any password, then your best bet is to go back to the
     original conf files generated by the Bacula installation
     process. Make only the absolutely necessary modifications
     to these files -- e.g. add the correct email address. Then
     follow the instructions in the <a href="running.html">
     Running Bacula</a> chapter of this manual. You will run
     a backup to disk and a restore. Only when that works, should
     you begin customization of the conf files.
     </dd>
   <p>

<a name="AccessProblems"></a>
<dt>Bacula Runs Fine but Cannot Access a Client on a Different Machine. Why?</dt>
 <p><dd>There are several reasons why Bacula could not contact a client
    on a different machine. They are:
    <ul>
      <li>It is a Windows Client, and the client died because of an
          improper configuration file. Check that the Bacula icon is in
          the system tray and the the menu items work.  If the client has
          died, the icon will disappear only when you move the mouse over
          the icon.</li>
      <li>The Client address or port is incorrect or not resolved by
          DNS. See if you can ping the client machine using the same
          address as in the Client record.</li>
      <li>You have a firewall, and it is blocking traffic on port
          9102 between the Director's machine and the Clients
          machine (or on port 9103 between the Client and the Storage daemon
          machines).</li>
      <li>Your password or names are not correct in both the Director and
          the Client machine.  Try configuring everything identical to
          how you run the client on the same machine as the Director, but
          just change the Address.  If that works, make the other changes
          one step at a time until it works.</li>
   </ul>

<dt>My Catalog is Full of Test Runs, How Can I Start Over?</dt>
 <p><dd>If you are using MySQL do the following:<br>
 <pre>
   cd &lt;bacula-source&gt;/src/cats
   ./drop_mysql_tables
   ./make_mysql_tables
 </pre>
 <p>
 If you are using SQLite, do the following:<br>
 <pre>
   Delete bacula.db from your working directory.
   cd &lt;bacula-source&gt;/src/cats
   ./drop_sqlite_tables
   ./make_sqlite_tables
 </pre>


 Then write an EOF on each tape you used with <b>Bacula</b>
 </dd>
   <p>

<dt>I Run a Restore Job and Bacula Hangs. What do I do?</dt>
  <p><dd>On Bacula version 1.25 and prior, it expects you to 
    have the correct tape mounted prior to a restore.  On
    Bacula version 1.26 and higher, it will ask you for the
    tape, and if the wrong one it mounted, it will inform you.
    <p>
    If you have previously done an <b>unmount</b> command, all
    Storage daemon sessions (jobs) will be completely blocked
    from using the drive unmounted, so be sure to do a <b>mount</b>
    after your unmount. If in doubt, do a second <b>mount</b>, it
    won't cause any harm.</dd>
    <p>

<dt>I Cannot Get My Windows Client to Start Automatically?</dt>
 <p><dd>You are probably having one of two problems: either the
   Client is dying due to an incorrect configuration file, or 
   you didn't do the Installation commands necessary to install
   it as a Windows Service.
   <p>
   For the first problem, see the next FAQ question. For the
   second problem, please review the <a href="win32.html">
   Windows Installation instructions</a> in this manual.
   </dd>
   <p>

<dt>My Windows Client Immediately Dies When I Start It</dt>
 <p><dd>The most common problem is either that the configuration
    file is not where it expects it to be, or that there is an
    error in the configuration file. 
    You must have the configuration file in
    <b>c:\bacula\bin\bacula-fd.conf</b>.
    <p>
    To <b>see</b> what is going on when the File daemon starts
    on Windows, do the following:
    <pre>
    Start a DOS shell Window.
    cd c:\bacula\bin
    bacula-fd -t &gt;out
    type out
    </pre>
    Calling <b>bacula-fd</b> with redirection (&gt;) will write the
    diagnostic output to the file <b>out</b> which you can then list.
    The <b>-t</b> option tells <b>Bacula</b> to read the configuration
    file and then exit.
   </dd>
   
   <p>

<dt>When I Start the Console, the Error Messages Fly By. How can I see them?</dt>
 <p><dd>Either use a shell window with a scroll bar, or use the gnome-console.
    In any case, you probably should be logging all output to a file, and
    then you can simply view the file using an editor or the <b>less</b>   
    program. To log all output, I have the following in my Director's
    Message resource definition:
    <pre>
    append = "/home/kern/bacula/bin/log" = all, !skipped
    </pre>

    Obviously you will want to change the filename to be appropriate 
    for your system.
   
   <p>

<dt>I didn't realize that the backups were not working on my Windows
     Client. What should I do?</dt>
 <p><dd>
     You should be sending yourself an email message for each job. This will
     avoid the possibility of not knowing about a failed backup.  To do so
     put something like:
  <pre>
  Mail = yourname@yourdomain = all, !skipped
  </pre>

   in your Director's message resource.  You should then receive one
   email for each Job that ran.  When you are comfortable with what
   is going on (it took me 9 months), you might change that to:

   <pre>
   MailOnError = yourname@yourdomain = all, !skipped
   </pre>

  then you only get email messages when a Job errors as is the case
  for your Windows machine.
  <p>You should also be logging the Director's messages, please see the
  previous FAQ for how to do so.
   </dd>
   <p>

<dt>All my Jobs are scheduled for the same time. Will this cause problems?</dt>
 <p><dd>No, not at all. <b>Bacula</b> will schedule all the Jobs at the same time,
    but will run them one after another unless you have increased the number
    of simultaneous jobs in the configuration files for the Director,
    the File daemon, and the Storage daemon. The appropriate configuration
    record is <b>Maximum Concurrent Jobs = nn</b>. At the current time,
    we recommend that you leave this set to <b>1</b> for the Director.
  </dd>
   <p>

<dt>Can Bacula Backup My System To Files instead of Tape?</dt>
 <p><dd>Yes, in principle, <b>Bacula</b> can backup to any storage
    medium as long as you have correctly defined that medium in the
    Storage daemon's Device resource.  For an example of how to backup
    to files, please see the 
    <a href="recycling.html#PruningExample">Pruning Example</a> in the
    Recycling chapter of this manual.  Also, there is a whole chapter
    devoted to <a href="disk.html">Backing Up to Disk</a>.
  </dd>
   <p>

<dt>Can Bacula Backup and Restore Files Greater than 2 Giga Bytes in Size?</dt>
 <p><dd>If your operating system permits it, and you are running Bacula
    version 1.26 or later, the answer is yes.  Unfortunately, large files
    are not supported by <b>cygwin</b> which Bacula uses for the
    Windows client.  However, 
    the native Windows APIs are used in Bacula version 1.31 and later
    on Windows systems, so in principal any 2 Giga Byte problems should
    disappear.
  </dd>
   <p>

<dt>I Started A Job then Decided I Really Did Not Want to Run It. Is there
    a better way than <b>./bacula stop</b> to stop it?</dt><p>
    <dd>Yes, you normally should use the Console command <b>cancel</b>
    to cancel a Job that is either scheduled or running.  If the Job is
    scheduled, it will be marked for cancellation and will be canceled 
    when it is scheduled to start. If it is running, it will normally
    terminate after a few minutes.  If the Job is waiting on a tape mount,
    you may need to do a <b>mount</b> command before it will be canceled.
    </dd><p>

<dt>Why have You Trademarked the Name Bacula<sup><small>&reg;</small></sup>?</dt>
    <p><dd>We have trademarked the name <b>Bacula</b> to ensure that all media
    written by any program named <b>Bacula</b> will always be compatible. Anyone
    may use the name Bacula, even in a derivative product as long as it
    remains totally compatible in all respects with the program defined
    here.</dd><p>
    
<dt>Why is Your Online Document for Version 1.27 of Bacula when the Currently
    Release Version is 1.26?</dt><p>
    <dd>As Bacula is being developed, the document is also being enhanced, more
    often than not it has clarifications of existing features that
    can be very useful to our users, so we publish the very latest
    document. Fortunately it is rare that there are confusions with
    new features.                
    <p>
    If you want to read a document that pertains only to a specific
    version, please use the one distributed in the source code. 
    </dd><p>

<dt>How Can You Be Sure that Bacula Really Saves and Restores All Files?</dt><p>
    <dd>It is really quite simple, but took me awhile to figure out how 
    to &quot;prove&quot; it. First make a Bacula Rescue disk, see the
    <a href="rescue.html">Disaster Recovery Using Bacula</a> of this manual.
    Second, you run a full backup of all your files
    on all partitions. Third, you run an Verify InitCatalog Job on the 
    same FileSet, which effectively makes a record of all the files on
    your system. Fourth, you run a Verify Catalog job and assure yourself that
    nothing has changed (well, between an InitCatalog and Catalog one doesn't
    expect anything). Then do the unthinkable, write zeros on your MBR (master
    boot record) wiping out your hard disk. Now, restore your whole system
    using your Bacula Rescue disk and the Full backup you made, and finally
    re-run the Verify Catalog job. You will see that with the exception of
    the directory modification and access dates and the files changed during
    the boot, your system is identical to what it was before you wiped
    your hard disk.</dd><p>

<dt>I did a Full backup last week, but now in running an Incremental, Bacula
    says it did not find a FULL backup time, so it did a FULL backup. Why?<dt><p>
    <dd>Before doing an Incremental or a Differential backup, Bacula checks
    to see if there was a prior Full backup of the same Job that terminated
    successfully. If so, it uses the date that full backup started as the
    time for comparing if files have changed. If Bacula does not find a
    successfully full backup, it proceeds to do one. Perhaps you canceled
    the full backup, or it terminated in error. In such cases, the full
    backup will not be successful. You can check by entering <b>list jobs</b>
    and look to see if there is a prior Job with the same Name that has
    Level F and JobStatus T (normal termination).
    <p>Another reason why Bacula may not find a suitable Full backup is
    that every time you change the FileSet, Bacula will require a new
    Full backup. This is necessary to ensure that all files are properly
    backed up in the case where you have added more files to the FileSet.
    Beginning with version 1.31, the FileSets are also dated when they
    are created, and this date is displayed with the name when you
    are listing or selecting a FileSet.   For more on backup levels
    see below.
    </dd><p>

<dt>How Can You Claim to Handle Unlimited Path and Filename Lengths when
    All Other Programs Have Fixed Limits?</dt><p>
    <dd>Most of those other programs have been around for a long time, in
    fact since the beginning of Unix, which means that they were designed
    for rather small fixed length path and filename lengths. Over the years,
    these restrictions have been relaxed allowing longer names. Bacula on the
    other hand was designed in 2000, and so from the start, Path and Filenames
    have been keep in buffers that start at 256 bytes in length but can
    grow as needed to handle any length. Most of the work is carried out
    by lower level routines making the coding rather easy.</dd><p>

<dt>What Is the Really Unique Feature of Bacula?</dt><p>
    <dd>Well, it is hard to come up with unique features when backup programs
    for Unix machines have been around since the 1960s. That said, I believe
    that Bacula is the first and only program to use a standard SQL interface
    to its catalog database. Although this adds a bit of complexity and 
    possibly overhead, it provides an amazingly rich set of features that are easy
    to program and enhance. The current code has barely scratched the surface
    in this regard (version 1.31).
    <p>The second feature, which gives a lot of power and flexibility to 
    Bacula is the Bootstrap record definition.
    <p>The third unique feature, which is currently (1.30) unimplemented, and
    thus can be called vaporware :-), is Base level saves. When implemented, this
    will enormously reduce tape usage.</dd><p>

<dt>Since Bacula is Multithreaded, Why Do You Recommend Not Running Multiple
    Simultaneous Jobs?</dt><p>
    <dd>Bacula can run multiple simultaneous jobs, but being very conservative,
    I do not recommend doing so at the current time for two reasons: 1. I'm
    not sure that two jobs accessing the same Volume won't have catalog 
    conflicts. 2. Doing a restore from a Volume with records from two jobs
    intermingled is complicated.<p>I expect to have definitive solutions to
    both of those problems in a later version. In the mean time, I recommend
    running one Job at a time. If you want to experiment with this as several
    large shops are doing, ensure that each job is writing to a different
    Volume (i.e. has a different Storage resource). This will avoid the
    two problems mentioned above. Just the same, there may be other race
    conditions in the Director that cause problems. Be forewarned.</dd><p>

<dt>If I Do Run Multiple Simultaneous Jobs, How Can I Force One Particular
    Job to Run After Another Job?</dt><p>
    <dd>Yes, you can set Priorities on your jobs so that they
    run in the order you specify.  Please see:
    <a href="dirdconf.html#Priority">the Priority record</a> in the                                   
    Job resource.</dd><p>

<dt>I Am Not Getting Email Notification, What Can I Do?</dt><p>
    <dd>The most common problem is that you have not specified a fully
    qualified email address and your smtp server is rejecting the mail.
    The next most common problem is that your smtp server doesn't like
    the syntax on the From part of the message. For more details on this
    and other problems, please see the <a href="tips.html#email">
    Getting Email Notification to Work</a> section of the Tips chapter
    of this manual. The section <a href="tips.html#notification">
    Getting Notified of Job Completion</a> of the Tips chapter may also
    be useful. For more information on the <b>smtp</b> mail program,
    please see <a href="progs.html#smtp">smtp in the Volume Utility
    Tools chapter</a> of this manual.</dd><p>

<dt>I Change Recycling, Retention Periods, or File Sizes in my Pool Resource
    and they Still Don"t Work.</dt><p>
    <dd>The different variables associated with a Pool are defined in the
    Pool Resource, but are actually read by Bacula from the Catalog database.
    On Bacula versions prior to 1.30, after changing your Pool Resource,
    you must manually update the corresponding values in the Catalog by
    using the <b>update pool</b> command in the Console program. In Bacula
    version 1.30, Bacula does this for you automatically every time it
    starts.
    <p>When Bacula creates a Media record (Volume), it uses many default
    values from the Pool record. If you subsequently change the Pool
    record, the new values will be used as a default for the next Volume
    that is created, but if you want the new values to apply to existing
    Volumes, you must manually update the Volume Catalog entry using
    the <b>update volume</b> command in the Console program. </dd><p>

<dt>I Have Configured Compression On, But None of My Files Are Compressed. 
    Why? </dt><p>
    <dd>There are two kinds of compression. One is tape compression. This
    is done by the tape drive hardware, and you either enable or disable
    it with system tools such as <b>mt</b>. This compression works 
    independently of Bacula. 
    <p>
    Bacula also has compression code, which is normally used only when
    backing up to file Volumes. There are two conditions for this
    &quot;software&quot; to be enabled. 
    <ol>
      <li>You must have the zip development libraries loaded on your
          system when building Bacula and Bacula must find this library,
          normally <b>/usr/lib/libz.a</b>. On RedHat systems, this library
          is provided by the <b>zlib-devel</b> rpm.
          <p>If the library is found by Bacula during the <b>./configure</b>
          it will be indicated on the <b>config.out</b> line by:
          <pre>
             ZLIB support:  yes
          </pre>
        </li>
       <li>You must add the <b>compression=gzip</b> option on your
           Include statement in the Director's configuration file.</li>
     </ol>
     </dd><p>

<dt>Bacula is Asking for a New Tape After 2 GB of Data but My Tape holds 33 GB. Why?</dt>
   <p>
   <dd>There are several reasons why Bacula will request a new tape.
     <ul>
       <li>There is an I/O error on the tape. Bacula prints an error message
           and requests a new tape. Bacula does not attempt to continue writing
           after an I/O error.</li>
       <li>Bacula encounters and end of medium on the tape. This is not always
           distinguishable from an I/O error.</li>                       
       <li>You have specifically set some size limitation on the tape. For
           example the <b>Maximum Volume Bytes</b> or <b>Maximum Volume Files</b>
           in the Director's Pool resource, or <b>Maximum Volume Size</b> in
           the Storage daemon's Device resource.</li>
        </ul>
     </dd><p>

<a name="LevelChanging">
<dt>Bacula is Not Doing the Right Thing When I Request an Incremental Backup. Why?</dt></a>
   <p>
   <dd>As explained in one of the previous questions, Bacula will automatically
    upgrade an Incremental or Differential job to a Full backup if it cannot
    find a prior Full backup or a suitable Full backup. For the gory details
    on how/when Bacula decides to upgrade levels please see the
    <a href="dirdconf.html#Level">Level record</a> in the Director's
    configuration chapter of this manual.  
    <p>
    If after reading the above mentioned section, you believe that Bacula
    is not correctly handling the level (Differential/Incremental),
    please send us the following information for analysis:
    <ul>
      <li>Your Director's configuration file.</li>
      <li>The output from <b>list jobs</b> covering the period where you
         are having the problem.</li>
      <li>The Job report output from the prior Full save (not critical).</li>
      <li>An <b>llist jobid=nnn</b> where nnn is the JobId of the prior
        Full save.</li>
      <li>The Job report output from the save that is doing the 
         wrong thing (not critical).</li>
       <li>An <b>llist jobid=nnn</b> where nnn is the JobId of the job
         that was not correct.</li>
       <li>An explanation of what job went wrong and why you think it did.</li>
    </ul>
    <p>
    The above information can allow us to analyze what happened, without it,
    there is not much we can do.
    </dd><p>

<a name="WaitForever"></a>
<dt>I am Backing Up an Offsite Machine with an Unreliable Connection. The   
    Director Waits Forever for the Client to Contact the SD. What Can
    I Do.</dt>
    <p>
    Bacula was written
    on the assumption that it will have a good TCP/IP connection
    between all the daemons.  As a consequence, the current
    Bacula doesn't deal with fauty connection very well.  This situation
    is slowly being corrected over time.
    <p>There are several things you can do to improve the situation. 
     <ul>
       <li>Upgrade to version 1.32 and use the new SDConnectTimeout record.
          For example, set:
          <pre>
          SD Connect Timeout = 5 min
          </pre>
           in the FileDaemon resource.</li>
        <li>Run these kinds of jobs after all other jobs.</li>
      </ul>
       </dd><p>

</dl>



<page_prev name="LGPL" url="lesser.html">
<page_next name="Projects" url="projects.html">
