On 15 Mar 2011, at 03:19, Michael Wechner wrote: > On 3/15/11 12:19 AM, Rakesh Vidyadharan wrote: >> On 14 Mar 2011, at 15:10, [email protected] wrote: >> >>> Hi, >>> >>> Are there any organizations/companies that use jackrabbit as their >>> production content management system? Can somebody name a few? and how many >>> files might there be in their system? >>> >>> And which approach is better db blob storage or file system storage and what >>> are the pros/cons of each? >>> >>> Thanks, >>> KS. >> http://press.uchicago.edu/ - Built using Magnolia 4.4.2 which uses >> JackRabbit 1.6.4 as the data store. >> >> We are using the file system blob store. The blob store tends to create a >> ton of directories which makes file system backup/restore quite slow. > > Did you consider introducing a "fail over environment"? We had similar > problems, but by "mirroring" the data (and application) we don't have the > problem of a slow restore in the first place, but rather just switch the > environment (and then do the restore for the system which was previously the > master). Hence the backup > is only for the worst case if the master and mirror should be down for > whatever reasons. > > Cheers > > Michael
Yes. In fact Magnolia uses distinct author and public instances concept (with the ability to run multiple public instances per author instance). In our case, we have one author and two public instances, which means our data is always replicated across three servers. However, we still need to maintain backup processes in case of catastrophic failures, and the recovery process is only for such a case. That said, the existence of mirrors does not remove the issue with so many directories and files. Simple archiving and unarchiving (once in a while we need to do that to update our development and qa instances) tend to take much longer than they should because of this issue. It is not a deal breaker, but it could have been better. Rakesh
