On Nov 29, 2010, at 4:03 PM, Andrea Castelli wrote: > Thank you, > > but how should I modify the nightly scheduled backup? I want to reduce the > space on DB also to be improve the speed of backup-restore.
The backup would need to backup DB and FS in parallel. Spped of the backup/restore run is a function of the size of DB and the transfer/disk speed. The only ways to improve the speed is to either reduce the size of DB or use the faster HW. One way to reduce the size of the DB is to remove unnecessary (or in an extreme case all) versions of the content. > How can I ensure that the contents of FS and DB will be synchronized? The only way to be absolutely sure is to shutdown the repository (and therefore Magnolia) and make the backup then. Other option is to automatically restore such a backup on another server (and delete indexes to force reindexing). The act of restoring and reindexing will revalidate all the entries and would fail in case of an error during backup in which case you can trigger another backup run. Also you will be absolutely sure that you can restore such a backup in the future if you need to. > > Best regards. > > Andrea > > > > > > > 2010/11/29 Unger, Richard <[email protected]> > Hello Andrea! > > > While I can’t give you any advice on the migration to FileDataStore, I can > give the following information: > > > The magnolia-bundle as shipped by Magnolia Inc. has been configured “out of > the box” to use the FileDataStore for objects larger than 1024 (bytes, I > assume). > > So at least since 4.3.6 this has been a default setting, and jackrabbit > itself recommends using the DataStores after Version 1.5… > > We have not had any troubles so far related to the DataStore. > > > The problems it brings are also clear: The repository is no longer completely > contained in the Database, there are now 2 parts needed for the repository to > work: The Persistence Manager and the DataStore. > > When clustering, it also implies a shared FileSystem (if using FileDataStore) > so all cluster-nodes can access the same DataStore, which is harder to set up > than a shared Database. > > > Regards from Vienna, > > > Richard > > > > > > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Andrea Castelli > Gesendet: Montag, 29. November 2010 14:34 > An: Magnolia User-List > Betreff: [magnolia-user] FileDataStore > > > Dear Magnolians, > I'm investigating about the feasibility to add the FileDataStore to an > existing Magnolia instance. > > http://wiki.apache.org/jackrabbit/DataStore > http://wiki.magnolia-cms.com/display/WIKI/Changing+Jackrabbit+PersistenceManager > http://wiki.apache.org/jackrabbit/BackupAndMigration > > The scenario is the following: month after month, site after site, file after > file the DB grows up. (Magnolia 4.3.1+Jackrabbit 1.6.1+MySQL) > The solution is: change to the FileDataStore. > > What does this solution imply? Are there scenarios where this solution can be > dangerous? For example, I never can be > able to rebuild indexes or magnolia-tools are not thinked to be used in such > configuration? Anything else? > > How can I perform this solution? Do I need to migrate the whole workspace, or > do I loss data? How do I schedule the Garbace Collector? > > If you already experimented this solution, what are the best practices? > > Thank you. > > Best regards. > Andrea Castelli > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
