There have been questions here of late regarding backups.
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?
Next, is there anything markedly different with v2.1 that would make this unworkable, unwise, or unnecessary?
Finally, has anyone written such a script (or a similar one) so I don't have to reinvent the wheel?
reb
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
At 07:34 PM 11/26/2001 -0800, you wrote:
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.
True... so what is the best way to back things up? I'm loathe to just back up the db files, as they can easily be modified while a tar is taking place. Is that what everyone else is doing? Is there any facility for dumping user config info? I must be missing something...
reb
I posted this once before for backing up archives, dbs, and keeping all user info, but it had one small bug. The files in archives/private/* had the wrong permissions set. A small change took care of that. Also, the $person_to_nag_with_700_emails variable doesn't matter if you use the --output argument to bin/newlist. If you are moving to a new machine name, you will also want to set things with config_list - I cannot stress how powerful a tool this can be!
I think this will work for what you want, but of course this didn't fix my mailman woes :(
On Tuesday, November 27, 2001, at 10:28 AM, Phydeaux wrote:
At 07:34 PM 11/26/2001 -0800, you wrote:
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.
True... so what is the best way to back things up? I'm loathe to just back up the db files, as they can easily be modified while a tar is taking place. Is that what everyone else is doing? Is there any facility for dumping user config info? I must be missing something...
reb
Mailman-Users maillist - Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users
"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
participants (4)
-
barry＠zope.com -
John W Baxter -
Mark T. Valites -
Phydeaux