]> git.sur5r.net Git - bacula/docs/commitdiff
Tweaks + review disk pool example chapter
authorKern Sibbald <kern@sibbald.com>
Sat, 23 Jun 2007 12:52:10 +0000 (12:52 +0000)
committerKern Sibbald <kern@sibbald.com>
Sat, 23 Jun 2007 12:52:10 +0000 (12:52 +0000)
docs/developers/version.tex
docs/manual-de/version.tex
docs/manual/pools.tex
docs/manual/restore.tex
docs/manual/tls.tex
docs/manual/version.tex

index 989f0e2fa39e228a2dde408c0e1e12a4bb3e26c1..332323bcef8a151a2f4a647f62fc87280c922229 100644 (file)
@@ -1 +1 @@
-2.1.19 (18 June 2007)
+2.1.21 (23 June 2007)
index 989f0e2fa39e228a2dde408c0e1e12a4bb3e26c1..332323bcef8a151a2f4a647f62fc87280c922229 100644 (file)
@@ -1 +1 @@
-2.1.19 (18 June 2007)
+2.1.21 (23 June 2007)
index 250778e616fbc4bc6855bfe2dc750a2e0d69e136..399664853fd30834a949700eff1538b8774ba829 100644 (file)
@@ -26,8 +26,8 @@ drive that was failing. The exact reason for the failure is still unknown.
 Worse yet, their full backup size is about 15GB whereas the capacity of their
 broken DDS-3 was at best 8GB (rated 6/12). A new DDS-4 tape drive and the
 necessary cassettes was more expensive than their budget could handle. 
-\label{TheSolution}
 
+\label{TheSolution}
 \section{The Solution}
 \index[general]{Solution}
 
@@ -45,11 +45,10 @@ less than 1/10th the price of a tape drive and the cassettes to handle the
 same amount of data, and to have Bacula write to disk files. 
 
 The rest of this chapter will explain how to setup Bacula so that it would
-automatically manage a set of disk files with the minimum intervention on my
-part. The system has been running since 22 January 2004 until today (17
-September 2006) with no intervention, with the exception that I had to
-% TODO: is this relevant for book? rewrite this part?
-add a second 120GB hard disk after a year because their needs grew
+automatically manage a set of disk files with the minimum sysadmin
+intervention. The system has been running since 22 January 2004 until today
+(23 June 2007) with no intervention, with the exception of adding 
+a second 120GB hard disk after a year because their needs grew
 over that time to more than the 120GB (168GB to be exact).  The only other
 intervention I have made is a periodic (about once a year) Bacula upgrade.
 
@@ -72,8 +71,8 @@ the use of tape Volumes if your tape fills. Being a hard disk and the only one
 you have, this will be a bit of a problem. It should be obvious that it is
 better to use a number of smaller Volumes and arrange for Bacula to
 automatically recycle them so that the disk storage space can be reused. The
-other problem with a single Volume, is that at the current time (1.34.0)
-Bacula does not seek within a disk Volume, so restoring a single file can take
+other problem with a single Volume, is that until version 2.0.0,
+Bacula did not seek within a disk Volume, so restoring a single file can take
 more time than one would expect. 
 
 As mentioned, the solution is to have multiple Volumes, or files on the disk.
