From: Kern Sibbald Date: Mon, 12 Dec 2005 16:42:42 +0000 (+0000) Subject: updates X-Git-Tag: Release-1.38.3~29 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=4504faab36181163bcae7b1e4a5dda1cdb2fe37b;p=bacula%2Fdocs updates --- diff --git a/docs/developers/generaldevel.tex b/docs/developers/generaldevel.tex index fce20d9f..aeb82d52 100644 --- a/docs/developers/generaldevel.tex +++ b/docs/developers/generaldevel.tex @@ -335,7 +335,7 @@ I expect that future release schedules will be much the same, and the number of new features will also be much the same providing that the contributions continue to come -- and they show no signs of let up :-) -\bf{Feature Requests:} \\ +{\bf Feature Requests:} \\ In addition, I would like to "formalize" the feature requests a bit. Instead of me maintaining an informal list of everything I run into @@ -359,12 +359,12 @@ reject it. If it is accepted, it will go in the "projects" file (a simple ASCII file) maintained in the main Bacula source directory. -\bf{Implementation of Feature Requests:}\\ +{\bf Implementation of Feature Requests:}\\ Any qualified developer can sign up for a project. The project must have an entry in the projects file, and the developer's name will appear in the Status field. -\bf{How Feature Requests are accepted:}\\ +{\bf How Feature Requests are accepted:}\\ Acceptance of Feature Requests depends on several things: \\ 1. feedback from users. If it is negative, the Feature Request will probably not be accepted. \\ @@ -375,7 +375,7 @@ be accepted. \\ current stategy of Bacula (for example an Feature Request that requests changing the tape to tar format would not be accepted, ...) -\bf{How Feature Requests are prioritized:}\\ +{\bf How Feature Requests are prioritized:}\\ Once an Feature Request is accepted, it needs to be implemented. If you can find a developer for it, or one signs up for implementing it, then the Feature Request becomes top priority (at least for that developer). diff --git a/docs/developers/version.tex b/docs/developers/version.tex index 5ac2412b..df53f38e 100644 --- a/docs/developers/version.tex +++ b/docs/developers/version.tex @@ -1 +1 @@ -1.38.2 (20 November 2005) +1.38.3 (09 December 2005) diff --git a/docs/home-page/donations.txt b/docs/home-page/donations.txt index e9a5ff6d..0bcf1e41 100644 --- a/docs/home-page/donations.txt +++ b/docs/home-page/donations.txt @@ -1,6 +1,6 @@ -Kern;;;2005/11/02;;;12:30 +Kern;;;2005/12/06;;;12:30 Bacula is now able to accept direct donations, and as of -02 November 2005, we have received the following: +7 December 2005, we have received the following: Amount: Donor: $ 50 Ludovic Strappazon @@ -8,16 +8,17 @@ Bacula is now able to accept direct donations, and as of $ 20 Jan Kesten $100 Anonymous $442 GDC A Kendall, Dominic Marks + $ 65 Jim Barlow -Total $682.73 After PayPal fees are deducted +Total $744.89 After PayPal fees are deducted Many thanks to these Bacula supporters. ;;; -Kern;;;2005/09/28;;;16:30 +Kern;;;2005/12/06;;;16:30 Results to date of donations to EFF for the Data Encryption project -28 October 2005 +7 December 2005 Donor: Amount: WingNET Internet $500 Timo Neuvonen $250 @@ -38,8 +39,7 @@ Additional information is available from Landon at: http://landonf.bikemonkey.org/code/bacula -Read on for details of the project, which is now partially -implemented and being worked on by Landon in the Branch-1_38-encryption -branch of the Bacula CVS. +The data encryption project is progressing nicely. Landon has now +integrated his code into the main CVS development branch. ;;; diff --git a/docs/home-page/images/1.39-wishlist-votes.png b/docs/home-page/images/1.39-wishlist-votes.png new file mode 100644 index 00000000..7e1c4de3 Binary files /dev/null and b/docs/home-page/images/1.39-wishlist-votes.png differ diff --git a/docs/home-page/inc/header.php b/docs/home-page/inc/header.php index 8c9fd42d..cc650e20 100644 --- a/docs/home-page/inc/header.php +++ b/docs/home-page/inc/header.php @@ -1,40 +1,40 @@ @@ -144,26 +144,28 @@ - + +
Downloads
- +
- Sectoor Logo - - + Sectoor Logo + +
diff --git a/docs/home-page/index.php b/docs/home-page/index.php index 1f7241a7..804203d8 100644 --- a/docs/home-page/index.php +++ b/docs/home-page/index.php @@ -12,15 +12,14 @@ require_once("inc/header.php"); * */ if(is_file($page_current)) { - include_once($page_current); -} -else { - printf(' -   - An ERROR occured:
-

- The page %s isn\'t available. -

', $page); + include_once($page_current); +} else { + printf(' +   + An ERROR occurred:
+

+ The page %s isn\'t available. +

', $page); } diff --git a/docs/home-page/pages/projects.php b/docs/home-page/pages/projects.php new file mode 100644 index 00000000..cb854143 --- /dev/null +++ b/docs/home-page/pages/projects.php @@ -0,0 +1,728 @@ + + + + + + +
+ +
+                
+Projects:
+                     Bacula Projects Roadmap 
+                       07 December 2005
+                    (prioritized by user vote)
+
+Summary:
+Item  1:  Implement data encryption (as opposed to comm encryption)
+Item  2:  Implement Migration that moves Jobs from one Pool to another.
+Item  3:  Accurate restoration of renamed/deleted files from
+Item  4:  Implement a Bacula GUI/management tool using Python.
+Item  5:  Implement Base jobs.
+Item  6:  Allow FD to initiate a backup
+Item  7:  Improve Bacula's tape and drive usage and cleaning management.
+Item  8:  Implement creation and maintenance of copy pools
+Item  9:  Implement new {Client}Run{Before|After}Job feature.
+Item 10:  Merge multiple backups (Synthetic Backup or Consolidation).
+Item 11:  Deletion of Disk-Based Bacula Volumes
+Item 12:  Directive/mode to backup only file changes, not entire file
+Item 13:  Multiple threads in file daemon for the same job
+Item 14:  Implement red/black binary tree routines.
+Item 15:  Add support for FileSets in user directories  CACHEDIR.TAG
+Item 16:  Implement extraction of Win32 BackupWrite data.
+Item 17:  Implement a Python interface to the Bacula catalog.
+Item 18:  Archival (removal) of User Files to Tape
+Item 19:  Add Plug-ins to the FileSet Include statements.
+Item 20:  Implement more Python events in Bacula.
+Item 21:  Quick release of FD-SD connection after backup.
+Item 22:  Permit multiple Media Types in an Autochanger
+Item 23:  Allow different autochanger definitions for one autochanger.
+Item 24:  Automatic disabling of devices
+Item 25:  Implement huge exclude list support using hashing.
+
+
+Below, you will find more information on future projects:
+
+Item  1:  Implement data encryption (as opposed to comm encryption)
+  Date:   28 October 2005
+  Origin: Sponsored by Landon and 13 contributors to EFF.
+  Status: Landon Fuller is currently implementing this.
+                  
+  What:   Currently the data that is stored on the Volume is not
+          encrypted. For confidentiality, encryption of data at
+          the File daemon level is essential. 
+          Data encryption encrypts the data in the File daemon and
+          decrypts the data in the File daemon during a restore.
+
+  Why:    Large sites require this.
+
+Item 2:   Implement Migration that moves Jobs from one Pool to another.
+  Origin: Sponsored by Riege Software International GmbH. Contact:
+          Daniel Holtkamp 
+  Date:   28 October 2005
+  Status: Partially coded in 1.37 -- much more to do. Assigned to
+          Kern.
+
+  What:   The ability to copy, move, or archive data that is on a
+          device to another device is very important. 
+
+  Why:    An ISP might want to backup to disk, but after 30 days
+          migrate the data to tape backup and delete it from
+          disk.  Bacula should be able to handle this
+          automatically.  It needs to know what was put where,
+          and when, and what to migrate -- it is a bit like
+          retention periods.  Doing so would allow space to be
+          freed up for current backups while maintaining older
+          data on tape drives.
+
+  Notes:   Riege Software have asked for the following migration
+           triggers:
+           Age of Job
+           Highwater mark (stopped by Lowwater mark?)
+                            
+  Notes:  Migration could be additionally triggered by:
+           Number of Jobs
+           Number of Volumes
+
+Item  3:  Accurate restoration of renamed/deleted files from
+          Incremental/Differential backups
+  Date:   28 November 2005
+  Origin: Martin Simmons (martin at lispworks dot com)
+  Status:
+
+  What:   When restoring a fileset for a specified date (including "most
+          recent"), Bacula should give you exactly the files and directories
+          that existed at the time of the last backup prior to that date.
+
+          Currently this only works if the last backup was a Full backup.
+          When the last backup was Incremental/Differential, files and
+          directories that have been renamed or deleted since the last Full
+          backup are not currently restored correctly.  Ditto for files with
+          extra/fewer hard links than at the time of the last Full backup.
+
+  Why:    Incremental/Differential would be much more useful if this worked.
+
+  Notes:  Item 14 (Merging of multiple backups into a single one) seems to
+          rely on this working, otherwise the merged backups will not be
+          truly equivalent to a Full backup.  
+
+          Kern: notes shortened. This can be done without the need for 
+          inodes. It is essentially the same as the current Verify job,
+          but one additional database record must be written, which does 
+          not need any database change.
+
+Item 4:   Implement a Bacula GUI/management tool using Python.
+  Origin: Kern
+  Date:   28 October 2005
+  Status: 
+
+  What:   Implement a Bacula console, and management tools
+          using Python and Qt or GTK.
+
+  Why:    Don't we already have a wxWidgets GUI?  Yes, but
+          it is written in C++ and changes to the user interface
+          must be hand tailored using C++ code. By developing
+          the user interface using Qt designer, the interface
+          can be very easily updated and most of the new Python       
+          code will be automatically created.  The user interface
+          changes become very simple, and only the new features
+          must be implement.  In addition, the code will be in
+          Python, which will give many more users easy (or easier)
+          access to making additions or modifications.
+
+ Notes:   This is currently being implemented using Python-GTK by       
+          Lucas Di Pentima 
+
+Item 5:   Implement Base jobs.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
+  
+  What:   A base job is sort of like a Full save except that you 
+          will want the FileSet to contain only files that are
+          unlikely to change in the future (i.e.  a snapshot of
+          most of your system after installing it).  After the
+          base job has been run, when you are doing a Full save,
+          you specify one or more Base jobs to be used.  All
+          files that have been backed up in the Base job/jobs but
+          not modified will then be excluded from the backup.
+          During a restore, the Base jobs will be automatically
+          pulled in where necessary.
+
+  Why:    This is something none of the competition does, as far as
+          we know (except perhaps BackupPC, which is a Perl program that
+          saves to disk only).  It is big win for the user, it
+          makes Bacula stand out as offering a unique
+          optimization that immediately saves time and money.
+          Basically, imagine that you have 100 nearly identical
+          Windows or Linux machine containing the OS and user
+          files.  Now for the OS part, a Base job will be backed
+          up once, and rather than making 100 copies of the OS,
+          there will be only one.  If one or more of the systems
+          have some files updated, no problem, they will be
+          automatically restored.
+
+  Notes:  Huge savings in tape usage even for a single machine.
+          Will require more resources because the DIR must send
+          FD a list of files/attribs, and the FD must search the
+          list and compare it for each file to be saved.
+
+Item  6:  Allow FD to initiate a backup
+  Origin: Frank Volf (frank at deze dot org)
+  Date:   17 November 2005
+  Status:
+
+   What:  Provide some means, possibly by a restricted console that
+          allows a FD to initiate a backup, and that uses the connection
+          established by the FD to the Director for the backup so that
+          a Director that is firewalled can do the backup.
+
+   Why:   Makes backup of laptops much easier.
+
+Item  7:  Improve Bacula's tape and drive usage and cleaning management.
+  Date:   8 November 2005, November 11, 2005
+  Origin: Adam Thornton ,
+          Arno Lehmann 
+  Status:
+
+  What:   Make Bacula manage tape life cycle information, tape reuse
+          times and drive cleaning cycles.
+
+  Why:    All three parts of this project are important when operating
+          backups.
+          We need to know which tapes need replacement, and we need to
+          make sure the drives are cleaned when necessary.  While many
+          tape libraries and even autoloaders can handle all this
+          automatically, support by Bacula can be helpful for smaller
+          (older) libraries and single drives.  Limiting the number of
+          times a tape is used might prevent tape errors when using
+          tapes until the drives can't read it any more.  Also, checking
+          drive status during operation can prevent some failures (as I
+          [Arno] had to learn the hard way...)
+
+  Notes:  First, Bacula could (and even does, to some limited extent)
+          record tape and drive usage.  For tapes, the number of mounts,
+          the amount of data, and the time the tape has actually been
+          running could be recorded.  Data fields for Read and Write
+          time and Number of mounts already exist in the catalog (I'm
+          not sure if VolBytes is the sum of all bytes ever written to
+          that volume by Bacula).  This information can be important
+          when determining which media to replace.  The ability to mark
+          Volumes as "used up" after a given number of write cycles
+          should also be implemented so that a tape is never actually
+          worn out.  For the tape drives known to Bacula, similar
+          information is interesting to determine the device status and
+          expected life time: Time it's been Reading and Writing, number
+          of tape Loads / Unloads / Errors.  This information is not yet
+          recorded as far as I [Arno] know.  A new volume status would
+          be necessary for the new state, like "Used up" or "Worn out".
+          Volumes with this state could be used for restores, but not
+          for writing. These volumes should be migrated first (assuming
+          migration is implemented) and, once they are no longer needed,
+          could be moved to a Trash pool.
+
+          The next step would be to implement a drive cleaning setup.
+          Bacula already has knowledge about cleaning tapes.  Once it
+          has some information about cleaning cycles (measured in drive
+          run time, number of tapes used, or calender days, for example)
+          it can automatically execute tape cleaning (with an
+          autochanger, obviously) or ask for operator assistance loading
+          a cleaning tape.
+
+          The final step would be to implement TAPEALERT checks not only
+          when changing tapes and only sending the information to the
+          administrator, but rather checking after each tape error,
+          checking on a regular basis (for example after each tape
+          file), and also before unloading and after loading a new tape.
+          Then, depending on the drives TAPEALERT state and the known
+          drive cleaning state Bacula could automatically schedule later
+          cleaning, clean immediately, or inform the operator.
+
+          Implementing this would perhaps require another catalog change
+          and perhaps major changes in SD code and the DIR-SD protocol,
+          so I'd only consider this worth implementing if it would
+          actually be used or even needed by many people.
+
+          Implementation of these projects could happen in three distinct
+          sub-projects: Measuring Tape and Drive usage, retiring
+          volumes, and handling drive cleaning and TAPEALERTs.
+
+Item  8:  Implement creation and maintenance of copy pools
+  Date:   27 November 2005
+  Origin: David Boyes (dboyes at sinenomine dot net)
+  Status:
+
+  What:   I would like Bacula to have the capability to write copies
+          of backed-up data on multiple physical volumes selected
+          from different pools without transferring the data
+          multiple times, and to accept any of the copy volumes
+          as valid for restore.
+
+  Why:    In many cases, businesses are required to keep offsite
+          copies of backup volumes, or just wish for simple
+          protection against a human operator dropping a storage
+          volume and damaging it. The ability to generate multiple
+          volumes in the course of a single backup job allows
+          customers to simple check out one copy and send it
+          offsite, marking it as out of changer or otherwise
+          unavailable. Currently, the library and magazine
+          management capability in Bacula does not make this process
+          simple.
+
+          Restores would use the copy of the data on the first
+          available volume, in order of copy pool chain definition.
+
+          This is also a major scalability issue -- as the number of
+          clients increases beyond several thousand, and the volume
+          of data increases, transferring the data multiple times to
+          produce additional copies of the backups will become
+          physically impossible due to transfer speed
+          issues. Generating multiple copies at server side will
+          become the only practical option. 
+
+  How:    I suspect that this will require adding a multiplexing
+          SD that appears to be a SD to a specific FD, but 1-n FDs
+          to the specific back end SDs managing the primary and copy
+          pools.  Storage pools will also need to acquire parameters
+          to define the pools to be used for copies. 
+
+  Notes:  I would commit some of my developers' time if we can agree
+          on the design and behavior. 
+
+Item  9:  Implement new {Client}Run{Before|After}Job feature.
+  Date:   26 September 2005
+  Origin: Phil Stracchino 
+  Status: 
+
+  What:   Some time ago, there was a discussion of RunAfterJob and
+          ClientRunAfterJob, and the fact that they do not run after failed
+          jobs.  At the time, there was a suggestion to add a
+          RunAfterFailedJob directive (and, presumably, a matching
+          ClientRunAfterFailedJob directive), but to my knowledge these
+          were never implemented.
+
+          An alternate way of approaching the problem has just occurred to
+          me.  Suppose the RunBeforeJob and RunAfterJob directives were
+          expanded in a manner something like this example:
+
+          RunBeforeJob {
+              Command = "/opt/bacula/etc/checkhost %c"
+              RunsOnClient = No
+              RunsAtJobLevels = All       # All, Full, Diff, Inc
+              AbortJobOnError = Yes
+          }
+          RunBeforeJob {
+              Command = c:/bacula/systemstate.bat
+              RunsOnClient = yes
+              RunsAtJobLevels = All       # All, Full, Diff, Inc
+              AbortJobOnError = No
+          }
+
+          RunAfterJob {
+              Command = c:/bacula/deletestatefile.bat
+              RunsOnClient = Yes
+              RunsAtJobLevels = All       # All, Full, Diff, Inc
+              RunsOnSuccess = Yes
+              RunsOnFailure = Yes
+          }
+          RunAfterJob {
+              Command = c:/bacula/somethingelse.bat
+              RunsOnClient = Yes
+              RunsAtJobLevels = All
+              RunsOnSuccess = No
+              RunsOnFailure = Yes
+          }
+          RunAfterJob {
+              Command = "/opt/bacula/etc/checkhost -v %c"
+              RunsOnClient = No
+              RunsAtJobLevels = All
+              RunsOnSuccess = No
+              RunsOnFailure = Yes
+          }
+
+
+  Why:    It would be a significant change to the structure of the
+          directives, but allows for a lot more flexibility, including
+          RunAfter commands that will run regardless of whether the job
+          succeeds, or RunBefore tasks that still allow the job to run even
+          if that specific RunBefore fails.
+
+  Notes:  By Kern: I would prefer to have a single new Resource called
+          RunScript. More notes from Phil:
+
+            RunBeforeJob = yes|no
+            RunAfterJob = yes|no
+            RunsAtJobLevels = All|Full|Diff|Inc
+
+          The AbortJobOnError, RunsOnSuccess and RunsOnFailure directives
+          could be optional, and possibly RunsWhen as well.
+
+          AbortJobOnError would be ignored unless RunsWhen was set to Before
+          (or RunsBefore Job set to Yes), and would default to Yes if
+          omitted.  If AbortJobOnError was set to No, failure of the script
+          would still generate a warning.
+
+          RunsOnSuccess would be ignored unless RunsWhen was set to After
+          (or RunsBeforeJob set to No), and default to Yes.
+
+          RunsOnFailure would be ignored unless RunsWhen was set to After,
+          and default to No.
+
+          Allow having the before/after status on the script command
+          line so that the same script can be used both before/after.
+          David Boyes.
+
+Item 10:  Merge multiple backups (Synthetic Backup or Consolidation).
+  Origin: Marc Cousin and Eric Bollengier 
+  Date:   15 November 2005
+  Status: Depends on first implementing project Item 1 (Migration).
+
+  What:   A merged backup is a backup made without connecting to the Client.
+          It would be a Merge of existing backups into a single backup.
+          In effect, it is like a restore but to the backup medium.
+
+          For instance, say that last Sunday we made a full backup.  Then
+          all week long, we created incremental backups, in order to do
+          them fast.  Now comes Sunday again, and we need another full.
+          The merged backup makes it possible to do instead an incremental
+          backup (during the night for instance), and then create a merged
+          backup during the day, by using the full and incrementals from
+          the week.  The merged backup will be exactly like a full made
+          Sunday night on the tape, but the production interruption on the
+          Client will be minimal, as the Client will only have to send
+          incrementals.
+
+          In fact, if it's done correctly, you could merge all the
+          Incrementals into single Incremental, or all the Incrementals
+          and the last Differential into a new Differential, or the Full,
+          last differential and all the Incrementals into a new Full
+          backup.  And there is no need to involve the Client.
+
+  Why:    The benefit is that :
+          - the Client just does an incremental ;
+          - the merged backup on tape is just as a single full backup,
+            and can be restored very fast.
+
+          This is also a way of reducing the backup data since the old
+          data can then be pruned (or not) from the catalog, possibly
+          allowing older volumes to be recycled
+
+Item 11:  Deletion of Disk-Based Bacula Volumes
+  Date:   Nov 25, 2005
+  Origin: Ross Boylan  (edited
+          by Kern)
+  Status:         
+
+   What:  Provide a way for Bacula to automatically remove Volumes
+          from the filesystem, or optionally to truncate them.
+          Obviously, the Volume must be pruned prior removal.
+
+  Why:    This would allow users more control over their Volumes and
+          prevent disk based volumes from consuming too much space.
+
+  Notes:  The following two directives might do the trick:
+
+          Volume Data Retention =
+ +
+ + diff --git a/docs/home-page/pages/vote.php b/docs/home-page/pages/vote.php new file mode 100644 index 00000000..db055aae --- /dev/null +++ b/docs/home-page/pages/vote.php @@ -0,0 +1,12 @@ + + + + + + +
+

+ +

+ + diff --git a/docs/manual-de/console.tex b/docs/manual-de/console.tex index 6b68dfc6..cfb28dd8 100644 --- a/docs/manual-de/console.tex +++ b/docs/manual-de/console.tex @@ -807,7 +807,8 @@ setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director | running jobs. The full form of this command is: status [all | dir=\lt{}dir-name\gt{} | director | - client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}] + client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{} | + days=nnn] If you do a {\bf status dir}, the console will list any currently running jobs, a summary of all jobs scheduled to be run in the next 24 @@ -842,6 +843,12 @@ status [all | dir=\lt{}dir-name\gt{} | director | JobId 2508 (MatouVerify) is waiting because only one job can run at a time, hence it is simply "waiting execution" + If you do a {\bf status dir}, it will by default list all jobs + that are scheduled in the next two days. If you wish to see + the jobs that are scheduled in the next 3 days (e.g. on Friday + you want to see wat tapes are scheduled to be used on Monday), you + can add the {\bf days=3} option. + \item [unmount] \index[console]{unmount} This command causes the indicated Bacula Storage daemon to unmount the diff --git a/docs/manual-de/restore.tex b/docs/manual-de/restore.tex index 79487cf9..4443d4c0 100644 --- a/docs/manual-de/restore.tex +++ b/docs/manual-de/restore.tex @@ -898,10 +898,6 @@ 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. \begin{description} -\item [Problem] - Your catalog has been damaged and Bacula either doesn't work or prints - errors. -\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. @@ -943,27 +939,25 @@ Priority: 10 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. You will then need to follow the instructions for your + database type to recreate the database from the ASCII backup file. \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 + 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} @@ -1010,19 +1004,16 @@ VolSessionTime=1114075126 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" @@ -1033,6 +1024,67 @@ VolBlock=0-4053 FileIndex=1-1 \end{verbatim} \normalsize + +\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 @@ -1076,16 +1128,12 @@ Volume "DLT-22Apr05" 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. + 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. + 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 @@ -1111,4 +1159,5 @@ Choose a query (1-15): \end{verbatim} \normalsize + \end{description} diff --git a/docs/manual-de/rpm-faq.tex b/docs/manual-de/rpm-faq.tex index ead5534a..1a68b3a5 100644 --- a/docs/manual-de/rpm-faq.tex +++ b/docs/manual-de/rpm-faq.tex @@ -192,12 +192,14 @@ The spec file currently supports building on the following platforms: \footnotesize \begin{verbatim} # RedHat builds +--define "build_rh7 1" --define "build_rh8 1" --define "build_rh9 1" # Fedora Core build --define "build_fc1 1" --define "build_fc3 1" +--define "build_fc4 1" # Whitebox Enterprise build --define "build_wb3 1" @@ -231,4 +233,3 @@ Sqlite support: \end{verbatim} \normalsize - diff --git a/docs/manual-de/security.tex b/docs/manual-de/security.tex index e48ab19e..3fd41a48 100644 --- a/docs/manual-de/security.tex +++ b/docs/manual-de/security.tex @@ -29,8 +29,8 @@ \item Currently all data that is sent across the network is unencrypted. As a consequence, unless you use {\bf ssh} or {\bf stunnel} for port forwarding, it is not recommended to do a backup across an insecure network (e.g. the -Internet). In a future version, we plan to have {\bf ssl} encryption -built-in. + Internet). In a future version, we plan to have {\bf ssl} encryption + built-in. \item You should ensure that the Bacula working directories are readable and writable only by the Bacula daemons. \item If you are using {\bf MySQL} it is not necessary for it to run with @@ -46,12 +46,52 @@ built-in. the respective daemon configuration files. \end{itemize} -\label{wrappers} -\subsection*{Configuring and Testing TCP Wrappers with Bacula} -\index[general]{Configuring and Testing TCP Wrappers with Bacula } -\addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers with -Bacula} +\subsection*{Backward Compatibility} +\index[general]{Backward Compatibility} +\addcontentsline{toc}{subsection}{Backward Compatibility} +One of the major goals of Bacula is to ensure that you can restore +tapes (I'll use the word tape to include disk Volumes) that you wrote years +ago. This means that each new version of Bacula should be able to read old +format tapes. The first problem you will have is to ensure that the +hardware is still working some years down the road, and the second +problem will be to ensure that the media will still be good, then +your OS must be able to interface to the device, and finally Bacula +must be able to recogize old formats. All the problems except the +last are ones that we cannot solve, but by careful planning you can. + +Since the very beginning of Bacula (January 2000) until today (December +2005), there have been two major Bacula tape formats. The second format +was introduced in version 1.27 in November of 2002, and it has not +changed since then. In principle, Bacula can still read the original +format, but I haven't tried it lately so who knows ... + +Though the tape format is fixed, the kinds of data that we can put on the +tapes are extensible, and that is how we added new features +such as ACLs, Win32 data, encrypted data, ... Obviously, an older +version of Bacula would not know how to read these newer data streams, +but each newer version of Bacula should know how to read all the +older streams. + +If you want to be 100% sure that you can read old tapes, you +should: + +1. Try reading old tapes from time to time -- e.g. at least once +a year. + +2. Keep statically linked copies of every version of Bacula that you use +in production then if for some reason, we botch up old tape compatibility, you +can always pull out an old copy of Bacula ... + +The second point is probably overkill but if you want to be sure, it may +save you someday. + + + +\label{wrappers} +subsection*{Configuring and Testing TCP Wrappers} +index[general]{Configuring and Testing TCP Wrappers} +addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers} TCP Wrappers are implemented if you turn them on when configuring ({\bf ./configure \verb:--:with-libwrap}). With this code enabled, you may control who may diff --git a/docs/manual-de/storedconf.tex b/docs/manual-de/storedconf.tex index 447b5719..435d9c40 100644 --- a/docs/manual-de/storedconf.tex +++ b/docs/manual-de/storedconf.tex @@ -438,26 +438,48 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface for reserving a drive for something special such as a high priority backup or restore operations. -\item [Maximum Changer Wait = {\it time}] - \index[sd]{Maximum Changer Wait } - This directive specifies the maximum time for Bacula to wait for an - autochanger to change the volume. If this time is exceeded, Bacula will - invalidate the Volume slot number stored in the catalog and try again. If no - additional changer volumes exist, Bacula will ask the operator to intervene. - The default time out is 5 minutes. +\item [Maximum Changer Wait = {\it seconds}] + \index[sd]{Maximum Changer Wait} + This directive specifies the maximum time in seconds for Bacula to wait + for an autochanger to change the volume. If this time is exceeded, + Bacula will invalidate the Volume slot number stored in the catalog and + try again. If no additional changer volumes exist, Bacula will ask the + operator to intervene. The default is 5 minutes. + + Please note that if you want to set your changer wait time to + 10 minutes, you must specify: + +\begin{verbatim} +Maximum Changer Wait = 600 +\end{verbatim} + + This directive will not accept qualifiers (such as "minutes"). + +\item [Maximum Rewind Wait = {\it seconds}] + \index[sd]{Maximum Rewind Wait} + This directive specifies the maximum time in seconds for Bacula to wait + for a rewind before timing out. If this time is exceeded, + Bacula will cancel the job. The default is 5 minutes. + +\item [Maximum Open Wait = {\it seconds}] + \index[sd]{Maximum Open Wait} + This directive specifies the maximum time in seconds for Bacula to wait + for a open before timing out. If this time is exceeded, + Bacula will cancel the job. The default is 5 minutes. \item [Always Open = {\it Yes|No}] \index[sd]{Always Open } - If {\bf Yes} (default), Bacula will always keep the device open unless - specifically {\bf unmounted} by the Console program. This permits Bacula to - ensure that the tape drive is always available. If you set {\bf AlwaysOpen} - to {\bf no} {\bf Bacula} will only open the drive when necessary, and at the - end of the Job if no other Jobs are using the drive, it will be freed. The - next time Bacula wants to append to a tape on a drive that was freed, Bacula - must rewind the tape and position to the end. To avoid unnecessary tape positioning - and to minimize unnecessary operator intervention, it is highly recommended that - {\bf Always Open = yes}. This also ensures that the drive is available when - Bacula needs it. + If {\bf Yes} (default), Bacula will always keep the device open unless + specifically {\bf unmounted} by the Console program. This permits + Bacula to ensure that the tape drive is always available. If you set + {\bf AlwaysOpen} to {\bf no} {\bf Bacula} will only open the drive when + necessary, and at the end of the Job if no other Jobs are using the + drive, it will be freed. The next time Bacula wants to append to a tape + on a drive that was freed, Bacula must rewind the tape and position to + the end. To avoid unnecessary tape positioning and to minimize + unnecessary operator intervention, it is highly recommended that {\bf + Always Open = yes}. This also ensures that the drive is available when + Bacula needs it. If you have {\bf Always Open = yes} (recommended) and you want to use the drive for something else, simply use the {\bf unmount} command in the Console @@ -503,12 +525,13 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface the drive on the next poll and automatically continue with the backup. Please see above more more details. -\item [Maximum Open Wait = {\it time}] +\item [Maximum Open Wait = {\it seconds}] \index[sd]{Maximum Open Wait } - This directive specifies the maximum amount of time that Bacula will wait for - a device that is busy. The default is 5 minutes. If the device cannot be - obtained, the current Job will be terminated in error. Bacula will re-attempt - to open the drive the next time a Job starts that needs the the drive. + This directive specifies the maximum amount of time in seconds that + Bacula will wait for a device that is busy. The default is 5 minutes. + If the device cannot be obtained, the current Job will be terminated in + error. Bacula will re-attempt to open the drive the next time a Job + starts that needs the the drive. \item [Removable media = {\it Yes|No}] \index[sd]{Removable media } @@ -524,22 +547,22 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface \item [Minimum block size = {\it size-in-bytes}] \index[sd]{Minimum block size } - On most modern tape drives, you will not need or wamt to specify this directive, and - if you do so, it will be to make Bacula use fixed block sizes. This - statement applies only to non-random access devices (e.g. tape drives). - Blocks written by the storage daemon to a non-random archive device will - never be smaller than the given {\bf size-in-bytes}. The Storage daemon will - attempt to efficiently fill blocks with data received from active sessions - but will, if necessary, add padding to a block to achieve the required - minimum size. + On most modern tape drives, you will not need or wamt to specify this + directive, and if you do so, it will be to make Bacula use fixed block + sizes. This statement applies only to non-random access devices (e.g. + tape drives). Blocks written by the storage daemon to a non-random + archive device will never be smaller than the given {\bf size-in-bytes}. + The Storage daemon will attempt to efficiently fill blocks with data + received from active sessions but will, if necessary, add padding to a + block to achieve the required minimum size. - To force the block size to be fixed, as is the case for some non-random - access devices (tape drives), set the {\bf Minimum block size} and the {\bf - Maximum block size} to the same value (zero included). The default is that - both the minimum and maximum block size are zero and the default block size - is 64,512 bytes. If you wish the block size to be fixed and different from - the default, specify the same value for both {\bf Minimum block size} and - {\bf Maximum block size}. + To force the block size to be fixed, as is the case for some non-random + access devices (tape drives), set the {\bf Minimum block size} and the + {\bf Maximum block size} to the same value (zero included). The default + is that both the minimum and maximum block size are zero and the default + block size is 64,512 bytes. If you wish the block size to be fixed and + different from the default, specify the same value for both {\bf Minimum + block size} and {\bf Maximum block size}. For example, suppose you want a fixed block size of 100K bytes, then you would specify: @@ -573,17 +596,18 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface \item [Maximum block size = {\it size-in-bytes}] \index[sd]{Maximum block size } - On most modern tape drives, you will not need to specify this directive. If - you do so, it will most likely be to use fixed block sizes (see Minimum block - size above). The Storage daemon will aways attempt to write blocks of the - specified {\bf size-in-bytes} to the archive device. As a consequence, this - statement specifies both the default block size and the maximum block size. - The size written never exceed the given {\bf size-in-bytes}. If adding data - to a block would cause it to exceed the given maximum size, the block will be - written to the archive device, and the new data will begin a new block. + On most modern tape drives, you will not need to specify this directive. + If you do so, it will most likely be to use fixed block sizes (see + Minimum block size above). The Storage daemon will aways attempt to + write blocks of the specified {\bf size-in-bytes} to the archive device. + As a consequence, this statement specifies both the default block size + and the maximum block size. The size written never exceed the given + {\bf size-in-bytes}. If adding data to a block would cause it to exceed + the given maximum size, the block will be written to the archive device, + and the new data will begin a new block. - If no value is specified or zero is specified, the Storage daemon will use a - default block size of 64,512 bytes (126 * 512). + If no value is specified or zero is specified, the Storage daemon will + use a default block size of 64,512 bytes (126 * 512). \item [Hardware End of Medium = {\it Yes|No}] \index[sd]{Hardware End of Medium } @@ -705,24 +729,25 @@ default, Bacula will only write one end of file to terminate the tape. \item [Maximum Volume Size = {\it size}] \index[sd]{Maximum Volume Size } - No more than {\bf size} bytes will be written onto a given volume on the - archive device. This directive is used mainly in testing Bacula to simulate a - small Volume. It can also be useful if you wish to limit the size of a File - Volume to say less than 2GB of data. In some rare cases of really antiquated - tape drives that do not properly indicate when the end of a tape is reached - during writing (though I have read about such drives, I have never personally - encountered one). Please note, this directive is deprecated (being phased - out) in favor of the {\bf Maximum Volume Bytes} defined in the Director's - configuration file. + No more than {\bf size} bytes will be written onto a given volume on the + archive device. This directive is used mainly in testing Bacula to + simulate a small Volume. It can also be useful if you wish to limit the + size of a File Volume to say less than 2GB of data. In some rare cases + of really antiquated tape drives that do not properly indicate when the + end of a tape is reached during writing (though I have read about such + drives, I have never personally encountered one). Please note, this + directive is deprecated (being phased out) in favor of the {\bf Maximum + Volume Bytes} defined in the Director's configuration file. \item [Maximum File Size = {\it size}] \index[sd]{Maximum File Size } - No more than {\bf size} bytes will be written into a given logical file on - the volume. Once this size is reached, an end of file mark is written on the - volume and subsequent data are written into the next file. Breaking long - sequences of data blocks with file marks permits quicker positioning to the - start of a given stream of data and can improve recovery from read errors on - the volume. The default is one Gigabyte. + No more than {\bf size} bytes will be written into a given logical file + on the volume. Once this size is reached, an end of file mark is + written on the volume and subsequent data are written into the next + file. Breaking long sequences of data blocks with file marks permits + quicker positioning to the start of a given stream of data and can + improve recovery from read errors on the volume. The default is one + Gigabyte. \item [Block Positioning = {\it yes|no}] \index[sd]{Block Positioning } diff --git a/docs/manual-de/version.tex b/docs/manual-de/version.tex index 2b9ec090..77539458 100644 --- a/docs/manual-de/version.tex +++ b/docs/manual-de/version.tex @@ -1 +1 @@ -1.38.3 (27 November 2005) +1.38.3 (11 December 2005) diff --git a/docs/manual/console.tex b/docs/manual/console.tex index 6b68dfc6..cfb28dd8 100644 --- a/docs/manual/console.tex +++ b/docs/manual/console.tex @@ -807,7 +807,8 @@ setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director | running jobs. The full form of this command is: status [all | dir=\lt{}dir-name\gt{} | director | - client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}] + client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{} | + days=nnn] If you do a {\bf status dir}, the console will list any currently running jobs, a summary of all jobs scheduled to be run in the next 24 @@ -842,6 +843,12 @@ status [all | dir=\lt{}dir-name\gt{} | director | JobId 2508 (MatouVerify) is waiting because only one job can run at a time, hence it is simply "waiting execution" + If you do a {\bf status dir}, it will by default list all jobs + that are scheduled in the next two days. If you wish to see + the jobs that are scheduled in the next 3 days (e.g. on Friday + you want to see wat tapes are scheduled to be used on Monday), you + can add the {\bf days=3} option. + \item [unmount] \index[console]{unmount} This command causes the indicated Bacula Storage daemon to unmount the diff --git a/docs/manual/restore.tex b/docs/manual/restore.tex index 79487cf9..4443d4c0 100644 --- a/docs/manual/restore.tex +++ b/docs/manual/restore.tex @@ -898,10 +898,6 @@ 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. \begin{description} -\item [Problem] - Your catalog has been damaged and Bacula either doesn't work or prints - errors. -\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. @@ -943,27 +939,25 @@ Priority: 10 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. You will then need to follow the instructions for your + database type to recreate the database from the ASCII backup file. \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 + 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} @@ -1010,19 +1004,16 @@ VolSessionTime=1114075126 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" @@ -1033,6 +1024,67 @@ VolBlock=0-4053 FileIndex=1-1 \end{verbatim} \normalsize + +\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 @@ -1076,16 +1128,12 @@ Volume "DLT-22Apr05" 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. + 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. + 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 @@ -1111,4 +1159,5 @@ Choose a query (1-15): \end{verbatim} \normalsize + \end{description} diff --git a/docs/manual/rpm-faq.tex b/docs/manual/rpm-faq.tex index ead5534a..1a68b3a5 100644 --- a/docs/manual/rpm-faq.tex +++ b/docs/manual/rpm-faq.tex @@ -192,12 +192,14 @@ The spec file currently supports building on the following platforms: \footnotesize \begin{verbatim} # RedHat builds +--define "build_rh7 1" --define "build_rh8 1" --define "build_rh9 1" # Fedora Core build --define "build_fc1 1" --define "build_fc3 1" +--define "build_fc4 1" # Whitebox Enterprise build --define "build_wb3 1" @@ -231,4 +233,3 @@ Sqlite support: \end{verbatim} \normalsize - diff --git a/docs/manual/security.tex b/docs/manual/security.tex index e48ab19e..3fd41a48 100644 --- a/docs/manual/security.tex +++ b/docs/manual/security.tex @@ -29,8 +29,8 @@ \item Currently all data that is sent across the network is unencrypted. As a consequence, unless you use {\bf ssh} or {\bf stunnel} for port forwarding, it is not recommended to do a backup across an insecure network (e.g. the -Internet). In a future version, we plan to have {\bf ssl} encryption -built-in. + Internet). In a future version, we plan to have {\bf ssl} encryption + built-in. \item You should ensure that the Bacula working directories are readable and writable only by the Bacula daemons. \item If you are using {\bf MySQL} it is not necessary for it to run with @@ -46,12 +46,52 @@ built-in. the respective daemon configuration files. \end{itemize} -\label{wrappers} -\subsection*{Configuring and Testing TCP Wrappers with Bacula} -\index[general]{Configuring and Testing TCP Wrappers with Bacula } -\addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers with -Bacula} +\subsection*{Backward Compatibility} +\index[general]{Backward Compatibility} +\addcontentsline{toc}{subsection}{Backward Compatibility} +One of the major goals of Bacula is to ensure that you can restore +tapes (I'll use the word tape to include disk Volumes) that you wrote years +ago. This means that each new version of Bacula should be able to read old +format tapes. The first problem you will have is to ensure that the +hardware is still working some years down the road, and the second +problem will be to ensure that the media will still be good, then +your OS must be able to interface to the device, and finally Bacula +must be able to recogize old formats. All the problems except the +last are ones that we cannot solve, but by careful planning you can. + +Since the very beginning of Bacula (January 2000) until today (December +2005), there have been two major Bacula tape formats. The second format +was introduced in version 1.27 in November of 2002, and it has not +changed since then. In principle, Bacula can still read the original +format, but I haven't tried it lately so who knows ... + +Though the tape format is fixed, the kinds of data that we can put on the +tapes are extensible, and that is how we added new features +such as ACLs, Win32 data, encrypted data, ... Obviously, an older +version of Bacula would not know how to read these newer data streams, +but each newer version of Bacula should know how to read all the +older streams. + +If you want to be 100% sure that you can read old tapes, you +should: + +1. Try reading old tapes from time to time -- e.g. at least once +a year. + +2. Keep statically linked copies of every version of Bacula that you use +in production then if for some reason, we botch up old tape compatibility, you +can always pull out an old copy of Bacula ... + +The second point is probably overkill but if you want to be sure, it may +save you someday. + + + +\label{wrappers} +subsection*{Configuring and Testing TCP Wrappers} +index[general]{Configuring and Testing TCP Wrappers} +addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers} TCP Wrappers are implemented if you turn them on when configuring ({\bf ./configure \verb:--:with-libwrap}). With this code enabled, you may control who may diff --git a/docs/manual/storedconf.tex b/docs/manual/storedconf.tex index 447b5719..435d9c40 100644 --- a/docs/manual/storedconf.tex +++ b/docs/manual/storedconf.tex @@ -438,26 +438,48 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface for reserving a drive for something special such as a high priority backup or restore operations. -\item [Maximum Changer Wait = {\it time}] - \index[sd]{Maximum Changer Wait } - This directive specifies the maximum time for Bacula to wait for an - autochanger to change the volume. If this time is exceeded, Bacula will - invalidate the Volume slot number stored in the catalog and try again. If no - additional changer volumes exist, Bacula will ask the operator to intervene. - The default time out is 5 minutes. +\item [Maximum Changer Wait = {\it seconds}] + \index[sd]{Maximum Changer Wait} + This directive specifies the maximum time in seconds for Bacula to wait + for an autochanger to change the volume. If this time is exceeded, + Bacula will invalidate the Volume slot number stored in the catalog and + try again. If no additional changer volumes exist, Bacula will ask the + operator to intervene. The default is 5 minutes. + + Please note that if you want to set your changer wait time to + 10 minutes, you must specify: + +\begin{verbatim} +Maximum Changer Wait = 600 +\end{verbatim} + + This directive will not accept qualifiers (such as "minutes"). + +\item [Maximum Rewind Wait = {\it seconds}] + \index[sd]{Maximum Rewind Wait} + This directive specifies the maximum time in seconds for Bacula to wait + for a rewind before timing out. If this time is exceeded, + Bacula will cancel the job. The default is 5 minutes. + +\item [Maximum Open Wait = {\it seconds}] + \index[sd]{Maximum Open Wait} + This directive specifies the maximum time in seconds for Bacula to wait + for a open before timing out. If this time is exceeded, + Bacula will cancel the job. The default is 5 minutes. \item [Always Open = {\it Yes|No}] \index[sd]{Always Open } - If {\bf Yes} (default), Bacula will always keep the device open unless - specifically {\bf unmounted} by the Console program. This permits Bacula to - ensure that the tape drive is always available. If you set {\bf AlwaysOpen} - to {\bf no} {\bf Bacula} will only open the drive when necessary, and at the - end of the Job if no other Jobs are using the drive, it will be freed. The - next time Bacula wants to append to a tape on a drive that was freed, Bacula - must rewind the tape and position to the end. To avoid unnecessary tape positioning - and to minimize unnecessary operator intervention, it is highly recommended that - {\bf Always Open = yes}. This also ensures that the drive is available when - Bacula needs it. + If {\bf Yes} (default), Bacula will always keep the device open unless + specifically {\bf unmounted} by the Console program. This permits + Bacula to ensure that the tape drive is always available. If you set + {\bf AlwaysOpen} to {\bf no} {\bf Bacula} will only open the drive when + necessary, and at the end of the Job if no other Jobs are using the + drive, it will be freed. The next time Bacula wants to append to a tape + on a drive that was freed, Bacula must rewind the tape and position to + the end. To avoid unnecessary tape positioning and to minimize + unnecessary operator intervention, it is highly recommended that {\bf + Always Open = yes}. This also ensures that the drive is available when + Bacula needs it. If you have {\bf Always Open = yes} (recommended) and you want to use the drive for something else, simply use the {\bf unmount} command in the Console @@ -503,12 +525,13 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface the drive on the next poll and automatically continue with the backup. Please see above more more details. -\item [Maximum Open Wait = {\it time}] +\item [Maximum Open Wait = {\it seconds}] \index[sd]{Maximum Open Wait } - This directive specifies the maximum amount of time that Bacula will wait for - a device that is busy. The default is 5 minutes. If the device cannot be - obtained, the current Job will be terminated in error. Bacula will re-attempt - to open the drive the next time a Job starts that needs the the drive. + This directive specifies the maximum amount of time in seconds that + Bacula will wait for a device that is busy. The default is 5 minutes. + If the device cannot be obtained, the current Job will be terminated in + error. Bacula will re-attempt to open the drive the next time a Job + starts that needs the the drive. \item [Removable media = {\it Yes|No}] \index[sd]{Removable media } @@ -524,22 +547,22 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface \item [Minimum block size = {\it size-in-bytes}] \index[sd]{Minimum block size } - On most modern tape drives, you will not need or wamt to specify this directive, and - if you do so, it will be to make Bacula use fixed block sizes. This - statement applies only to non-random access devices (e.g. tape drives). - Blocks written by the storage daemon to a non-random archive device will - never be smaller than the given {\bf size-in-bytes}. The Storage daemon will - attempt to efficiently fill blocks with data received from active sessions - but will, if necessary, add padding to a block to achieve the required - minimum size. + On most modern tape drives, you will not need or wamt to specify this + directive, and if you do so, it will be to make Bacula use fixed block + sizes. This statement applies only to non-random access devices (e.g. + tape drives). Blocks written by the storage daemon to a non-random + archive device will never be smaller than the given {\bf size-in-bytes}. + The Storage daemon will attempt to efficiently fill blocks with data + received from active sessions but will, if necessary, add padding to a + block to achieve the required minimum size. - To force the block size to be fixed, as is the case for some non-random - access devices (tape drives), set the {\bf Minimum block size} and the {\bf - Maximum block size} to the same value (zero included). The default is that - both the minimum and maximum block size are zero and the default block size - is 64,512 bytes. If you wish the block size to be fixed and different from - the default, specify the same value for both {\bf Minimum block size} and - {\bf Maximum block size}. + To force the block size to be fixed, as is the case for some non-random + access devices (tape drives), set the {\bf Minimum block size} and the + {\bf Maximum block size} to the same value (zero included). The default + is that both the minimum and maximum block size are zero and the default + block size is 64,512 bytes. If you wish the block size to be fixed and + different from the default, specify the same value for both {\bf Minimum + block size} and {\bf Maximum block size}. For example, suppose you want a fixed block size of 100K bytes, then you would specify: @@ -573,17 +596,18 @@ bacula-sd Alert: TapeAlert[32]: Interface: Problem with SCSI interface \item [Maximum block size = {\it size-in-bytes}] \index[sd]{Maximum block size } - On most modern tape drives, you will not need to specify this directive. If - you do so, it will most likely be to use fixed block sizes (see Minimum block - size above). The Storage daemon will aways attempt to write blocks of the - specified {\bf size-in-bytes} to the archive device. As a consequence, this - statement specifies both the default block size and the maximum block size. - The size written never exceed the given {\bf size-in-bytes}. If adding data - to a block would cause it to exceed the given maximum size, the block will be - written to the archive device, and the new data will begin a new block. + On most modern tape drives, you will not need to specify this directive. + If you do so, it will most likely be to use fixed block sizes (see + Minimum block size above). The Storage daemon will aways attempt to + write blocks of the specified {\bf size-in-bytes} to the archive device. + As a consequence, this statement specifies both the default block size + and the maximum block size. The size written never exceed the given + {\bf size-in-bytes}. If adding data to a block would cause it to exceed + the given maximum size, the block will be written to the archive device, + and the new data will begin a new block. - If no value is specified or zero is specified, the Storage daemon will use a - default block size of 64,512 bytes (126 * 512). + If no value is specified or zero is specified, the Storage daemon will + use a default block size of 64,512 bytes (126 * 512). \item [Hardware End of Medium = {\it Yes|No}] \index[sd]{Hardware End of Medium } @@ -705,24 +729,25 @@ default, Bacula will only write one end of file to terminate the tape. \item [Maximum Volume Size = {\it size}] \index[sd]{Maximum Volume Size } - No more than {\bf size} bytes will be written onto a given volume on the - archive device. This directive is used mainly in testing Bacula to simulate a - small Volume. It can also be useful if you wish to limit the size of a File - Volume to say less than 2GB of data. In some rare cases of really antiquated - tape drives that do not properly indicate when the end of a tape is reached - during writing (though I have read about such drives, I have never personally - encountered one). Please note, this directive is deprecated (being phased - out) in favor of the {\bf Maximum Volume Bytes} defined in the Director's - configuration file. + No more than {\bf size} bytes will be written onto a given volume on the + archive device. This directive is used mainly in testing Bacula to + simulate a small Volume. It can also be useful if you wish to limit the + size of a File Volume to say less than 2GB of data. In some rare cases + of really antiquated tape drives that do not properly indicate when the + end of a tape is reached during writing (though I have read about such + drives, I have never personally encountered one). Please note, this + directive is deprecated (being phased out) in favor of the {\bf Maximum + Volume Bytes} defined in the Director's configuration file. \item [Maximum File Size = {\it size}] \index[sd]{Maximum File Size } - No more than {\bf size} bytes will be written into a given logical file on - the volume. Once this size is reached, an end of file mark is written on the - volume and subsequent data are written into the next file. Breaking long - sequences of data blocks with file marks permits quicker positioning to the - start of a given stream of data and can improve recovery from read errors on - the volume. The default is one Gigabyte. + No more than {\bf size} bytes will be written into a given logical file + on the volume. Once this size is reached, an end of file mark is + written on the volume and subsequent data are written into the next + file. Breaking long sequences of data blocks with file marks permits + quicker positioning to the start of a given stream of data and can + improve recovery from read errors on the volume. The default is one + Gigabyte. \item [Block Positioning = {\it yes|no}] \index[sd]{Block Positioning } diff --git a/docs/manual/version.tex b/docs/manual/version.tex index 2b9ec090..77539458 100644 --- a/docs/manual/version.tex +++ b/docs/manual/version.tex @@ -1 +1 @@ -1.38.3 (27 November 2005) +1.38.3 (11 December 2005)