
Bacula 1.29 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
|
|
 |
|
|