From: Kern Sibbald Date: Mon, 21 Dec 2009 15:05:07 +0000 (+0100) Subject: Update state X-Git-Tag: Release-5.0.0~35 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=917ae3e308275514d71468d165032a43347a5c64;p=bacula%2Fdocs Update state --- diff --git a/docs/manuals/en/main/state.tex b/docs/manuals/en/main/state.tex index 4d954b87..c9291aa5 100644 --- a/docs/manuals/en/main/state.tex +++ b/docs/manuals/en/main/state.tex @@ -203,33 +203,22 @@ In other words, what is and what is not currently implemented and functional. \index[general]{Restrictions!Current Implementation } \begin{itemize} -\item Bacula's Differential and Incremental \textsl{normal} 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 run backups in Accurate mode or explicitly update - the date/time stamp on all moved files. % TODO: remove it ? -\item File System Modules (configurable routines for - saving/restoring special files) are not yet implemented. However, - this feature is easily implemented using RunScripts. -\item Bacula cannot restore two different jobs in the same - restore if those jobs were run simultaneously, unless you had +\item It is very unusual to attempt to restore two Jobs + that ran simultaneously in a single restore, but if + you do, please be aware that unless you had data spooling turned on and the spool file held the full - contents of both jobs. In other terms, Bacula cannot restore - two jobs in the same restore if the jobs' data blocks were - intermixed on the backup medium. This poses no restrictions - for normal backup jobs even if they are run simultaneously. -\item Bacula can generally restore any backup made from a client + contents of both Jobs during the backup, the restore will not + work correctly. In other terms, Bacula cannot restore + two jobs in the same restore if the Jobs' data blocks were + intermixed on the backup medium. The problem is resolved by + simply doing two restores, one for each Job. +\item Bacula can generally restore any backup made from one client to any other client. However, if the architecture is significantly different (i.e. 32 bit architecture to 64 bit or Win32 to Unix), some restrictions may apply (e.g. Solaris door files do not exist on other Unix/Linux machines; there are reports that Zlib compression written with 64 bit machines does not always read correctly on a 32 bit machine). -\item In older version of Bacula ($<=$ 3.x), if you have over 4 billion file - entries stored in your database, the database FileId is likely to overflow. -\item In non \textsl{Accurate} mode, files deleted after a Full save will be - included in a restoration. This is typical for most similar backup programs. \end{itemize} \section{Design Limitations or Restrictions} @@ -244,3 +233,18 @@ In other words, what is and what is not currently implemented and functional. \item Command line input to some of the stand alone tools -- e.g. btape, bconsole is restricted to several hundred characters maximum. \end{itemize} + +\section{Items to Note} +\index[general]{Items to Note} +\begin{itemize} +\item Bacula's Differential and Incremental \textsl{normal} 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. This problem is corrected by using Accurate mode backups + or by explicitly updating the date/time stamp on all moved files. +\item In older versions of Bacula ($<=$ 3.0.x), if you have over 4 billion file + entries stored in your database, the database FileId is likely to overflow. +\item In non \textsl{Accurate} mode, files deleted after a Full save will be + included in a restoration. This is typical for most similar backup programs. +\end{itemize}