Riak CS Backup Solutions

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

Riak CS Backup Solutions

Valenti, Anthony

We are looking to improve on our Riak CS backup strategy.  We have had Riak CS in place for a while and we are currently taking a snapshot of each server.  I'm not sure is this is the best method in terms of recoverability, space used, timeliness or the backups, etc.  What methods has anyone else used?  What is the basho recommended solution?

Thanks,

Anthony Valenti


********************************************

 

Inmar Confidentiality Note:  This e-mail and any attachments are confidential and intended to be viewed and used solely by the intended recipient.  If you are not the intended recipient, be aware that any disclosure, dissemination, distribution, copying or use of this e-mail or any attachment is prohibited.  If you received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy and all attachments from your system and destroy any printed copies.  Thank you for your cooperation.

 

Notice of Protected Rights:  The removal of any copyright, trademark, or proprietary legend contained in this e-mail or any attachment is prohibited without the express, written permission of Inmar, Inc.  Furthermore, the intended recipient must maintain all copyright notices, trademarks, and proprietary legends within this e-mail and any attachments in their original form and location if the e-mail or any attachments are reproduced, printed or distributed.

 

********************************************


_______________________________________________
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: Riak CS Backup Solutions

Bryan Hunt-3
Anthony, 

Your snapshot solution is not bad if you just want a daily version you can roll back to for disaster recovery.

I presume : 

1. You’re running on VM’s 
2. You stop the world at the time of the snapshot

Riak CS makes multiple (3 by default) copies of your data and generally speaking, stores them onto multiple physical servers with the following caveats : 

1. Verify that the partitions are evenly spread across the machines, sometimes old Riak puts two copies of the data on a single physical machine.
2. Always run a cluster of 5 or more machines.
3. Take care that you’re not storing all your data on the same physical device (SAN server in the basement anyone?) ).

I suppose the reason you want backups is to mitigate the situation where an adversary gets inside your servers and begins silently deleting or tampering with data, in which case, snapshots are prudent. 

If you wanted to do something more sophisticated, you could try : 

1. Re-building your cluster using the soon to be released Riak 2.2.5.
2. Replicate off site to a physically remote location
3. More regularly perform snapshots there (as they won’t impact latencies on your main Riak CS cluster)

Does that make sense? Any questions? 

Bryan 




On 25 Apr 2018, at 14:30, Anthony Valenti <[hidden email]> wrote:


We are looking to improve on our Riak CS backup strategy.  We have had Riak CS in place for a while and we are currently taking a snapshot of each server.  I'm not sure is this is the best method in terms of recoverability, space used, timeliness or the backups, etc.  What methods has anyone else used?  What is the basho recommended solution?

Thanks,

Anthony Valenti


********************************************


 

Inmar Confidentiality Note:  This e-mail and any attachments are confidential and intended to be viewed and used solely by the intended recipient.  If you are not the intended recipient, be aware that any disclosure, dissemination, distribution, copying or use of this e-mail or any attachment is prohibited.  If you received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy and all attachments from your system and destroy any printed copies.  Thank you for your cooperation.


 

Notice of Protected Rights:  The removal of any copyright, trademark, or proprietary legend contained in this e-mail or any attachment is prohibited without the express, written permission of Inmar, Inc.  Furthermore, the intended recipient must maintain all copyright notices, trademarks, and proprietary legends within this e-mail and any attachments in their original form and location if the e-mail or any attachments are reproduced, printed or distributed.

 

********************************************

_______________________________________________
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: Riak CS Backup Solutions

Nicholas Adams

Dear Anthony,

 

As you specified in your question as to Basho's official method, may I refer you to https://docs.basho.com/riak/kv/2.1.4/using/cluster-operations/backing-up/

 

Backing up an entire Riak cluster in one operation is difficult because of the way Riak operates. It is impossible, without downtime, to say that no requests are currently in-flight between nodes or only written 2 out of 3 replicas, etc. For this reason we recommend users back up their nodes in a rolling fashion. Taking a node down, backing up the data/configuration/ring, and then restarting the node. Restoring from these backups is simple. Move the data directory backups, config, and ring back to their appropriate location and start the node.

 