@@ -82,7 +81,10 @@ time, by number of jobs, or by size. Any of these would work, but we chose to
 limit the use of a single Volume by putting a single job in each Volume with
 the exception of Volumes containing Incremental backup where there will be 6
 jobs (a week's worth of data) per volume. The details of this will be
-discussed shortly. 
+discussed shortly.  This is a single client backup, so if you have multiple
+clients you will need to multiply those numbers by the number of clients,
+or use a different system for switching volumes, such as limiting the
+volume size.
 
 The next problem to resolve is recycling of Volumes. As you noted from above,
 the requirements are to be able to restore monthly for 6 months, weekly for a
@@ -95,8 +97,8 @@ have a separate Pool for each backup type.
 The decision was to use three Pools: one for Full saves, one for Differential
 saves, and one for Incremental saves, and each would have a different number
 of volumes and a different Retention period to accomplish the requirements. 
-\label{FullPool}
 
+\label{FullPool}
 \subsection{Full Pool}
 \index[general]{Pool!Full}
 \index[general]{Full Pool}
@@ -114,7 +116,7 @@ Pool {
   Volume Retention = 6 months
   Maximum Volume Jobs = 1
   Label Format = Full-
-  Maximum Volumes = 6
+  Maximum Volumes = 9
 }
 \end{verbatim}
 \normalsize
@@ -124,9 +126,19 @@ each backup (done once a month in this case). The items to note are the
 retention period of six months (i.e. they are recycled after six months), that
 there is one job per volume (Maximum Volume Jobs = 1), the volumes will be
 labeled Full-0001, ... Full-0006 automatically. One could have labeled these
-manual from the start, but why not use the features of Bacula. 
-\label{DiffPool}
+manually from the start, but why not use the features of Bacula. 
 
+Six months after the first volume is used, it will be subject to pruning
+and thus recycling, so with a maximum of 9 volumes, there should always be
+3 volumes available (note, they may all be marked used, but they will be
+marked purged and recycled as needed).
+
+If you have two clients, you would want to set {\bf Maximum Volume Jobs} to
+2 instead of one, or set a limit on the size of the Volumes, and possibly 
+increase the maximum number of Volumes.
+
+
+\label{DiffPool}
 \subsection{Differential Pool}
 \index[general]{Pool!Differential}
 \index[general]{Differential Pool}
@@ -145,17 +157,24 @@ Pool {
   Volume Retention = 40 days
   Maximum Volume Jobs = 1
   Label Format = Diff-
-  Maximum Volumes = 6
+  Maximum Volumes = 10
 }
 \end{verbatim}
 \normalsize
 
-As you can see, the Differential Pool can grow to a maximum of six volumes,
+As you can see, the Differential Pool can grow to a maximum of 9 volumes,
 and the Volumes are retained 40 days and thereafter they can be recycled. Finally
 there is one job per volume. This, of course, could be tightened up a lot, but
 the expense here is a few GB which is not too serious. 
-\label{IncPool}
 
+If a new volume is used every week, after 40 days, one will have used 7
+volumes, and there should then always be 3 volumes that can be purged and
+recycled.
+
+See the discussion above concering the Full pool for how to handle multiple
+clients.
+
+\label{IncPool}
 \subsection{Incremental Pool}
 \index[general]{Incremental Pool}
 \index[general]{Pool!Incremental}
@@ -172,7 +191,7 @@ Pool {
   Volume Retention = 20 days
   Maximum Volume Jobs = 6
   Label Format = Inc-
-  Maximum Volumes = 5
+  Maximum Volumes = 7
 }
 \end{verbatim}
 \normalsize
@@ -184,8 +203,16 @@ be set to just a bit more than a week and keep only two or three volumes
 instead of five. Again, the lost is very little and as the system reaches the
 full steady state, we can adjust these values so that the total disk usage
 doesn't exceed the disk capacity. 
-\label{Example}
 
+If you have two clients, the simplest thing to do is to increase the
+maximum volume jobs from 6 to 12. As mentioned above, it is also possible
+limit the size of the volumes.  However, in that case, you will need to
+have a better idea of the volume or add sufficient volumes to the pool so
+that you will be assured that in the next cycle (after 20 days) there is
+at least one volume that is pruned and can be recycled.
+
+
+\label{Example}
 \section{The Actual Conf Files}
 \index[general]{Files!Actual Conf}
 \index[general]{Actual Conf Files}
@@ -329,7 +356,7 @@ Pool {
   Volume Retention = 6 months
   Maximum Volume Jobs = 1
   Label Format = Full-
-  Maximum Volumes = 8
+  Maximum Volumes = 9
 }
 
 Pool {
@@ -337,10 +364,10 @@ Pool {
   Pool Type = Backup
   Recycle = yes           # automatically recycle Volumes
   AutoPrune = yes         # Prune expired volumes
-  Volume Retention = 14 days
+  Volume Retention = 20 days
   Maximum Volume Jobs = 6
   Label Format = Inc-
-  Maximum Volumes = 6
+  Maximum Volumes = 7
 }
 
 Pool {
@@ -348,7 +375,7 @@ Pool {
   Pool Type = Backup
   Recycle = yes
   AutoPrune = yes
-  Volume Retention = 35 days
+  Volume Retention = 40 days
   Maximum Volume Jobs = 1
   Label Format = Diff-
   Maximum Volumes = 10
index c952f2ba343df5667b144bc81658c28ad86445ac..1f3a7e2bdef5c55ccbdf73c6a7a3a4e31e394bb0 100644 (file)
@@ -595,15 +595,6 @@ The full list of possible command line arguments are:
 \item {\bf where=/tmp/bacula-restore} -- restore files in {\bf where} directory.
 \item {\bf yes} -- automatically run the restore without prompting  for
    modifications (most useful in batch scripts). 
-\end{itemize}
-
-\label{restorefilerelocation}
-You can also do filename and path manipulations, implemented in Bacula
-2.1.8 or later, such as adding a suffix to all your files, renaming files
-or directories, etc.  Theses options will overwrite {\bf where=} option.
-See the next section for more information and examples.
-
-\begin{itemize}
 \item {\bf strip\_prefix=/prod} -- remove a part of the filename when restoring.
 \item {\bf add\_prefix=/test} -- add a prefix to all files when restoring (like
   where) (can't be used with {\bf where=}).
@@ -612,6 +603,7 @@ See the next section for more information and examples.
   like with sed unix command. Will overwrite other filename manipulation.
 \end{itemize}
 
+\label{restorefilerelocation}
 \section{Using File Relocation}
 \index[general]{Using File Relocation}
 \label{filerelocation}
@@ -622,6 +614,11 @@ The \textbf{where=} option is simple, but not very powerful. With file
 relocation, Bacula can restore a file to the same directory, but with a
 different name, or in an other directory without recreating the full path.
 
+You can also do filename and path manipulations, implemented in Bacula
+2.1.8 or later, such as adding a suffix to all your files, renaming files
+or directories, etc.  Theses options will overwrite {\bf where=} option.
+
+
 For example, many users use OS snapshot features so that file
 \texttt{/home/eric/mbox} will be backed up from the directory
 \texttt{/.snap/home/eric/mbox}, which can complicate restores.  If you use
index 32fdc9b8582566456cb57ce34d3e1d8edb04084e..c5068d1a62d7df0f2c5be3e1e8aaa7348c06bf2c 100644 (file)
@@ -56,16 +56,17 @@ Bacula will connect with other daemons either with or without TLS depending
 on what the other daemon requests.  If TLS is enabled and TLS is required,
 then Bacula will refuse any connection that does not use TLS.
 
-\item [TLS Certificate = \lt{}Directory\gt{}]
-Path to a PEM encoded TLS certificate.  It can be used as either a client
-or server certificate. PEM stands for Privacy Enhanced Mail, but in 
-this context refers to how the certificates are encoded. It is used
-because PEM files are base64 encoded and hence ASCII text based
-rather than binary. They may also contain encrypted information.
-
-\item [TLS Key = \lt{}Directory\gt{}]
-Path to a PEM encoded TLS private key.  It must correspond to the TLS
-certificate.
+\item [TLS Certificate = \lt{}Filename\gt{}]
+The full path and filename of a PEM encoded TLS certificate.  It can be
+used as either a client or server certificate.  PEM stands for Privacy
+Enhanced Mail, but in this context refers to how the certificates are
+encoded.  It is used because PEM files are base64 encoded and hence ASCII
+text based rather than binary.  They may also contain encrypted
+information.
+
+\item [TLS Key = \lt{}Filename\gt{}]
+The full path and filename of a PEM encoded TLS private key.  It must
+correspond to the TLS certificate.
 
 \item [TLS Verify Peer = \lt{}yes|no\gt{}]
 Verify peer certificate.  Instructs server to request and verify the
index 989f0e2fa39e228a2dde408c0e1e12a4bb3e26c1..332323bcef8a151a2f4a647f62fc87280c922229 100644 (file)
@@ -1 +1 @@
-2.1.19 (18 June 2007)
+2.1.21 (23 June 2007)