This would be nice to be able to just backup the database, but I don't think it can work that way in the general case because in the repository folder is information about versions, custom node types, namespaces etc.
Would someone in the know please comment on whether or not this approach works/is a good practice? Thanks in advance, Mark On 5/10/07, John Ewing <[EMAIL PROTECTED]> wrote:
We currently persist our repository to a MS SQL Server Database and handle the backups using DTS to copy the data to another SQL Server install on a separate server. This works very nicely for us. To restore, we delete the repository home directory (repository xml is stored elsewhere), point at the desired repository DB, and the index is rebuild when we create an instance of the repository. Thanks! John On 5/9/07, Shaun Barriball <[EMAIL PROTECTED]> wrote: > > Jeremy, > Have you considered using the exportsystemview method? > > This is available programmatically on session or we have been using the > command line utility (a contributed component) which provides > "exportsysview > /home c:/temp/home.xml" functionality. > > Regards, > Shaun. > > > -----Original Message----- > From: Jeremy Volkman [mailto:[EMAIL PROTECTED] > Sent: 08 May 2007 21:27 > To: [email protected] > Subject: Backing up a repository > > Hi all, > > We're currently using Jackrabbit as the store for our internal CMS, and > I'm > looking for a way to perform nightly backups on our repository. We're > currently using the DerbyPersistenceManager for both versions and > workspaces. Does Jackrabbit have any built-in functionality for > performing > backups, or should I simply make a copy of the repository directory? In > the > latter case, do I have to shutdown the repository before doing so? > Optimally I'd be able to lock the repository and make a backup, having > subsequent writes to the repository simply block. > > I've looked at the contributed BackupTool, but it seems to be developed > against Jackrabbit 1.1, and we're currently using 1.2.3 (and may move to > 1.3). > > Thanks, > Jeremy Volkman > >
-- Best, Mark Waschkowski
