cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Oberman <ober...@civicscience.com>
Subject Re: best way to backup
Date Thu, 28 Apr 2011 20:10:32 GMT
Interesting.  Both use cases seem easy to code.
Compress to S3 = cassandra snapshot, tar, s3 put
EBS = cassandra snapshot, rsync snapshot dir -> ebs, ebs snapshot

I think the former is cheaper in terms of costs, as my gut says keeping
around an EBS drive is more money than the lack of deltas in S3.  But, EBS
would allow extremely fine grained snapshotting without storage penalties
(EBS snaps are supposed to be compressed deltas behind the scenes).  Of
course, I don't know how cassandra likes frequent snapshotting, and given
the amount of node redundancy/eventual consistency that seems pointless
anyways.

will

On Thu, Apr 28, 2011 at 3:57 PM, Sasha Dolgy <sdolgy@gmail.com> wrote:

> You could take a snapshot to an EBS volume.  then, take a snapshot of that
> via AWS.  of course, this is ok.when they -arent- having outages and issues
> ...
> On Apr 28, 2011 9:54 PM, "William Oberman" <oberman@civicscience.com>
> wrote:
> > Even with N-nodes for redundancy, I still want to have backups. I'm an
> > amazon person, so naturally I'm thinking S3. Reading over the docs, and
> > messing with nodeutil, it looks like each new snapshot contains the
> previous
> > snapshot as a subset (and I've read how cassandra uses hard links to
> avoid
> > excessive disk use). When does that pattern break down?
> >
> > I'm basically debating if I can do a "rsync" like backup, or if I should
> do
> > a compressed tar backup. And I obviously want multiple points in time. S3
> > does allow file versioning, if a file or file name is changed/resused
> over
> > time (only matters in the rsync case). My only concerns with compressed
> > tars is I'll have to have free space to create the archive and I get no
> > "delta" space savings on the backup (the former is solved by not allowing
> > the disk space to get so low and/or adding more nodes to bring down the
> > space, the latter is solved by S3 being really cheap anyways).
> >
> > --
> > Will Oberman
> > Civic Science, Inc.
> > 3030 Penn Avenue., First Floor
> > Pittsburgh, PA 15201
> > (M) 412-480-7835
> > (E) oberman@civicscience.com
>



-- 
Will Oberman
Civic Science, Inc.
3030 Penn Avenue., First Floor
Pittsburgh, PA 15201
(M) 412-480-7835
(E) oberman@civicscience.com

Mime
View raw message