martin: doc/architecture server.sgml,1.33,1.34

cvs at intevation.de cvs at intevation.de
Fri Mar 18 03:07:05 CET 2005


Author: martin

Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv16584

Modified Files:
	server.sgml 
Log Message:
Martin Konold: Added documentation about Backup/Restore of imap and LDAP


Index: server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/server.sgml,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -d -r1.33 -r1.34
--- server.sgml	18 Mar 2005 01:14:20 -0000	1.33
+++ server.sgml	18 Mar 2005 02:07:03 -0000	1.34
@@ -1400,7 +1400,7 @@
 their free-busy lists via anonymous FTP on the server. If only KDE clients connect, the FTP
 functionality is not needed.</para>
 
-<para>FTP is deactivated by default, for security reasons.</para>
+<para>FTP is deactivated by default, for security reasons and is considered depricated. It is to be expected that the FTP service will be removed with some future release of Kolab.</para>
 
 <sect1><title> Kolab Server Backup Strategy </title>
 <para>One of the biggest advantages of using the maildir format on the Kolab server is, that no
@@ -1409,18 +1409,96 @@
 the fact that some files throughout the IMAP server filesystem structure may actually be opened
 during backup time. It is also possible to restore single mailboxes or even single emails with
 small to zero additional effort, compared to restoring any other file on the system.
-This is one of the biggest benefits over commercially available solutions which sometimes operate
-an a single large binary object, that actually would require
-a shutdown or a highly sophisticated online-backup
-mechanism for save backup and restore procedures.</para>
+This is one of the biggest benefits over other available solutions which sometimes operate
+an a single large binary object like a multi-gigabyte database, that actually would require
+a shutdown or a highly sophisticated online-backup mechanism for save backup and restore procedures.</para>
 
 <sect2><title>Backup of IMAP Store</title>
-<para>Missing
+<para>Backup and restore of messages can be done with
+commonly available tools. There is no need for special
+backup clients.
+</para>
+<sect3><title>Backup of IMAP messages</title>
+<para>
+The source for the backup of the IMAP store is
+<filename>/kolab/var/imapd/spool</filename>. Each individual
+message is contained in a seperate file. The normal message files
+(emails, events, tasks and notes) use an integer with a trailing dot (.) as filename.
+This integer is increased for every message in a folder and never reused.
+So the filename is unique within a folder at all times.
+</para>
+<sect3><title>Restore of IMAP messages</title>
+<para>Restoring of message is basically simply revovering the message files
+from the backup and then running <filename>reconstruct</filename> in order
+to cleanly integrate the recovered message in the imap databases.
+</para>
+<para>
+The largest database is the mailbox directories. Each mailbox directory contains the following files:
+</para>
+<orderedlist>
+<listitem>
+<para>message files</para>
+<para>
+There is one file per message, containing the message in RFC 822 format. Lines in the message are separated by CRLF, not just LF. The file name of each message is the message's UID followed by a dot (.).
+</para>
+</listitem>
+<listitem>
+<para>cyrus.header</para>
+<para>
+This file contains a magic number and variable-length information about the mailbox itself.
+</para>
+</listitem>
+<listitem>
+<para>cyrus.index</para>
+<para>This file contains fixed-length information about the mailbox itself and each message in the mailbox.
+</para>
+</listitem>
+
+<listitem>
+<para>cyrus.cache</para>
+<para>This file contans variable-length information about each message in the mailbox.
+</para>
+</listitem>
+
+<listitem>
+<para>cyrus.seen</para>
+<para> This file contains variable-length state information about each reader of the mailbox who has "s" permissions.
+</para>
+</listitem>
+</orderedlist>
+<para>
+ The <filename>reconstruct</filename> program can be used to recover from corruption in mailbox directories. If </filename>reconstruct</filename> can find existing header and index files, it attempts to preserve any data in them that is not derivable from the message files themselves. The state <filename>reconstruct</filename> attempts to preserve includes the flag names, flag state, and internal date. <filename>Reconstruct<filename> derives all other information from the message files.
+</para>
+<para>An administrator may recover from a damaged disk by restoring message files from a backup and then running reconstruct to regenerate what it can of the other files.
+</para>
+<para>
+The <filename>reconstruct</filename> program does not adjust the quota usage recorded in any quota root files. After running reconstruct, it is advisable to run <filename>quota -f</filename> in order to fix the quota root files.
 </para>
 </sect2>
 
 <sect2><title>Backup of LDAP Directory</title>
-<para>Missing
+<para>The data of the OpenLDAP server is stored in
+<filename>/kolab/var/openldap/openldap-data/</filename>. Doing a snapshot (e.g. using LVM tools)
+of this directory and its contents is the main step when backing up the LDAP directory.
+</para>
+<para>The files in the <filename>openldap-data</filename> directory are actually Berkley DB databases. When recovering bdb files it is highly recommended to run db_recover on them in
+order to commit any missing database logs.
+</para>
+<sect3><title>Portable Backup of LDAP Directory</title>
+<para>
+The most portable way of doing a backup of the LDAP directory is to use <filename>
+slapcat</filename>. This creates a textual representation of the directory using
+the LDAP Directory Interchange Format (LDIF). For consistency it is highly recommended to
+stop the directory service while doing a <filename>slapcat</filename>.
+</para>
+<sect3><title>Restoring a portable Backup of LDAP Directory</title>
+<para>The LDIF file obtained from <filename>slapcat</filename> can be easily
+added to an otherwise empty LDAP server using <filename>slapadd</filename>.
+</para>
+<para>Please note that the LDIF file generated by <filename>slapcat</filename> is suitable for use with <filename>slapadd</filename> but not <filname>ldapadd</filename>.  As the entries are  in  database order,  not superior first order, they cannot be loaded with <filename>ldapadd</filename> without first being reordered.
+</para>
+<para>In case uninterrupted operation of the directory server is required you can simply replicate the directory server to a slave server setup. It is then save to stop the slave
+during the backup operation without interrupting the main LDAP directory service.
 </para>
 </sect2>
 </sect1>





More information about the commits mailing list