incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabian Wabbel <fabian.wab...@getunik.com>
Subject AW: Backup Strategy for content graph
Date Tue, 04 May 2010 13:06:41 GMT
Hi Reto,

Thanks, we're going to have a look at that.


Cheers
Fabian



--getunik ag-------------------------------------------
  fabian wabbel               fabian.wabbel@getunik.com
  hardturmstrasse 101          fon: +41 (0)44 388 55 88
  ch-8005 zuerich              fax: +41 (0)44 388 55 89

--latest getunik project-------------------------
   Act local! Geo Marketing for your E-Mail campaign: www.geomarketing.com

 --best of swiss web awards 2009------------------
   Gold & Silver for Connect2Earth / Bronze for WWF UK 

we make the web a better place - www.getunik.com

*****************************************************************
Think before you print - for the sake of nature
*****************************************************************


-----Ursprüngliche Nachricht-----
Von: Reto Bachmann-Gmuer [mailto:reto.bachmann@trialox.org] 
Gesendet: Montag, 3. Mai 2010 13:37
An: clerezza-dev@incubator.apache.org
Betreff: Re: Backup Strategy for content graph

Hi Fabian

What we could do (as a clerezza improvement), would be to log all changes to
the graph. from the log you could read the differences, otherwise there's no
usable way to get this from the graph.

possibly backing up directly the backend (rdb or sesame) might be faster
than getting a dump via clerezza.

Cheers,
reto

On Sun, May 2, 2010 at 4:34 PM, Tsuyoshi Ito <tsuy.ito@clerezza.com> wrote:

> Hi Fabian
>
>
> On Apr 30, 2010, at 4:41 PM, Fabian Wabbel wrote:
>
> > Hi,
> >
> > We're using the integrated backup solution from Clerezza at the moment
> for backing up the content graph (eg.
> http://localhost:8383/admin/backup/download). In one of our production
> systems, the graph is quite big and we're now facing problems copying it to
> another machine each night (at the moment it's 200m, if the size increases
> as it did before, it will hit 1g in the next weeks). Any idea how to create
> differential backups or any other advice to solve this issue?
>
> I think the graph is quite big because your system stores all digital
> assets in a graph. I suggest to remove the digital assets from the graph and
> store it directly on the filesystem or in a database optimized for storing
> digital assets (pdf, images etc)
>
> Cheers
> Tsuy
Mime
View raw message