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