Production Backup Strategies

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Production Backup Strategies

Mike Katz
Hey All, 

I'm sizing up some database options for a fairly ambitious app I'm building out for a client of mine. I've read a good amount of the available docs and have toyed around with Riak enough to know that it's one of my finalists (one of two, to be precise). 

Before I set off building this app, there was one thing I wanted to ask about: backups. Specifically, what strategies/methods are people using to backup the data in their Riak clusters? I've worked with this client enough to know that they won't sign off on a relatively new database technology without knowing that the backup story was rock-solid. 

I'd really love to use Riak, and this is basically my last hurdle. Any anecdotes/examples/pointers to blog posts that my Googling has yet to uncover would be much appreciated.

Thanks!

MK 

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Production Backup Strategies

Aphyr
In the exciting event that your application or riak goes rogue and
deletes everything, bitcask will allow you to recover amazing,
life-saving amounts of data from its log-structured format.

ASK ME HOW I KNOW. :-P

Uh, more typically, I've heard that FS-level snapshots of /var/lib/riak
or simple tarballs work well. riak-admin backup works fairly well below,
say, 50 million keys, but can take several hours at that scale.

--Kyle

On 05/13/2011 05:27 PM, Mike Katz wrote:

> Hey All,
>
> I'm sizing up some database options for a fairly ambitious app I'm
> building out for a client of mine. I've read a good amount of the
> available docs and have toyed around with Riak enough to know that it's
> one of my finalists (one of two, to be precise).
>
> Before I set off building this app, there was one thing I wanted to ask
> about: backups. Specifically, what strategies/methods are people using
> to backup the data in their Riak clusters? I've worked with this client
> enough to know that they won't sign off on a relatively new database
> technology without knowing that the backup story was rock-solid
>
> I'd really love to use Riak, and this is basically my last hurdle. Any
> anecdotes/examples/pointers to blog posts that my Googling has yet to
> uncover would be much appreciated.
>
> Thanks!
>
> MK
>
>
>
> _______________________________________________
> riak-users mailing list
> [hidden email]
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Production Backup Strategies

Justin Sheehy
In reply to this post by Mike Katz
Hi, Mike.

Assuming that the cluster is using the default storage engine
(bitcask) then the backup story is straightforward. Bitcask only ever
appends to files, and never re-opens a file for writing after it is
closed.  This means that your favorite existing server filesystem
backup mechanism will Just Work.

Other means exist, but that is the simplest and often the best.

-Justin

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Production Backup Strategies

Jeremy Raymond

So just backing up the files from separate nodes works? There won't be inconsistencies in the data say if all the nodes had to be restored?

- Jeremy

On 2011-05-13 8:35 PM, "Justin Sheehy" <[hidden email]> wrote:
> Hi, Mike.
>
> Assuming that the cluster is using the default storage engine
> (bitcask) then the backup story is straightforward. Bitcask only ever
> appends to files, and never re-opens a file for writing after it is
> closed. This means that your favorite existing server filesystem
> backup mechanism will Just Work.
>
> Other means exist, but that is the simplest and often the best.
>
> -Justin
>
> _______________________________________________
> riak-users mailing list
> [hidden email]
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Reply | Threaded
Open this post in threaded view
|

Re: Production Backup Strategies

Justin Sheehy
Hi, Jeremy.

On Sat, May 14, 2011 at 2:45 PM, Jeremy Raymond <[hidden email]> wrote:

> So just backing up the files from separate nodes works? There won't be
> inconsistencies in the data say if all the nodes had to be restored?

That's right, it works.  :-)

Inconsistencies due to modifications that occur between the moments
two different nodes are backed up will fixed by anti-entropy
mechanisms such as read-repair.

-Justin

_______________________________________________
riak-users mailing list
[hidden email]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com