[Kolab-devel] automated backup
lists at pietrosanti.it
Mon Oct 17 08:49:28 CEST 2005
I think that tar/gz/bz backup should be fine but it'ss not scalable.
Imho backup should be enabled with explicit action by the system
administrator and not a default settings to avoid the 1TB of data problem.
Regarding the backup solution, due to the master/slave design of Kolab,
imho the best choise would be to use amanda (http://www.amanda.org).
Amanda, already in OpenPKG 2.4 stable PLUS (
It has a client-server design, can do backup not only to tape but also
directly to disk.
Could be interesting if every server could be a client and a server at
the same time.
By design every slave server could be associated with it's own backup
The backup server could be a centralized one (think about a datacenter
or a fast WAN where the IT prefer to have a centralized backup
solutions) or a decentralized one (think about the master/slave
configuration for branch offices that need to do their backup inside
their LAN or on the same server).
I immagine a "backup" section in the web admin interface of every server
where it's possible to enable the "backup client" and the "backup server".
Amanda has the advantage of managing itself incremental backup, with the
availability of taking several revision of backupped files (let say
backup of yesterday, of last week and last month) and look at the future
of Kolab that's increasing it's functionality over the time.
If amanda require too effort to integrate within Kolab would be also
interesting to attempt to create the same model of
master/slave/remote/local backup using rsync.
Markus Heller ha scritto:
>I just read about a feature wish somebody stated in the wiki:
>"Integrated tar/gz/bz backup of mailboxes and configuration files plus cron
>What do you think about omitting the idea that the backup needs to be 100%
>I mean, in that case, a simple perl script would be absolutely sufficient. In
>order not to rely on the tar and gzip binaries of the underlying OS, the
>following perl modules would need to be installed:
>The only problem here would be scalability. In case somebody has a 1 TB Kolab
>installation, such a perl script would run forever. Perhaps a neat little c
>implementation wouldn't be bad either?
>Or would you suggest to leave this task to the cyrus guys and hope they start
>to develop reasonable backup procedures within cyr_master?
>What's your strategy?
>Thanks for your oppinion!
>Kolab-devel mailing list
>Kolab-devel at kolab.org
More information about the devel