From: Kern Sibbald Date: Sat, 23 Jun 2007 12:52:10 +0000 (+0000) Subject: Tweaks + review disk pool example chapter X-Git-Tag: Release-2.2.0~239 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=28c3a3bd5cfe833fefc00a57f90818d2d32ccc7c;p=bacula%2Fdocs Tweaks + review disk pool example chapter --- diff --git a/docs/developers/version.tex b/docs/developers/version.tex index 989f0e2f..332323bc 100644 --- a/docs/developers/version.tex +++ b/docs/developers/version.tex @@ -1 +1 @@ -2.1.19 (18 June 2007) +2.1.21 (23 June 2007) diff --git a/docs/manual-de/version.tex b/docs/manual-de/version.tex index 989f0e2f..332323bc 100644 --- a/docs/manual-de/version.tex +++ b/docs/manual-de/version.tex @@ -1 +1 @@ -2.1.19 (18 June 2007) +2.1.21 (23 June 2007) diff --git a/docs/manual/pools.tex b/docs/manual/pools.tex index 250778e6..39966485 100644 --- a/docs/manual/pools.tex +++ b/docs/manual/pools.tex @@ -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 diff --git a/docs/manual/restore.tex b/docs/manual/restore.tex index c952f2ba..1f3a7e2b 100644 --- a/docs/manual/restore.tex +++ b/docs/manual/restore.tex @@ -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 diff --git a/docs/manual/tls.tex b/docs/manual/tls.tex index 32fdc9b8..c5068d1a 100644 --- a/docs/manual/tls.tex +++ b/docs/manual/tls.tex @@ -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 diff --git a/docs/manual/version.tex b/docs/manual/version.tex index 989f0e2f..332323bc 100644 --- a/docs/manual/version.tex +++ b/docs/manual/version.tex @@ -1 +1 @@ -2.1.19 (18 June 2007) +2.1.21 (23 June 2007)