But even with all those explanations, it's clear that for realtime distributed systems there's really not a truly "point in time" backup. This has been resolved in a Riak KV cluster via MDC replication. Should you want to consider MDC replication, we would highly recommend bi-directional replication as non bi-directional replication does not propagate tombstones which will lead to siblings on the standby cluster.

 

One thing to bear in mind is that Riak CS was never officially tested or approved with Riak KV 2.2.x series. As such, if you do not have an Enterprise Edition copy of Riak KV 2.1.4 or earlier, there is no officially approved way to run an MDC solution with Riak CS.

 

If MDC is not an option, one possible way to be able to replicate to a standby cluster is to do it at the application level. Maybe have the app communicate to 2 CS nodes, the 1st CS node communicates to the production Riak KV cluster and the 2nd one communicates to the standby Riak KV cluster. This way, both the production and standby KV clusters get updated at around the same time.

 

tl;dr;

The only truly safe ways to back up a Riak cluster that is using Riak CS would be to:

1. Stop the cluster completely and do a full data back up via your preferred method e.g. snapshots, tarballs etc.

2. Licensing permitting, use MDC to replicate to another cluster.

3. Create something yourself to work at the application level that would mirror all commands.

 

Hope this helps,

 

Nicholas

 

From: riak-users <[hidden email]> On Behalf Of Bryan Hunt
Sent: 25 April 2018 22:50
To: riak-users <[hidden email]>
Subject: Re: Riak CS Backup Solutions

 

Anthony, 

 

Your snapshot solution is not bad if you just want a daily version you can roll back to for disaster recovery.

 

I presume : 

 

1. You’re running on VM’s 

2. You stop the world at the time of the snapshot

 

Riak CS makes multiple (3 by default) copies of your data and generally speaking, stores them onto multiple physical servers with the following caveats : 

 

1. Verify that the partitions are evenly spread across the machines, sometimes old Riak puts two copies of the data on a single physical machine.

2. Always run a cluster of 5 or more machines.

3. Take care that you’re not storing all your data on the same physical device (SAN server in the basement anyone?) ).

 

I suppose the reason you want backups is to mitigate the situation where an adversary gets inside your servers and begins silently deleting or tampering with data, in which case, snapshots are prudent. 

 

If you wanted to do something more sophisticated, you could try : 

 

1. Re-building your cluster using the soon to be released Riak 2.2.5.

2. Replicate off site to a physically remote location

3. More regularly perform snapshots there (as they won’t impact latencies on your main Riak CS cluster)

 

Does that make sense? Any questions? 

 

Bryan 

 

 

 



On 25 Apr 2018, at 14:30, Anthony Valenti <[hidden email]> wrote:

 


We are looking to improve on our Riak CS backup strategy.  We have had Riak CS in place for a while and we are currently taking a snapshot of each server.  I'm not sure is this is the best method in terms of recoverability, space used, timeliness or the backups, etc.  What methods has anyone else used?  What is the basho recommended solution?

 

Thanks,

Anthony Valenti



********************************************

 

 

Inmar Confidentiality Note:  This e-mail and any attachments are confidential and intended to be viewed and used solely by the intended recipient.  If you are not the intended recipient, be aware that any disclosure, dissemination, distribution, copying or use of this e-mail or any attachment is prohibited.  If you received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy and all attachments from your system and destroy any printed copies.  Thank you for your cooperation.

 

 

Notice of Protected Rights:  The removal of any copyright, trademark, or proprietary legend contained in this e-mail or any attachment is prohibited without the express, written permission of Inmar, Inc.  Furthermore, the intended recipient must maintain all copyright notices, trademarks, and proprietary legends within this e-mail and any attachments in their original form and location if the e-mail or any attachments are reproduced, printed or distributed.

 

********************************************

_______________________________________________
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