"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