Newbie Q: How do you backup the data? Where is everything anyway?
Greetings! I just installed Zope and Plone and am trying to get the hang of it by playing with it and working my way through the available documentation. I just figured out that folders, paths and files (e.g. /thefirst/portal_skins/plone_styles/ploneCustom.css - "thefirst" is the Plone site I just created) don't actually represent actual files in the file system (this is on a Linux box), but seem to be stored somwhere else, apparently in the ZODB (my reading seems to suggest this). However, I don't know where this object database stores its information - var/Data.fs does not exist on my system (one article I found said that this was the place where the ZODB data was to be found) - and even if I found it, I'd still need to know how to back it up. With my favourit SQL database, PostgreSQL, for instance, you are disencouraged to simply copy the directories where PostgreSQL stores its data since this would break the transactional integrity (or you'd have to stop the server to do it which isn't really optimal . . . ). Thus you have a special utility, pg_dump, which dumps your data into flat files that can be read back into the server if need be. Hence my questions: Where are the data to be found and how do you back them up? Is there a way to read them out into a file/format that is not binary, that can be viewed with a text editor as a plain file? Regards, Frank
I just figured out that folders, paths and files (e.g. /thefirst/portal_skins/plone_styles/ploneCustom.css - "thefirst" is the Plone site I just created) don't actually represent actual files in the file system (this is on a Linux box), but seem to be stored somwhere else, apparently in the ZODB (my reading seems to suggest this).
This is in general true. However, some products allow you to retrieve/store data elsewhere, like the filesystem. CMF skins that ship with products are stored on the FS: you can usually find them in a place like Products/CMFProductName/skins/CMFProductName You shouldn't be changing these directly unless you're developing that product; any customizations you make will be stored in the ZODB.
However, I don't know where this object database stores its information - var/Data.fs does not exist on my system (one article I found said that this was the place where the ZODB data was to be found) - and even if I found it, I'd still need to know how to back it up.
Unless someone has produced a new and clever installer, it's almost certain that you have a Data.fs somewhere. I've never head of a Zope installer that used a storage other than FileStorage (which uses the Data.fs scheme.) Try 'locate Data.fs', provided you're done an 'updatedb'.
With my favourit SQL database, PostgreSQL, for instance, you are disencouraged to simply copy the directories where PostgreSQL stores its data since this would break the transactional integrity (or you'd have to stop the server to do it which isn't really optimal . . . ). Thus you have a special utility, pg_dump, which dumps your data into flat files that can be read back into the server if need be.
It is widely regarded as safe to simply copy your Data.fs. As a single file, it is not subject to copy-while-write consistency issues. If you do copy in the middle of a transaction, you will lose that transaction, but it will be truncated on next run and should not harm your previous data. DirectoryStorage (an alternate ZODB storage) has utilities for a snapshot mode, and does incremental backups, as well as other neat things. http://dirstorage.sourceforge.net/
Hence my questions: Where are the data to be found and how do you back them up? Is there a way to read them out into a file/format that is not binary, that can be viewed with a text editor as a plain file?
The ZODB stores objects, and thus it cannot be guaranteed that they have reasonable contents outside the context of a running Zope. Usually they are stored pickled (aka serialized.) You can access live objects for editing via the web, FTP, and WebDAV. You can also export Zope objects (for transfer to another Zope) in an XML format, as well as pickled. I can't say this XML is terribly usable, however. Possibly Ape (nee AdaptableStorage) can provide FS human-readable storage. --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."
On Mon, Jul 28, 2003 at 12:44:13PM -0500, J Cameron Cooper wrote: []
However, I don't know where this object database stores its information - var/Data.fs does not exist on my system
Something really stupid, this was (I'm not sure what exactly): My Midnight Commander file manager appeared to have a view cached or something, and displayed var/ as empty . . . []
It is widely regarded as safe to simply copy your Data.fs. As a single file, it is not subject to copy-while-write consistency issues. If you do copy in the middle of a transaction, you will lose that transaction, but it will be truncated on next run and should not harm your previous data.
Ah, cool. That's good to know.
DirectoryStorage (an alternate ZODB storage) has utilities for a snapshot mode, and does incremental backups, as well as other neat things. http://dirstorage.sourceforge.net/
Excellent link; in particular the link there to the ZODB storage feature comparison matrix is helpful. Thanks & Regards, Frank
participants (2)
-
Frank Joerdens -
J Cameron Cooper