Backing up /var/db/spamdb

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Backing up /var/db/spamdb

Daniel Barowy
Hi everyone,

  I realize that there's probably not much value in keeping backups of
/var/db/spamdb, since entries have a relatively short lifetime, but it
would be nice to be able to drop an existing spamdb onto another
machine; or to keep last night's backup in case a spamd/firewall fails
and needs to be brought back up quickly.  I am content to just let spamd
start over from scratch, but users do notice the delay while spamd
rebuilds the whitelist.  Don't you just love that glazed eyes look when
they hear the answer to the question "Is there something wrong with
email?"  Anything to avoid the users! ;^)

  I didn't see anything about doing backups of spamdb in the man pages,
but I'm guessing you can't just rip it out while spamd is running.  Any
pointers here?  I figure I should shutdown spamd and copy the database--
unless there's something else I can do while the program is running.

Thanks,
Dan

Reply | Threaded
Open this post in threaded view
|

Re: Backing up /var/db/spamdb

Jacob Yocom-Piatt
Daniel Barowy wrote:
> Hi everyone,
>
>  I realize that there's probably not much value in keeping backups of
> /var/db/spamdb, since entries have a relatively short lifetime, but it
> would be nice to be able to drop an existing spamdb onto another
> machine; or to keep last night's backup in case a spamd/firewall fails
> and needs to be brought back up quickly.  I am content to just let spamd

daniel,

i have learned the hard way that you should be making incremental
backups of all of your machines every night. a decent backup solution
should take care of this.

my advice is "try it!" testing is simple enough: scp /var/db/spamdb to
another machine, run spamdb and see if your IPs are preserved.

> there something wrong with email?"  Anything to avoid the users! ;^)
>

lol! tech-clueless ppl complaining about stuff is hard on my ears too. i
should get hazard pay for that crap

cheers,
jake

Reply | Threaded
Open this post in threaded view
|

Re: Backing up /var/db/spamdb

Dan Barowy
Jacob Yocom-Piatt wrote:

>
> daniel,
>
> i have learned the hard way that you should be making incremental
> backups of all of your machines every night. a decent backup solution
> should take care of this.
>
> my advice is "try it!" testing is simple enough: scp /var/db/spamdb to
> another machine, run spamdb and see if your IPs are preserved.
>
Hi Jake,

  The only thing about just copying the file-- I don't want to catch the
database in some intermediate state.  I understand that spamd uses
Berkeley DB, and I'm guessing that it is able to recover from errors,
but I honestly don't know since I've never used Berkeley DB for anything
myself.  For now, I'll take your advice and just scp the file to another
machine.

  I do incremental backups for the machines that count.  For me, a
firewall is not one of them, since with the exception of the spamdb
file, there is no important information stored on it.  I keep system
configuration files for these kinds of machines elsewhere so that we can
quickly put together replacements if they fail.  That's good enough for
me, and less work than making sure that a couple dozen incremental
backups are actually running correctly every night.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Backing up /var/db/spamdb

Otto Moerbeek
On Tue, 23 Jan 2007, Dan Barowy wrote:

> Jacob Yocom-Piatt wrote:
> >
> > daniel,
> >
> > i have learned the hard way that you should be making incremental backups of
> > all of your machines every night. a decent backup solution should take care
> > of this.
> >
> > my advice is "try it!" testing is simple enough: scp /var/db/spamdb to
> > another machine, run spamdb and see if your IPs are preserved.
> >
> Hi Jake,
>
>  The only thing about just copying the file-- I don't want to catch the
> database in some intermediate state.  I understand that spamd uses Berkeley
> DB, and I'm guessing that it is able to recover from errors, but I honestly
> don't know since I've never used Berkeley DB for anything myself.  For now,
> I'll take your advice and just scp the file to another machine.
>
>  I do incremental backups for the machines that count.  For me, a firewall is
> not one of them, since with the exception of the spamdb file, there is no
> important information stored on it.  I keep system configuration files for
> these kinds of machines elsewhere so that we can quickly put together
> replacements if they fail.  That's good enough for me, and less work than
> making sure that a couple dozen incremental backups are actually running
> correctly every night.

A simple and stupid method would be to use spamdb(8) to dump the DB.
It does proper locking. Drawback is that some script massage would be
needed to restore the db.

Also, be aware that the db format is not arch-independent. So e.g.
transferring a db between a i386 and sparc64 would not work.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Backing up /var/db/spamdb

Stephan A. Rickauer
In reply to this post by Daniel Barowy
Daniel Barowy wrote:
>  I realize that there's probably not much value in keeping backups of
> /var/db/spamdb, since entries have a relatively short lifetime, but it
> would be nice to be able to drop an existing spamdb onto another
> machine; or to keep last night's backup in case a spamd/firewall fails
> and needs to be brought back up quickly.  I am content to just let spamd

Since it's a mere Berkeley DB, can't you just do a
'db_dump /var/db/spamdb | ssh host db_load /var/db/spamdb' ?

--

 Stephan A. Rickauer

 -----------------------------------------------------------
 Institute of Neuroinformatics         Tel  +41 44 635 30 50
 University / ETH Zurich               Sec  +41 44 635 30 52
 Winterthurerstrasse 190               Fax  +41 44 635 30 53
 CH-8057 Zurich                        Web  www.ini.unizh.ch

 RSA public key:  https://www.ini.uzh.ch/~stephan/pubkey.asc
 -----------------------------------------------------------