At 21:49 -0500 11/26/2001, Phydeaux wrote:

Using bin/list_lists I can get a list of the lists. I can then easily cycle through each list and (for each one) do the following:

• Run bin/config_list
• Run bin/list_members (once for digested, once for regular members)
• Copy the complete archive or at least the mbox file of the archive.

I can then tar the whole mess up and copy it to tape, etc. for a portable backup of my mailman installation.

I have several questions. First, am I forgetting to copy anything? Will the above approach get me all the data I need to restore the system?

I don't think the above has captured various user flags other than digest vs regular.

I believe a restore will not restore subscriber choices like not-me-to, no-mail, hidden, and some others.

--John

-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA

...

...

...

...

"P" == Phydeaux <reb@taco.com> writes:

P> Using bin/list_lists I can get a list of the lists. I can then
P> easily cycle through each list and (for each one) do the
P> following:

P> - Run bin/config_list - Run bin/list_members (once for
P> digested, once for regular members) - Copy the complete archive
P> or at least the mbox file of the archive.

P> I can then tar the whole mess up and copy it to tape, etc. for
P> a portable backup of my mailman installation.

P> I have several questions. First, am I forgetting to copy
P> anything?  Will the above approach get me all the data I need
P> to restore the system?

I'd say it would be much easier to just backup all of $prefix, e.g. /home/mailman. Is that too much stuff to backup? It's a bit more than you need if you're willing to re-install the system, but it has the advantage that it'll backup all the waiting messages in qfiles too.

For absolute best results, I'd try to make sure that the qrunner was quiescent and that no one could change the list config.db files while you're backing up. This means temporarily turning off qrunner (through cron) and preventing the cgi scripts from running. You may even want to shut off your MTA so you don't get half written files in the qfiles directory.

P> Next, is there anything markedly different with v2.1 that would
P> make this unworkable, unwise, or unnecessary?

MM2.1 should have largely the same issues, except it'll have a long running daemon instead of cron-invoked qrunners, so at least that part will be easier to suspend during the backups. And by default, MM2.1 installs in /usr/local/mailman instead of /home/mailman.

I wonder if it's worth putting blockers into MM2.1 to stop the cgi from mucking with config.pck (renamed from config.db)? OTOH, it isn't Mailman's job to stop the MTA and that still should be done.

-Barry

At 10:38 AM 11/27/2001 -0500, Barry A. Warsaw wrote:

P> Next, is there anything markedly different with v2.1 that would
P> make this unworkable, unwise, or unnecessary?

MM2.1 should have largely the same issues, except it'll have a long running daemon instead of cron-invoked qrunners, so at least that part will be easier to suspend during the backups. And by default, MM2.1 installs in /usr/local/mailman instead of /home/mailman.

I wonder if it's worth putting blockers into MM2.1 to stop the cgi from mucking with config.pck (renamed from config.db)? OTOH, it isn't Mailman's job to stop the MTA and that still should be done.

But -- once the message has gone to the MTA Mailman is done with it,!

A method to easily stop Mailman from processing things for a time is what I'm really looking for. I don't mind backing up everything I just want to ensure that I do not get an inconsistent set of files by doing so while the set of files is being written to. Having to stop qrunner, sendmail and my web server seems a bit extreme.

Anything that can be done to stop qrunner and to not have to stop the .cgi interface of the web server (ie a backup lock for Mailman) would be great.

reb