]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manuals/es/developers/file-en.tex
Setup es/developers for translation
[bacula/docs] / docs / manuals / es / developers / file-en.tex
diff --git a/docs/manuals/es/developers/file-en.tex b/docs/manuals/es/developers/file-en.tex
new file mode 100644 (file)
index 0000000..ee89577
--- /dev/null
@@ -0,0 +1,68 @@
+%%
+%%
+
+\chapter{File Services Daemon}
+\label{_ChapterStart11}
+\index{File Services Daemon }
+\index{Daemon!File Services }
+\addcontentsline{toc}{section}{File Services Daemon}
+
+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
+{\bf Bacula}. 
+
+The {\bf 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, {\bf 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 {\bf 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 {\bf Restore} operation will be very similar to the {\bf Backup} except that
+during the {\bf 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). 
+
+\section{Commands Received from the Director for a Backup}
+\index{Backup!Commands Received from the Director for a }
+\index{Commands Received from the Director for a Backup }
+\addcontentsline{toc}{subsection}{Commands Received from the Director for a
+Backup}
+
+To be written ... 
+
+\section{Commands Received from the Director for a Restore}
+\index{Commands Received from the Director for a Restore }
+\index{Restore!Commands Received from the Director for a }
+\addcontentsline{toc}{subsection}{Commands Received from the Director for a
+Restore}
+
+To be written ...