From cacf6c2054bd220317c620f64101e1f9f004250f Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Mon, 7 Aug 2006 09:21:51 +0000 Subject: [PATCH] Updates --- docs/manual-fr/imagename_translations | 36 ++++----- docs/manual/critical.tex | 2 +- docs/manual/dirdconf.tex | 7 +- docs/manual/migration.tex | 105 ++++++++++++++++++++++++++ docs/manual/progs.tex | 4 + docs/manual/state.tex | 50 +++++------- 6 files changed, 152 insertions(+), 52 deletions(-) create mode 100644 docs/manual/migration.tex diff --git a/docs/manual-fr/imagename_translations b/docs/manual-fr/imagename_translations index 04daf098..01f53302 100644 --- a/docs/manual-fr/imagename_translations +++ b/docs/manual-fr/imagename_translations @@ -1,27 +1,27 @@ +img19.png./idle.eps img6.png./Conf-Diagram.eps -img11.png./win32-nsis.eps +img25.png./view-only.eps +img12.png./win32-welcome.eps img3.png./bacula-objects.eps -img1.png./bacula-logo.eps -img24.png./access-is-denied.eps +img16.png./win32-service-ok.eps +img9.png./bimagemgr2.eps +img27.png./properties-security-advanced-owner.eps +img15.png./win32-service.eps img2.png./bacula-applications.eps -img5.png./Bacula-tray-monitor.eps -img23.png./error.eps img14.png./win32-location.eps -img12.png./win32-welcome.eps -img10.png./bimagemgr3.eps -img20.png./tray-icon.eps -img27.png./properties-security-advanced-owner.eps img8.png./bimagemgr1.eps -img19.png./idle.eps -img22.png./running.eps -img13.png./win32-pkg.eps +img23.png./error.eps +img11.png./win32-nsis.eps +img24.png./access-is-denied.eps +img5.png./Bacula-tray-monitor.eps +img10.png./bimagemgr3.eps +img18.png./win32-finish.eps img26.png./properties-security.eps img17.png./win32-start.eps -img18.png./win32-finish.eps -img28.png./confirm.eps -img9.png./bimagemgr2.eps -img16.png./win32-service-ok.eps -img25.png./view-only.eps img4.png./flow.eps -img15.png./win32-service.eps img21.png./menu.eps +img28.png./confirm.eps +img1.png./bacula-logo.eps +img13.png./win32-pkg.eps +img20.png./tray-icon.eps +img22.png./running.eps diff --git a/docs/manual/critical.tex b/docs/manual/critical.tex index c299db88..c62233d5 100644 --- a/docs/manual/critical.tex +++ b/docs/manual/critical.tex @@ -92,7 +92,7 @@ you avoid problems. through the examples in the \ilink{Tutorial}{_ChapterStart1} chapter of this manual. \item Learn what each of the \ilink{Bacula Utility Programs}{_UtilityChapter} -does. + does. \item Set up reasonable retention periods so that your catalog does not grow to be too big. See the following three chapters:\\ \ilink{Recycling your Volumes}{_ChapterStart22},\\ diff --git a/docs/manual/dirdconf.tex b/docs/manual/dirdconf.tex index 628a3891..98105469 100644 --- a/docs/manual/dirdconf.tex +++ b/docs/manual/dirdconf.tex @@ -870,7 +870,8 @@ For a {\bf Verify} Job, the Level may be one of the following: The specified {\bf command} is run as an external program prior or after the current Job. This directive is optional. - You can use following options : + You can use following options:\\ + \begin{tabular}{|c|c|c|l} Options & Value & Default & Informations \\ \hline @@ -889,6 +890,7 @@ Abort Job On Error & Yes/No & {\it Yes} & Abort job if script return Command & & & Path to your script\\ \hline \end{tabular} + \\ Any output sent by the command to standard output will be included in the Bacula job report. The command string must be a valid program name or name @@ -936,7 +938,8 @@ The Job Exit Status code \%e edits the following values: it within some sort of quotes. -You can use these following shortcuts : +You can use these following shortcuts:\\ + \begin{tabular}{|c|c|c|c|c|c} Keyword & RunsOnSuccess & RunsOnFailure & AbortJobOnError & Runs On Client & RunsWhen \\ \hline diff --git a/docs/manual/migration.tex b/docs/manual/migration.tex new file mode 100644 index 00000000..30dee543 --- /dev/null +++ b/docs/manual/migration.tex @@ -0,0 +1,105 @@ + +\section*{Migration} +\label{_MigrationChapter} +\index[general]{Migration} +\addcontentsline{toc}{section}{Migration} + +The term Migration as used in the context of Bacula means moving data from one +Volume to another, and in particular it is +a Job (similar to a backup job) that reads data that was previously +backed up to a Volume and writes it to another Volume purging the +catalog records associated with the first backup job. In other words, +Migration moves Bacula Job data from one Volume to another. Although we +mention Volumes, in reality, Migration is based on moving individual Jobs from +one Pool to another. + +Migrations can be based on quite a number of different criteria such as: +a single previous Job; a Volume; a Client; a regular expression matching +a Job, Volume, or Client name; the time a Job is on a Volume; high +and low water marks (usage or occupation) of a Pool; Volume size, ... +The details of these selection criteria will be defined below. + + +To run a Migration job, you must have defined a Job resource very similar +to a Backup Job but with {\bf Type = Migrate} instead of {\bf Type = +Backup}. The migration job then starts much like a backup job starts and +searches for a previous backup Job or Jobs that matches the parameters you have +specified in the migration Job resource (detailed a bit later). Then +for each previous backup Job found, the Migration Job will run a new +Job which copies the old Job data from the previous Volume to a new +Volume defined in the Migration Pool. It is possible that no prior +Jobs are found for migration, in which case, the Migration job will +simply terminate having done nothing, but normally at a minimum, three jobs +are involved during a migration: + +\begin{itemize} +\item The currently running Migration Job +\item The previous Backup Job +\item A new Backup Job that writes the previous data to + the new Volume. +\end{itemize} + +If the Migration is for a particular Volume, multiple new Backup Jobs +may be started, one for each Job on the Volume. + + + +\subsection*{Migration Job Resource Directives} +\addcontentsline{toc}{section}{Migration Job Resource Directives} + +The following directives can appear in a Director's Job resource, and they +are used to define a Migration job. + +\begin{description} +\item [Type = Migrate] +This defines the job that is run as being a Migration Job. +Migration Jobs do not have any Files associated with them, and in +that sense they are more or less like an Admin job. They just +check to see if there is anything to Migrate then possibly start +and control new Backup jobs to move the data. + +\item [Selection Type = \lt{}Selection-type-keyword\gt{}] + Where \lt{}Selection-type-keyword\gt{} can be: + \begin{description} + \item [SmallestVolume] This selection keyword selects the smallest volume in + the Pool to be migrated. + \item [OldestVolume] This selection keyword selects the oldest volume in + the Pool to be migrated. + \item [Client] + \item [Volume] + \item [Job] + \item [SQLQuery] + \item [PoolOccupancy] Not yet implemented. + \item [PoolTime] Not yet implemented. + \end{description} +\end{description} + + +\item [Selection Pattern = \lt{}Quoted-string\gt{}] +The Selection Patterns permitted for each Selection-type-keyword +are described above. + +\end{description} + +\subsection*{Migration Pool Resource Directives} +\addcontentsline{toc}{section}{Migration Pool Resource Directives} + +The following directives can appear in a Director's Pool resource, and they +are used to define a Migration job. + +\begin{description} +\item [Migration Time = \lt{}time-specification\gt{}] +If a PoolTime migration is done, the time specified here in seconds (time +modifiers are permitted -- e.g. hours, ...) will be used. If the +previous Backup Job or Jobs selected have been in the Pool longer than +the specified PoolTime, then they will be migrated. + +\item [Migration High Bytes = \lt{}byte-specification\gt{}] + +\item [Migration Low Bytes = \lt{}byte-specification\gt{}] + +\item [Next Pool = \lt{}pool-specification\gt{}] + +\item [Storage = \lt{}storage-specification\gt{}] + +\end{description} diff --git a/docs/manual/progs.tex b/docs/manual/progs.tex index d877cf62..1b9fdc98 100644 --- a/docs/manual/progs.tex +++ b/docs/manual/progs.tex @@ -447,6 +447,10 @@ The {\bf bscan} program can be used to re-create a database (catalog) from the backup information written to one or more Volumes. This is normally needed only if one or more Volumes have been pruned or purged from your catalog so that the records on the Volume are no longer in the catalog. +If you find yourself using this program, you have probably done something +wrong. For example, the best way to recover a lost or damaged Bacula +database is to reload the database from using the bootstrap file that +was written when you saved it. With some care, it can also be used to synchronize your existing catalog with a Volume. Although we have never seen a case of bscan damaging a diff --git a/docs/manual/state.tex b/docs/manual/state.tex index 95e2bd79..fbe1ab74 100644 --- a/docs/manual/state.tex +++ b/docs/manual/state.tex @@ -34,7 +34,8 @@ In other words, what is and what is not currently implemented and functional. capability (system break-in detection). \item CRAM-MD5 password authentication between each component (daemon). \item Configurable - \ilink{TLS (ssl) encryption}{_ChapterStart61} between each component. + \ilink{TLS (ssl) communications encryption}{_ChapterStart61} between each component. + \item Data (on Volume) encryption on a Client by Client basis. \item Computation of MD5 or SHA1 signatures of the file data if requested. \end{itemize} @@ -99,7 +100,9 @@ In other words, what is and what is not currently implemented and functional. \item Support for multiple drive autochangers. \item Raw device backup/restore. Restore must be to the same device. \item All Volume blocks (approx 64K bytes) contain a data checksum. - \end{itemize} + \item Migration support -- move data from one Pool to another or + one Volume to another. + \end{itemize} \item Multi-Operating System Support \begin{itemize} @@ -117,6 +120,8 @@ In other words, what is and what is not currently implemented and functional. version 1.37.28 and greater. \item Consistent backup of open files on Win32 systems (WinXP, Win2003), but not Win2000, using Volume Shadow Copy (VSS). + \item Support for path/filename lengths of up to 64K on Win32 machines + (unlimited on Unix/Linux machines). \end{itemize} \item Miscellaneous @@ -147,6 +152,7 @@ In other words, what is and what is not currently implemented and functional. \item Automatic pruning of the database (removal of old records) thus simplifying database administration. \item Any SQL database engine can be used making Bacula very flexible. + Drivers currently exist for MySQL, PostgreSQL, and SQLite. \item The modular but integrated design makes Bacula very scalable. \item Since Bacula uses client file servers, any database or other application can be properly shutdown by Bacula using the @@ -161,7 +167,7 @@ In other words, what is and what is not currently implemented and functional. other comparable products. \item According to one user Bacula is as fast as the big major commercial applications. -\item According to another user Bacula is four times as fast as another +\item According to another user Bacula is four times as fast as another commercial application, probably because that application stores its catalog information in a large number of individual files rather than an SQL database as Bacula does. @@ -192,37 +198,22 @@ In other words, what is and what is not currently implemented and functional. \addcontentsline{toc}{subsection}{Current Implementation Restrictions} \begin{itemize} -\item Path and filenames longer than 260 characters on Win32 systems are - not supported. They will be backed up, but they cannot be restored. By - using the {\bf Portable=yes} directive in your FileSet, files with - long names can be restored to Unix and Linux systems. - Long filenames for Win32 will be implemented in version 1.40. \item If you have over 4 billion file entries stored in your database, the database FileId is likely to overflow. This is a monster database, but still - possible. At some point, Bacula's FileId fields will be upgraded from 32 bits - to 64 bits and this problem will go away. In the mean time, a good workaround - is to use multiple databases. -\item Files deleted after a Full save will be included in a restoration. + possible. Bacula's FileId fields have been modified so that they can be + upgraded from 32 to 64 bits in version 1.39, but this has never been + tested. +\item Files deleted after a Full save will be included in a restoration. This + is typical for most similar backup programs (we have a project to + correct this). \item Bacula's Differential and Incremental backups are based on time stamps. Consequently, if you move files into an existing directory or move a whole directory into the backup fileset after a Full backup, those files will probably not be backed up by an Incremental save because they will have old dates. You must explicitly update the date/time stamp on all - moved files. Correcting this is a future project. + moved files (we have a project to correct this). \item File System Modules (configurable routines for saving/restoring special files) are not yet implemented. -\item Data encryption of the Volume contents. Bacula version 1.40 - will have this feature. -\item Bacula cannot automatically restore files for a single Job - from two or more different storage devices or different media types. - That is, if you use more than one storage device or media type to - backup a single job, the restore process will require some manual - intervention. -\item Bacula does not currently support removable disk Volumes. - Some users seem to have it working, but you must take care to - have the correct volume mounted, and restores spanning removable - disk volumes are not likely to work. It is planned that Bacula - 1.40 will have this feature. \end{itemize} \subsection*{Design Limitations or Restrictions} @@ -232,10 +223,7 @@ In other words, what is and what is not currently implemented and functional. \begin{itemize} \item Names (resource names, Volume names, and such) defined in Bacula - configuration files are limited to a fixed number of characters. Currently - the limit is defined as 127 characters. Note, this does not apply to - filenames, which may be arbitrarily long. -\item On Win32 machines filenames are limited by the non-Unicode Windows - API that we use to 260 characters. This is corrected in - version 1.39 and later by switching to the Unicode API. + configuration files are limited to a fixed number of + characters. Currently the limit is defined as 127 characters. Note, + this does not apply to filenames, which may be arbitrarily long. \end{itemize} -- 2.39.5