Final changes

[bacula/docs] / docs / manual / state.tex

%%
%%

\section*{The Current State of Bacula}
\label{_ChapterStart2}
\index[general]{Current State of Bacula }
\addcontentsline{toc}{section}{Current State of Bacula}

In other words, what is and what is not currently implemented and functional. 

\subsection*{What is Implemented}
\index[general]{Implemented!What}
\index[general]{What is Implemented}
\addcontentsline{toc}{subsection}{What is Implemented}

\begin{itemize}
\item Job Control
   \begin{itemize}
   \item Network backup/restore with centralized Director.  
   \item Internal scheduler for automatic 
      \ilink{Job}{JobDef} execution.  
   \item Scheduling of multiple Jobs at the same time.  
   \item You may run one Job at a time or multiple simultaneous Jobs.  
   \item Job sequencing using priorities.  
   \item \ilink{Console}{UADef} interface to the Director  allowing complete
      control. A shell, GNOME GUI and wxWidgets GUI versions of  the Console program
      are available. Note, the GNOME GUI program currently  offers very few
      additional features over the shell program. 
   \end{itemize}

\item Security
   \begin{itemize}
   \item Verification of files previously cataloged, permitting a Tripwire like 
      capability (system break-in detection).  
   \item CRAM-MD5 password authentication between each component (daemon).
   \item Configurable 
      \ilink{TLS (ssl) encryption}{_ChapterStart61} between each component.
   \item Computation of MD5 or SHA1 signatures of the file data if requested.  
   \end{itemize}


\item Restore Features
   \begin{itemize}
   \item Restore of one or more files selected interactively either for  the
      current backup or a backup prior to a specified time and date.  
   \item Restore of a complete system starting from bare  metal. This is mostly
      automated for Linux systems and  partially automated for Solaris. See 
      \ilink{Disaster Recovery Using Bacula}{_ChapterRescue}. This is also
      reported to work on Win2K/XP systems.  
   \item Listing and Restoration of files using stand-alone {\bf bls} and  {\bf
      bextract} tool programs. Among other things, this permits  extraction of files
      when Bacula and/or the catalog are not  available. Note, the recommended way
      to restore files is using  the restore command in the Console. These programs
      are designed  for use as a last resort. 
   \item Ability to recreate the catalog database by scanning backup Volumes 
      using the {\bf bscan} program.  
   \end{itemize}

\item SQL Catalog
   \begin{itemize}
   \item Catalog database facility for remembering Volumes, Pools, Jobs,  and
      Files backed up.  
   \item Support for SQLite, PostgreSQL, and MySQL Catalog databases.  
   \item User extensible queries to the SQLite, PostgreSQL and MySQL databases.  
   \end{itemize}

\item Advanced Volume and Pool Management
   \begin{itemize}
   \item Labeled Volumes, preventing accidental overwriting  (at least by
      Bacula).  
   \item Any number of Jobs and Clients can be backed up to a single  Volume.
      That is, you can backup and restore Linux, Unix, Sun, and  Windows machines to
      the same Volume.  
   \item Multi-volume saves. When a Volume is full, {\bf Bacula}  automatically
      requests the next Volume and continues the backup.  
   \item 
      \ilink{Pool and Volume}{PoolResource} library management 
      providing Volume flexibility (e.g. monthly, weekly, daily Volume sets,  Volume
      sets segregated by Client, ...). 
   \item Machine independent Volume data format. Linux, Solaris, and Windows 
      clients can all be backed up to the same Volume if desired. 
   \item A flexible 
      \ilink{ message}{MessageResource}  handler including routing
      of messages from any daemon back to the  Director and automatic email
      reporting.  
   \item Data spooling to disk during backup with subsequent write to tape from
      the spooled disk files. This prevents tape "shoe shine"  during
      Incremental/Differential backups.  
   \end{itemize}

\item Advanced Support for most Storage Devices
    \begin{itemize}
   \item Autochanger support using a simple shell interface that can interface 
      to virtually any autoloader program. A script for {\bf mtx} is  provided.  
   \item Support for autochanger barcodes -- automatic tape labeling from 
      barcodes.  
   \item Automatic support for multiple autochanger magazines either using
      barcodes or by reading the tapes.  
   \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 Multi-Operating System Support
   \begin{itemize} 
   \item Programmed to handle arbitrarily long filenames and messages.  
   \item GZIP compression on a file by file basis done by the Client program  if
      requested before network transit.  
   \item Saves and restores POSIX ACLs on most OSes if enabled.  
   \item Access control lists for Consoles that permit restricting user access
      to only their data.  
   \item Support for save/restore of files larger than 2GB.  
   \item Support for 64 bit machines, e.g. amd64.  
   \item Ability to encrypt communications between daemons using stunnel. 
   \item Support ANSI and IBM tape labels.
   \item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
         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).
   \end{itemize}

\item Miscellaneous
   \begin{itemize}
   \item Multi-threaded implementation.  
   \item A comprehensive and extensible 
      \ilink{configuration file}{_ChapterStart40} for each daemon.  
   \end{itemize}
\end{itemize}

\subsection*{Advantages of Bacula Over Other Backup Programs}
\index[general]{Advantages of Bacula Over Other Backup Programs }
\index[general]{Programs!Advantages of Bacula Over Other Backup }
\addcontentsline{toc}{subsection}{Advantages of Bacula Over Other Backup
   Programs}

\begin{itemize}
\item Since there is a client for each machine, you can backup
   and restore clients of any type ensuring that all attributes
   of files are properly saved and restored.
\item It is also possible to backup clients without any client
   software by using NFS or Samba.  However, if possible, we
   recommend running a Client File daemon on each machine to be
   backed up.
\item Bacula handles multi-volume backups.  
\item A full comprehensive SQL standard database of all files backed up.  This
   permits online viewing of files saved on any particular  Volume.  
\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.  
\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
   native tools of the system, backed up, then restarted (all
   within a Bacula Job).
\item Bacula has a built-in Job scheduler.  
\item The Volume format is documented and there are simple C programs to 
   read/write it.  
\item Bacula uses well defined (IANA registered) TCP/IP ports -- no rpcs,  no
   shared memory.  
\item Bacula installation and configuration is relatively simple compared  to
   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
   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.  
\item Aside from a GUI administrative interface, Bacula has a
   comprehensive shell administrative interface, which allows the
   administrator to use tools such as ssh to administrate any part of
   Bacula from anywhere (even from home).
\item Bacula has a Rescue CD for Linux systems with the following features:  
   \begin{itemize}
   \item You build it on your own system from scratch with one simple  command:
      make -- well, then make burn. 
   \item It uses your kernel  
   \item It captures your current disk parameters and builds scripts that  allow
      you to automatically repartition a disk and format it to  put it back to what
      you had before. 
   \item It has a script that will restart your networking (with the right  IP
      address)  
   \item It has a script to automatically mount your hard disks.  
   \item It has a full Bacula FD statically linked  
   \item You can easily add additional data/programs, ... to the disk.  
   \end{itemize}

\end{itemize}

\subsection*{Current Implementation Restrictions}
\index[general]{Current Implementation Restrictions }
\index[general]{Restrictions!Current Implementation }
\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.  
\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.
\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}
\index[general]{Restrictions!Design Limitations or }
\index[general]{Design Limitations or Restrictions }
\addcontentsline{toc}{subsection}{Design Limitations or Restrictions}

\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.
\end{itemize}