Bacula 1.30 User's Guide | Chapter

Storage Daemon Design | Index | Bacula Catalog Services

# File Services Daemon

### General

Please note, this section is somewhat out of date as the code has evolved significantly. The basic idea has not changed though.

This chapter is intended to be a technical discussion of the File daemon services and as such is not targeted at end users but rather at developers and system administrators that want or need to know more of the working details of Bacula.

The Bacula File Services consist of the programs that run on the system to be backed up and provide the interface between the Host File system and Bacula -- in particular, the Director and the Storage services.

When time comes for a backup, the Director gets in touch with the File daemon on the client machine and hands it a set of "marching orders" which, if written in English, might be something like the following:

OK, File daemon, it's time for your daily incremental backup. I want you to get in touch with the Storage daemon on host archive.mysite.com and perform the following save operations with the designated options. You'll note that I've attached include and exclude lists and patterns you should apply when backing up the file system. As this is an incremental backup, you should save only files modified since the time you started your last backup which, as you may recall, was 2000-11-19-06:43:38. Please let me know when you're done and how it went. Thank you.

So, having been handed everything it needs to decide what to dump and where to store it, the File daemon doesn't need to have any further contact with the Director until the backup is complete providing there are no errors. If there are errors, the error messages will be delivered immediately to the Director. While the backup is proceeding, the File daemon will send the file coordinates and data for each file being backed up to the Storage daemon, which will in turn pass the file coordinates to the Director to put in the catalog.

During a Verify of the catalog, the situation is different, since the File daemon will have an exchange with the Director for each file, and will not contact the Storage daemon.

A Restore operation will be very similar to the Backup except that during the Restore the Storage daemon will not send storage coordinates to the Director since the Director presumably already has them. On the other hand, any error messages from either the Storage daemon or File daemon will normally be sent directly to the Directory (this, of course, depends on how the Message resource is defined).

### Commands Received from the Director for a Backup

type = <type>
  The backup type specifies the type of backup to be done. It may be one of the following:

  full, incremental, differential, level N, since date

  where
  full
    is all files in the FileSet whether or not they have changed.
  incremental
    is all files that have changed since the last backup.
  differential
    is all files that have changed since the last Full backup.
  *level N
    is all files that have changed since the last Level N backup.
  *since date
    is all files that have changed since the date specified.
jobid = <number>
  This is the unique JobId of the current Job. It is saved on the storage media with the File Attributes.
storage address = <Storage-daemon-hostname> port = <port-number>
  The Storage Address specifies the host name of the Storage daemon as well as its port number.
include = <processing-attribute-list>
<file-list>
  The Include Files specifies the list of files and/or directories to be included in the backup job. The <processing-attribute-list> is optional. If specified, it is a comma separated list of processing options to be applied to the file-list. These options are used to modify the default processing behavior of the files included. The options to be modified may be one of the following:
  compression=
  *GZIP
    All files saved will be compressed using the GNU ZIP compression format. This code is only partially implemented please DO NOT USE it.
  signature=
  MD5
    An MD5 signature will be computed for all files saved.
  encryption=
    NOT IMPLEMENTED. PLEASE DO NOT USE.
  *blowfish
    Blowfish encryption will be applied to all files saved.
  *3DES
    The 3DES encryption will be applied to all files saved.
  verify=
    Report changes in any of the following:
  p
    permission bits
  i
    inode number
  n
    number of links
  u
    userid
  g
    groupid
  s
    file size change
  a
    access time/date
  m
    modification time/date
  c
    CTIME ref time/date
  5
    MD5 signature
  d
    file size decrease
  Miscellaneous not yet implemented. PLEASE DO NOT USE.
  noexec
    All executable files will be automatically excluded from being saved.
  nofollow
    Any symbolic link found will be saved, but the link will not be followed. Thus the file to which the link points may not be saved.
  nonfs
    Any file that resides on an NFS filesystem will not be saved.
  nodescent
    Do not descend into directories found.
  sparse
    Enable special code that checks for sparse files such as created by ndbm.
  onefs
    Remain on a single filesystem.

The <file-list> is a list of filenames and/or directory names with each name being on a separate line. The filename may be enclosed in quotes for easy inclusion of spaces.

exclude
<file-list>
  The Exclude Files specifies the list of files and/or directories to be excluded from the backup job. The <file-list> is a list of filenames and/or directory names with each name being on a separate line. The <file-list> may contain wild-cards.
save
  The save command causes the File daemon to begin sending the listed files to the Storage daemon to be saved.

### Commands Received from the Director for a Restore

To be written ...

Storage Daemon Design | Index | Bacula Catalog Services

Bacula 1.30 User's Guide The Network Backup Solution | Copyright © 2000-2003 Kern Sibbald and John Walker