[Zope] Backing up Zope's database?

[Martijn Faassen]

Paul Everitt wrote:
> 
> Martijn wrote:
> > I briefly saw the pack operation but I had no clue that it
> > could be used
> 
> It isn't supposed to be used for backup purposes, just like Python
> wasn't written to be the world's best desktop calculator.  It just
> turned out that way.

Yeah, it's a side effect; I am sorry I wasn't clear in showing that I
understood it wasn't meant to do this. 
 
> > for backup purposes. Generally things that say 'remove' as in 'remove
> > object revisions that are older than X days' don't associate with
> > 'backup' in my mind.
> 
> Zope doesn't have a "make a backup file facility".  Packing just happens
> to make a backup file.  If what is really wanted is a "make a backup
> file facility", this would be an easy project for the community to
> submit some patches.

Right; since I think having a good backup is rather essential, I'll
delve into the source code to see what pack does to create its backup,
and then try to extend the Zope control panel with a backup feature.
 
[snip]

> > I saw some references to the Zope scheduler..would this be the thing
> > that I'd use to automate backups?
> 
> There really isn't a Zope Scheduler facility, unfortunately.  I'd expect
> it to become more prominent when concurrency arrives.

So currently there's no 'cron' type system in Zope, I understand? What
do you mean by 'when concurrency arrives' by the way? Does this have to
do with multithreading?
 
> Instead, use cron.  Write a little ZRPC (or just httplib) script that
> connects to the Control Panel and executes a pack.

I should look into ZRPC. And on how to do cron on NT (sigh :). Perhaps
arcserve can start a little script before it starts to do the backup. I
don't know much about arcserve (I didn't install it), and I should delve
further tomorrow in exactly *what* is failing.
 
[file system export as another option]

> That's another option.  I'm not sure how much the import/export
> machinery executes at the application level instead of the database
> level (where pack resides), so export *might* be a tad slower.  Also it
> won't *really* be a full backup as it won't contain old revisions of
> objects.

I see. I'll have to think about how important keeping old revisions is.
 
> > It would also be nice if this backup could somehow be
> > synchronized with
> > the external tape backup procedure, so that the tape backup doesn't
> > backup while Zope's still creating a backup, and such.
> 
> Uhh, I imagine that's one for you.

The ficticious Zope scheduler could call some external method to
check..whatever, yeah, that's up to me. :)
 
> > I'm sure I'm not the only one trying to make a proper backup
> > of the Zope
> > database. How is this done by other people?
> 
> We do backups all the time on Unix and have no problems.  The Zope
> database format generally makes it pretty safe to do backups (as all
> write operations are appends).

So it's not a big problem to do a backup of a Zope database while it is
in active use? I really do need to figure out why arcserve fails at
backing up the database. Oddly enough just copying it in NT works just
fine. Therefore, the simplest ad hoc solution (if arcserve allows this
and it should otherwise it's braindead) is to create a small python
script or batch file that copies the database, and then do a backup of
this database.

I don't expect this particular Zope installation to see very heavy use
in the future anyway, but one never knows. I just want to be sure in
this case; making a backup one isn't pretty sure about isn't worth
making...

Thanks for your replies!

Martijn